dnys1
commented
4 months ago Hey @marcglasberg, what a cool idea!
I think this makes a lot of sense, and in fact, I had never considered that the generation of a client library could be an out-of-the-box means of distribution in these cases 😄
A few things we would need to figure out would be:
- Would the end-user still be calling
celest.initand usingcelest.functionsetc.? Or would we need another client (either generated or manually written) which wraps this up nicely and whitelabels the service? - Currently the Celest client only exposes
.functionsbut in the future, we may havecelest.auth,celest.models, etc. Seemingly, these would not all be useful to end-users and the owner would want to limit which methods are exposed. - How would end-users authenticate to the service? Would it be through API keys that Celest vends on your behalf? Would people want more sophisticated auth mechanisms on top of this in the future?
I really love this idea because one of our driving principles has always been to build Celest in such a way that one could eventually rebuild Celest in Celest 😄 this is a great exposition to some of those steps needed.
marcglasberg
I want to be able to provide SaaS for companies that use Celest in their apps, and charge for them. When publishing my Saas with
celest deployin the store, I'd provide ayamlfile (or better yet, Dart code) to create a store page in the Celest website, much likepub.devdoes for Flutter.I'd have 4 pieces of software:
<name>_frontendin pub.dev: A package projects can include inmy_app/pubspec.yaml<name>_backendin pub.dev: A package projects can include inmy_app/celest/pubspec.yamlExample
For example, suppose I'm Harry Potter and I want to provide a SaaS that allows apps that use Celest to have magic features in their apps. In this example I'd publish:
celest_magic_frontendin pub.devcelest_magic_backendin pub.devA Celest service that gets requests from those packages, does magic in the server, and sends the magic to the frontend package, so that it's displayed to the user in the app. Note: The companies that added my SaaS to their apps DO NOT have access to the source code of my Celest service. They simply use the service.
The Celest database must have different access settings depending on the project: Only I have access, or I can choose to let the client company to have access too.
Pricing
Celest wouldn't charge anything for the store listing, but it would make money because the Celest is being used by the service and the Celest database.
Celest would charge the client company directly, not the SaaS service provider.
Celest would add an extra on top of its bill to the client company, to pay the SaaS service provider. That extra would be chosen by the SaaS service provider, and it could be a combination of: (i) a fixed monthly value; (ii) a % of the regular bill the client is paying Celest. For example, I could choose to be paid $5 plus 10% over Celest's normal cost. If the Celest regular bill would be, say $150 in a month, Celest would charge the client $150 + $5 + 0.1 * $150 = $150 + $5 + $15 = $170. I'd get $20.
Rules
It would be great if Celest could provide rules for pub.dev packages that are in the Celest store. For example, how should I name my packages:
celest_magic_frontendandcelest_magic_backendcelest_magic_flutterandcelest_magic_servermagic_for_celest_frontendandmagic_for_celest_backendShould there be a rule like this?: First thing you must say in the package docs in pub.dev is that it's a third-party service not provided by Celest, and that Celest is not responsible for anything, damages, etc etc; and then link to the Celest store.
Note
This is not hypothetical. I already have a service that I want to provide for Celest client companies.