Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Celest Store #45

Open
marcglasberg opened this issue Feb 13, 2024 · 4 comments
Open

Celest Store #45

marcglasberg opened this issue Feb 13, 2024 · 4 comments
Labels
triaging Initial investigation into the issue

Comments

@marcglasberg
Copy link

marcglasberg commented Feb 13, 2024

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 deploy in the store, I'd provide a yaml file (or better yet, Dart code) to create a store page in the Celest website, much like pub.dev does for Flutter.

I'd have 4 pieces of software:

  • <name>_frontend in pub.dev: A package projects can include in my_app/pubspec.yaml
  • <name>_backend in pub.dev: A package projects can include in my_app/celest/pubspec.yaml
  • A Celest service that those packages may access.
  • A Celest database that those packages AND Celest service can access.

Example

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_frontend in pub.dev

  • celest_magic_backend in pub.dev

  • A 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

  1. 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.

  2. Celest would charge the client company directly, not the SaaS service provider.

  3. 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_frontend and celest_magic_backend
  • celest_magic_flutter and celest_magic_server
  • magic_for_celest_frontend and magic_for_celest_backend
  • other?

Should 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.

@dnys1 dnys1 added the triaging Initial investigation into the issue label Feb 13, 2024
@dnys1
Copy link
Member

dnys1 commented Feb 14, 2024

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.init and using celest.functions etc.? 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 .functions but in the future, we may have celest.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
Copy link
Author

Hey, maybe we could discuss these questions and my particular use case over Zoom at some point? As I can't discuss the details of my service here.

@dnys1
Copy link
Member

dnys1 commented Feb 14, 2024

Absolutely. Door's always open! https://cal.com/celest-dev/dillon

@marcglasberg
Copy link
Author

Thanks! I'm busy until March 4, but then I'll set up a meeting in your calendar.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
triaging Initial investigation into the issue
Projects
None yet
Development

No branches or pull requests

2 participants