u/BinaryDichotomy

I am the founder and CTO of an internet threat intelligence and internet security SaaS offering, I write tools for privacy vendors like AdGuard. I am open-sourcing a suite of tools for AdGuard and AdGuard DNS I wrote last year as prototypes for a new suite of tools my firm is releasing later this year. I wanted to ensure I'm giving back to the AdGuard community that has so graciously provided some of the open source code needed to provide inspiration for me to write tools that will hopefully benefit the entire internet writ-large when we reach RTM

The tools I'm releasing today are geared towards developers and list makers, and are ports of the original AdGuard Hostlist Compiler. AdGuard have provided the foundation for a new suite of tools we'll be releasing soon. To be clear, we are not aiming to compete with AdGuard or any other threat intelligence vendor (e.g. NextDNS, Technitium, etc.) and are instead seeking to provide the intelligence portion, along with simplified toolsets to interact vendor APIs via single pane of glass. We hope to partner with firms like AdGuard to provide the intelligence portion of their platforms, laying on top of their infrastructure investment.

Our tools will allow users with investments in 3rd party privacy tools like AdGuard to continue using those tools, we'll just provide the intelligence portion along with an interface to automatically have those rules applied to your vendor. We're a drop in replacement for the threat intelligence portion.

Bloqr's threat list compilers provide vastly superior performance, with threading and chunking provided out of the box. We can compile millions of rules in seconds, and can combine rules from dozens of lists into a single artifact in a fraction of the time. Our libraries can be integrated into CLI pipelines, embedded as libraries, and are fully customizable and extensible.

https://github.com/Bloqr-Systems/bloqr-lists

EDIT: Only the core /src directory is published to JSR, all cloudflare infrastructure code is not. Only core functionality is contained in the /src directory, but that includes most of the business logic, but not web API calls.

I have an SaaS offering I'm putting the finishing touches on, and am wondering what the best architecture is to allow limited core functionality for the core library, and paywall premium features? My first thought is to require an API key for all API calls to the SaaS web service, but I also need to account for airgapped installations where API keys cannot be validated via web api calls. Currently, every web API request requires an API key regardless of tier so I can track usage/etc.

All libraries are hosted on a private Github mono-repository, but I also publish to JSR to allow for developers to use the libraries locally via Deno package imports, however, I only want a very limited subset of the functionality to be free, with premium features requiring a paid monthly subscription + usage fees. The app is hosted on Cloudflare, and every API that is exposed locally also has a web API counterpart, and every API call requires an API key which is checked at runtime to verify the user has the appropriate license. The same library code hosted on Cloudflare is what you get if you import the package from JSR via Deno/Bun/Node/etc, so any code that is executed via web APIs can also be executed locally.

I want to expose a very limited subset of functionality for the imported package for free, with extra functionality only available for paid license holders via a monthly subscription. My initial thought was to extract the core functionality into something like app-core, which is then imported into the premium library as an embedded package, with the app-core available in a public github repo and having only that repo exported to JSR. But, I still want to track usage regardless of subscription tier. For premium source code, I will be charging a fee.

I don't want to publish the source code for the premium library, hence why it's a private github repo. So do I layer the private github repo on top of the public limited core github repo, or do I publish the whole thing to JSR (assuming that's even possible for a private github repo) and gatekeep every API call with API keys and check at runtime? That exposes all of the source code though, and only a limited subset of the source code should be available for free.

The other issue is that the core library could be used in airgapped scenarios where internet access isn't available, which is why I'm wondering if having a limited core package is the better option? I realize I can't track usage then, but I don't want developers to be able to download the entire source code. If airgapped scenarios weren't required, I'd just put everything behind API key checks and limit functionality that way (which is my current architecture) but I've had customers request airgapped support.

Or should I change the entire architecture to a facade library that contains local code for the limited free features and paywall premium features behind API key checks, with the full set of libraries executed in cloudflare workers. Or offer two libraries: One free library that is self-contained, which can then be embedded in the premium library? That still doesn't solve airgapped scenarios though b/c some airgapped installations will want the premium features, but how to A) check usage for billing and B) track said usage?

Or do I just not support airgapped scenarios? I didn't account for airgapping in my initial architecture, and I want to ensure the limited features are available for free, but still be able to bill for airgapped premium features. What's the best architecture to account for all of these scenarios?

The app is written in typescript, with most premium features compiled to web assembly on the server side. The web assembly code will always be proprietary with no initial plans to offer that source code, though at some point I will offer a paid subscription to the webassm code for enterprise customers down the road. Webassm will be executed on the server and not in the browser, at least not initially. Currently it's a monorepo with several cloudflare workers hosting the runtime code, and each library is self-contained and monolithic with a simple dependency model. If you were to have access to the private repo and could download the source code, you'd basically have the entire set of code that runs on cloudflare able to be run locally via Wrangler.

I feel like my architecture is flawed as my assumption is this would always be run on Cloudflare via web APIs called from a web UI, but I want to offer developers the option to run it embedded, but only via web API calls. The airgapped architecture requests are throwing me for a loop as all execution was assumed to be called through cloudflare workers. The requests for airgapped installations are minimal and would not have a big impact on my bottom line, but I hate turning customers away, but I'm far enough along that changing my architecture to accommodate airgapped requests would require several more weeks of work.

The bigger question is how to layer the free vs premium libs though. Currently every request from a local library run via CLI or embedded calls into the cloudflare worker web APIs with API key checks done to check subscription tier, and logging usage. I'm inclined to just not support airgapped installations, but the architecture is an intriguing question b/c it's not something I've thought about architecting prior to now. Or am I overthinking this? The SaaS itself is geared towards general users via the web UI, and developers/admins via local usage by importing via Deno/etc, I just want to ensure I'm not exposing the entire proprietary codebase without everything going through web API calls. The web UI is a facade, but the libraries have all of the source code, but not available via github or JSR, but I want to expose a very limited freemium subset for basic usage.

My SaaS offering is a private monorepo on Github, written natively for Cloudflare as a set of composed Worker services (along with dozens of other CF services, but the APIs are surfaced via Workers.) It's written in Typescript, with core proprietary/performance critical sections compiled to server-side WASM. WASM code will never be released unless enterprises are willing to pay through the nose, but the rest of the typescript components I do plan on licensing the source code, though under a license that does not allow modification of most parts. It's mainly for auditing purposes.

I've architected it so that only the core code is under /src, all cloudflare infrastructure/etc are in /worker etc. Currently I publish /src to JSR to be used as Deno/Bun/Node package imports. I am beginning to think this is a mistake b/c it exposes premium functionality that can be run locally, though ultimately all API calls are funneled through the Cloudflare Wokers APIs. All web API calls require API keys for tracking, billing, and usage charges.

There are a few ways the library can be used:
- Strictly as an SaaS offering with a web UI frontend, also hosted as a CF worker. This is for general users and power users who don't want to run the library locally.
- Every web API has an equivalent CLI switch, so the library can be run as a standalone process callable by local code via CLI.
- Embeddable as a Deno/Bun/Node package, though ultimately all API calls again get funneled through CF for tracking.

The issue is that if you have the source code, it would be very easy to modify it to bypass web API calls, which initially was by design so that businesses/enterprises can modify the code, but I'm now realizing this could be ripe for abuse, especially since it's a JSR package easily importable via Deno/etc. Or if you purchase a library license to embed, you can bypass the web API entirely which isn't ideal b/c even w/ a developer license, I still want everything funneled through CF to bill for usage. I will *always* bill usage fees, plus I want to be able to track everything.

That being said, I do want to offer extremely basic functionality for free, though this would be just a couple of core APIs with no CF infrastructure support whatsoever. Basically, it's just a tiny library that you're expected to build your own infrastructure around. Or I may charge a small monthly fee, or a flat license fee...though this is inconsequential to the architecture.

So, my architecture questions are as follows:

1. Should I just write a client façade library in a compiled language like Rust or C# that provides the basic functionality above for free (still tracked with API keys) along with all of the other web API calls, tracked via API keys, which are licensed and billed since ultimately everything from the façade calls the CF Workers?
2. Extract a core library in Typescript (since most of the library code is Typescript) and offer that as a separate public Github repo, and publish *that* to JSR? This core library would then be embedded by me into the larger library, which is a private github repo. This is a layered/composition approach.

For #1, this would eliminate the possibility of embedding the library via JSR, and I would yank all of the JSR versions and delete the scopes. I would design the façade to be embeddable since both .Net and Rust have hooks almost any other code can use, so it would still be embeddable, just not available via Deno/Node/etc via JSR. To me this is the simplest solution, and ultimately fulfills the requirement that everything gets funneled through CF for billing/etc. It would also be extremely easy to write and would require zero architectural changes to the core libraries.

For #2, this provides more flexibility and would allow developers to use existing package import runtimes, however, since it's hosted on JSR, the source code is available for the core library. I would also have to rearchitect the libraries to extract the core free features, and then embed that library into my existing private monorepo.

I'm leaning towards #1 b/c I wouldn't have to create a new github repo, and it would only be available for download/usage via a signed license agreement (free or not.) I can also write generator code to ensure feature parity between the façade wrapper API calls and the APIs hosted in CF (I would use OpenAPI Generator, or Kiota, etc, to generate code, so minimal intervention needed on my part, it could be included as part of the CI process.

#2 provides more flexibility though, at the expense of vastly increased complexity, in addition to having to rewrite my existing libraries to accommodate hosting the core free library. But, it would be easier for developers to use since you can use existing TS/JS package managers to import it from JSR, but I have no idea how to enforce usage tracking since the code would execute locally and web API calls could be bypassed.

I am not interested in a hybrid of the two models as it's overkill and adds way too much complexity, and adds two more github repos (one in the monorepo, and a new public repo.)

The final hurdle is I've had potential enterprise customers request support for an airgapped runtime model. That would completely eliminate all web API calls so I would have to come up with a new billing model or use the façade from above, but then the façade would need to be hosted in a model that supports network calls. This makes me think the façade should be both embeddable, CLI, and able to be run as a standalone network callable process, e.g. gRPC or something similar to minimize latency. I think I can reuse the façade for this scenario since it would act as a proxy.

My SaaS offering is a private monorepo on Github, written natively for Cloudflare as a set of composed Worker services (along with dozens of other CF services, but the APIs are surfaced via Workers.) It's written in Typescript, with core proprietary/performance critical sections compiled to server-side WASM. WASM code will never be released unless enterprises are willing to pay through the nose, but the rest of the typescript components I do plan on licensing the source code, though under a license that does not allow modification of most parts. It's mainly for auditing purposes.

I've architected it so that only the core code is under /src, all cloudflare infrastructure/etc are in /worker etc. Currently I publish /src to JSR to be used as Deno/Bun/Node package imports. I am beginning to think this is a mistake b/c it exposes premium functionality that can be run locally, though ultimately all API calls are funneled through the Cloudflare Wokers APIs. All web API calls require API keys for tracking, billing, and usage charges.

There are a few ways the library can be used:
- Strictly as an SaaS offering with a web UI frontend, also hosted as a CF worker. This is for general users and power users who don't want to run the library locally.
- Every web API has an equivalent CLI switch, so the library can be run as a standalone process callable by local code via CLI.
- Embeddable as a Deno/Bun/Node package, though ultimately all API calls again get funneled through CF for tracking.

The issue is that if you have the source code, it would be very easy to modify it to bypass web API calls, which initially was by design so that businesses/enterprises can modify the code, but I'm now realizing this could be ripe for abuse, especially since it's a JSR package easily importable via Deno/etc. Or if you purchase a library license to embed, you can bypass the web API entirely which isn't ideal b/c even w/ a developer license, I still want everything funneled through CF to bill for usage. I will *always* bill usage fees, plus I want to be able to track everything.

That being said, I do want to offer extremely basic functionality for free, though this would be just a couple of core APIs with no CF infrastructure support whatsoever. Basically, it's just a tiny library that you're expected to build your own infrastructure around. Or I may charge a small monthly fee, or a flat license fee...though this is inconsequential to the architecture.

So, my architecture questions are as follows:

1. Should I just write a client façade library in a compiled language like Rust or C# that provides the basic functionality above for free (still tracked with API keys) along with all of the other web API calls, tracked via API keys, which are licensed and billed since ultimately everything from the façade calls the CF Workers?
2. Extract a core library in Typescript (since most of the library code is Typescript) and offer that as a separate public Github repo, and publish *that* to JSR? This core library would then be embedded by me into the larger library, which is a private github repo. This is a layered/composition approach.

For #1, this would eliminate the possibility of embedding the library via JSR, and I would yank all of the JSR versions and delete the scopes. I would design the façade to be embeddable since both .Net and Rust have hooks almost any other code can use, so it would still be embeddable, just not available via Deno/Node/etc via JSR. To me this is the simplest solution, and ultimately fulfills the requirement that everything gets funneled through CF for billing/etc. It would also be extremely easy to write and would require zero architectural changes to the core libraries.

For #2, this provides more flexibility and would allow developers to use existing package import runtimes, however, since it's hosted on JSR, the source code is available for the core library. I would also have to rearchitect the libraries to extract the core free features, and then embed that library into my existing private monorepo.

I'm leaning towards #1 b/c I wouldn't have to create a new github repo, and it would only be available for download/usage via a signed license agreement (free or not.) I can also write generator code to ensure feature parity between the façade wrapper API calls and the APIs hosted in CF (I would use OpenAPI Generator, or Kiota, etc, to generate code, so minimal intervention needed on my part, it could be included as part of the CI process.

#2 provides more flexibility though, at the expense of vastly increased complexity, in addition to having to rewrite my existing libraries to accommodate hosting the core free library. But, it would be easier for developers to use since you can use existing TS/JS package managers to import it from JSR, but I have no idea how to enforce usage tracking since the code would execute locally and web API calls could be bypassed.

I am not interested in a hybrid of the two models as it's overkill and adds way too much complexity, and adds two more github repos (one in the monorepo, and a new public repo.)

The final hurdle is I've had potential enterprise customers request support for an airgapped runtime model. That would completely eliminate all web API calls so I would have to come up with a new billing model or use the façade from above, but then the façade would need to be hosted in a model that supports network calls. This makes me think the façade should be both embeddable, CLI, and able to be run as a standalone network callable process, e.g. gRPC or something similar to minimize latency. I think I can reuse the façade for this scenario since it would act as a proxy.

EDIT: Only the core /src directory is published to JSR, all cloudflare infrastructure code is not. Only core functionality is contained in the /src directory, but that includes most of the business logic, but not web API calls.

I have an SaaS offering I'm putting the finishing touches on, and am wondering what the best architecture is to allow limited core functionality for the core library, and paywall premium features? My first thought is to require an API key for all API calls to the SaaS web service, but I also need to account for airgapped installations where API keys cannot be validated via web api calls. Currently, every web API request requires an API key regardless of tier so I can track usage/etc.

All libraries are hosted on a private Github mono-repository, but I also publish to JSR to allow for developers to use the libraries locally via Deno package imports, however, I only want a very limited subset of the functionality to be free, with premium features requiring a paid monthly subscription + usage fees. The app is hosted on Cloudflare, and every API that is exposed locally also has a web API counterpart, and every API call requires an API key which is checked at runtime to verify the user has the appropriate license. The same library code hosted on Cloudflare is what you get if you import the package from JSR via Deno/Bun/Node/etc, so any code that is executed via web APIs can also be executed locally.

I want to expose a very limited subset of functionality for the imported package for free, with extra functionality only available for paid license holders via a monthly subscription. My initial thought was to extract the core functionality into something like app-core, which is then imported into the premium library as an embedded package, with the app-core available in a public github repo and having only that repo exported to JSR. But, I still want to track usage regardless of subscription tier. For premium source code, I will be charging a fee.

I don't want to publish the source code for the premium library, hence why it's a private github repo. So do I layer the private github repo on top of the public limited core github repo, or do I publish the whole thing to JSR (assuming that's even possible for a private github repo) and gatekeep every API call with API keys and check at runtime? That exposes all of the source code though, and only a limited subset of the source code should be available for free.

The other issue is that the core library could be used in airgapped scenarios where internet access isn't available, which is why I'm wondering if having a limited core package is the better option? I realize I can't track usage then, but I don't want developers to be able to download the entire source code. If airgapped scenarios weren't required, I'd just put everything behind API key checks and limit functionality that way (which is my current architecture) but I've had customers request airgapped support.

Or should I change the entire architecture to a facade library that contains local code for the limited free features and paywall premium features behind API key checks, with the full set of libraries executed in cloudflare workers. Or offer two libraries: One free library that is self-contained, which can then be embedded in the premium library? That still doesn't solve airgapped scenarios though b/c some airgapped installations will want the premium features, but how to A) check usage for billing and B) track said usage?

Or do I just not support airgapped scenarios? I didn't account for airgapping in my initial architecture, and I want to ensure the limited features are available for free, but still be able to bill for airgapped premium features. What's the best architecture to account for all of these scenarios?

The app is written in typescript, with most premium features compiled to web assembly on the server side. The web assembly code will always be proprietary with no initial plans to offer that source code, though at some point I will offer a paid subscription to the webassm code for enterprise customers down the road. Webassm will be executed on the server and not in the browser, at least not initially. Currently it's a monorepo with several cloudflare workers hosting the runtime code, and each library is self-contained and monolithic with a simple dependency model. If you were to have access to the private repo and could download the source code, you'd basically have the entire set of code that runs on cloudflare able to be run locally via Wrangler.

I feel like my architecture is flawed as my assumption is this would always be run on Cloudflare via web APIs called from a web UI, but I want to offer developers the option to run it embedded, but only via web API calls. The airgapped architecture requests are throwing me for a loop as all execution was assumed to be called through cloudflare workers. The requests for airgapped installations are minimal and would not have a big impact on my bottom line, but I hate turning customers away, but I'm far enough along that changing my architecture to accommodate airgapped requests would require several more weeks of work.

The bigger question is how to layer the free vs premium libs though. Currently every request from a local library run via CLI or embedded calls into the cloudflare worker web APIs with API key checks done to check subscription tier, and logging usage. I'm inclined to just not support airgapped installations, but the architecture is an intriguing question b/c it's not something I've thought about architecting prior to now. Or am I overthinking this? The SaaS itself is geared towards general users via the web UI, and developers/admins via local usage by importing via Deno/etc, I just want to ensure I'm not exposing the entire proprietary codebase without everything going through web API calls. The web UI is a facade, but the libraries have all of the source code, but not available via github or JSR, but I want to expose a very limited freemium subset for basic usage.

I'm putting the finishing touches on a SaaS offering, and I'm planning on selling resource consumption based subscriptions (via Cloudflare): What's an acceptable markup rate? On top of basic fixed cost monthly subscriptions, this is going to be the main source of revenue. Invoices will show detailed line items for resource consumption, so clients will see the markup. Or do I charge some sort of service/usage fee as a separate line item?