Show HN: Celest – Flutter Cloud Platform(celest.dev)
celest.dev
Show HN: Celest – Flutter Cloud Platform
https://celest.dev/
49 comments
I played around with Flutter a couple years ago for a project that required a mobile app, and walked away really impressed with Flutter and Dart. It's a much, much nicer language for building UI in compared to React Native and even the native languages. But the backend story with Dart was very much neglected. I got the feeling that Flutter's main developers at Google were the driving force behind Dart development, and the lack of backend adoption for Dart at Google was causing it to wither on the vine for backend purposes.
Is the ecosystem support improving here? People end up needing libraries for all kinds of backend stuff, not just auth and SQL like you have on your roadmap. What about sending emails, hooking into payment providers / billing, queues/pubsub, observability...? Doesn't this need to exist first, to make building backends in Dart feasible, before building a framework that makes it easier?
Is the ecosystem support improving here? People end up needing libraries for all kinds of backend stuff, not just auth and SQL like you have on your roadmap. What about sending emails, hooking into payment providers / billing, queues/pubsub, observability...? Doesn't this need to exist first, to make building backends in Dart feasible, before building a framework that makes it easier?
The ecosystem support is improving, and still needs help. I think we can drive both in parallel so that the framework feeds use cases to the ecosystem which then lead to more complex backends. It's hard to put one before the other, but can be a really powerful flywheel.
Although it's not listed on my landing, it is absolutely a goal of Celest to be a funnel for these use cases and partner with the community as we go to fill the gaps.
Although it's not listed on my landing, it is absolutely a goal of Celest to be a funnel for these use cases and partner with the community as we go to fill the gaps.
Looks interesting. What are your plans for the backend - will self-hosting be an option?
Right now this looks fine for a hobby project, but massive lock-in/risk for production (what if you shut down, get bought up etc?).
Right now this looks fine for a hobby project, but massive lock-in/risk for production (what if you shut down, get bought up etc?).
Great points.
My immediate plan for reducing lock-in is to provide the option to deploy into a cloud account you manage. This has the upside of making your deployed infrastructure independent of Celest and letting you use your cloud credits.
Self-hosting is another option I'm considering, but I don't have a good sense yet of what that could look like. Any thoughts? Is spitting out a binary/Dockerfile sufficient to alleviate risk?
If I get shut down, I'll be open-sourcing all my code. And regardless, I plan to open source more and more of the platform over time.
My immediate plan for reducing lock-in is to provide the option to deploy into a cloud account you manage. This has the upside of making your deployed infrastructure independent of Celest and letting you use your cloud credits.
Self-hosting is another option I'm considering, but I don't have a good sense yet of what that could look like. Any thoughts? Is spitting out a binary/Dockerfile sufficient to alleviate risk?
If I get shut down, I'll be open-sourcing all my code. And regardless, I plan to open source more and more of the platform over time.
Committing to open-source the code (and provide detailed instructions on how to run the code) in case the company shuts down is the most important. It could be part of the service contract. I've read all parts of the Celest code which are public, and I can attest it's very well-written and easy to understand.
> It could be part of the service contract.
Agreed. I'll look into how we can add that.
Agreed. I'll look into how we can add that.
[deleted]
I just listened to a podcast episode of the Flying High with Flutter podcast [1] where Celest founder, Dillon, was on as a guest. He came across as capable, hungry to get Celest out into the world, and focussed on solving problems around running dart in the cloud. All the best, Dillon, I'm looking forward to see where Celest goes!
[1] https://podcasts.apple.com/us/podcast/celest-the-flutter-clo...
[1] https://podcasts.apple.com/us/podcast/celest-the-flutter-clo...
That looks cool, reminds me of long ago when I happily used Heroic, even though Celest is very different.
Question: I know a few Clojure enthusiasts who really enjoy Clojure+Dart backend. Is Celest compatible for this workflow?
Question: I know a few Clojure enthusiasts who really enjoy Clojure+Dart backend. Is Celest compatible for this workflow?
Interesting! I don't know much about using Closure and Dart together. Any projects you could point me to? Sounds like a cool use case.
Hi, ClojureDart co-author here. Join us on #clojuredart of the Clojurians slack, we will help.
Can code in `celest/functions` import from lib?
We cou
Question for OP:
Obviously you are committed to Flutter and Dart.
Where do you see it going, broadly?
I’ve used Flutter a small amount and enjoyed it.
But it’s a hard sell to commit fully to it.
The alternatives of native tooling on iOS, Android and the web are not contentious choices.
Whereas suggesting to a team or decision maker that Flutter is the right choice seems like it could be an uphill battle!
As a solo dev making choices for clients that want a cross platform solution I can pitch Flutter as a somewhat rational choice against the cost of seperate builds for iOS and Android. Maybe, depending….
Then there’s the Google factor… what if they get bored and kill Flutter!?
Obviously you are committed to Flutter and Dart.
Where do you see it going, broadly?
I’ve used Flutter a small amount and enjoyed it.
But it’s a hard sell to commit fully to it.
The alternatives of native tooling on iOS, Android and the web are not contentious choices.
Whereas suggesting to a team or decision maker that Flutter is the right choice seems like it could be an uphill battle!
As a solo dev making choices for clients that want a cross platform solution I can pitch Flutter as a somewhat rational choice against the cost of seperate builds for iOS and Android. Maybe, depending….
Then there’s the Google factor… what if they get bored and kill Flutter!?
These are reasonable concerns.
Having seen the development of Flutter and its ecosystem over the past 7 years, I've come to really believe in the framework and its mission. There have been lots of companies which have found success building with Flutter [1] and it very often speaks to their bottom lines [2].
I'm hopeful for its continued success, but more importantly, I believe that having more companies building enterprise solutions makes the technology more attractive and practical to adopt. The founder of Flutter has started Shorebird [3] and the FlutterFlow team recently closed a $25M Series A [4]. These are great investments to have into Flutter.
Another cool stat: Dart was the fastest growing programming language among all languages last year at 33%! [5]
All that to say, I believe the business value of Flutter is becoming clear and I think having more companies building on top will reduce adoption risk and create a very rich ecosystem for further progress.
[1] https://flutter.dev/showcase
[2] https://assets-global.website-files.com/5ee12d8e99cde2e20255...
[3] https://shorebird.dev/
[4] https://techcrunch.com/2024/01/11/flutterflow-attracts-cash-...
[5] https://www.developernation.net/resources/reports/state-of-t...
Having seen the development of Flutter and its ecosystem over the past 7 years, I've come to really believe in the framework and its mission. There have been lots of companies which have found success building with Flutter [1] and it very often speaks to their bottom lines [2].
I'm hopeful for its continued success, but more importantly, I believe that having more companies building enterprise solutions makes the technology more attractive and practical to adopt. The founder of Flutter has started Shorebird [3] and the FlutterFlow team recently closed a $25M Series A [4]. These are great investments to have into Flutter.
Another cool stat: Dart was the fastest growing programming language among all languages last year at 33%! [5]
All that to say, I believe the business value of Flutter is becoming clear and I think having more companies building on top will reduce adoption risk and create a very rich ecosystem for further progress.
[1] https://flutter.dev/showcase
[2] https://assets-global.website-files.com/5ee12d8e99cde2e20255...
[3] https://shorebird.dev/
[4] https://techcrunch.com/2024/01/11/flutterflow-attracts-cash-...
[5] https://www.developernation.net/resources/reports/state-of-t...
When I go to flutter examples and go to the first one
https://flutter.github.io/samples/web/material_3_demo/
I find everything is rendered in a canvas. This means it's not accessibility friendly. It means none of my extensions work. It means no text can be selected (for example clicking the 3rd icon from the top left labeled "Typography". It also means none of the Browser/OS level features are available. I can't select a word and pick "look up" or "define" or "speak". It's shows ugly monochrome non native emoji. It takes second to show non-English characters while it downloads non-English fonts
How is this a win for the user?
https://flutter.github.io/samples/web/material_3_demo/
I find everything is rendered in a canvas. This means it's not accessibility friendly. It means none of my extensions work. It means no text can be selected (for example clicking the 3rd icon from the top left labeled "Typography". It also means none of the Browser/OS level features are available. I can't select a word and pick "look up" or "define" or "speak". It's shows ugly monochrome non native emoji. It takes second to show non-English characters while it downloads non-English fonts
How is this a win for the user?
I can’t speak for web but mobile apps written in Flutter are accessible https://docs.flutter.dev/ui/accessibility-and-internationali....
I downloaded the flutter sdk abd built a sample app. it had the similar issues to the web app.
Flutter tooling is superior to that of native iOS and Android development. It's not just about the cost savings from avoiding separate builds: Developing a Flutter app is generally easier than developing a separate app for either Android or iOS. And the developer experience is way better too.
Google is not killing Flutter. Despite Google's rep, Flutter is a highly successful project that Google uses for many of its own products, including Google Pay, Google Classroom, and Google Ads. It's also used by other major companies: https://flutter.dev/showcase.
Google is not killing Flutter. Despite Google's rep, Flutter is a highly successful project that Google uses for many of its own products, including Google Pay, Google Classroom, and Google Ads. It's also used by other major companies: https://flutter.dev/showcase.
Hey folks, I've created an open source app example using Celest, complete with tests and all. If think it demonstrates Celest use quite well. Here it is:
https://github.com/marcglasberg/SameAppDifferentTech/tree/ma...
https://github.com/marcglasberg/SameAppDifferentTech/tree/ma...
Neat! Looks like you are using Flutter for the web front-end, is that right?
I remember folks complaining about Flutter in the browser. Did that get fixed to an acceptable degree? And does that obviate the complexity of typical SPA framework on the frontend? With similar power?
I remember folks complaining about Flutter in the browser. Did that get fixed to an acceptable degree? And does that obviate the complexity of typical SPA framework on the frontend? With similar power?
Right now, we're using Docusaurus, which has been working well: https://github.com/celest-dev/website
Though, Flutter Web has come a long ways recently, especially with the WASM work that's underway [1][2]. Flutter is very well positioned, I think, for web applications requiring a lot of interactivity and complex layouts--the DX is phenomenal. For static sites, it's very hard to beat a pure HTML/CSS/JS stack in terms of speed and optimization potential.
That being said, I think there's a good chance we'll see more work on Dart web frameworks going forward. Projects like Zap[3] and Jaspr[4] and doing great work in this area already. And it's safe to say we may see a Celest Web framework one day!
[1] https://flutter.dev/wasm
[2] https://flutterweb-wasm.web.app
[3] https://pub.dev/packages/zap
[4] https://pub.dev/packages/jaspr
Though, Flutter Web has come a long ways recently, especially with the WASM work that's underway [1][2]. Flutter is very well positioned, I think, for web applications requiring a lot of interactivity and complex layouts--the DX is phenomenal. For static sites, it's very hard to beat a pure HTML/CSS/JS stack in terms of speed and optimization potential.
That being said, I think there's a good chance we'll see more work on Dart web frameworks going forward. Projects like Zap[3] and Jaspr[4] and doing great work in this area already. And it's safe to say we may see a Celest Web framework one day!
[1] https://flutter.dev/wasm
[2] https://flutterweb-wasm.web.app
[3] https://pub.dev/packages/zap
[4] https://pub.dev/packages/jaspr
Thanks, believe you answered my question, though I may not have been clear enough before.
I was asking about the demo app as shown in the video on the marketing site. The kinds of apps we'd be expected to build with this. Was not asking about the marketing site itself, though it seemed nice enough.
I was asking about the demo app as shown in the video on the marketing site. The kinds of apps we'd be expected to build with this. Was not asking about the marketing site itself, though it seemed nice enough.
Ah, gotcha! The choice to use Flutter Web in the demo was just for presentational effect. Celest is built to work with all of the Flutter platforms equally.
Thanks. Is flutter required, or can we use Dart to return html, json, etc?
Flutter is currently required for the parent app, but I'll be lifting that requirement very soon. Stay tuned!
Great work Dillon!
As you know the current setup with langpal's API is literally just next API routes from the marketing site. Bit of a strange and hacky coupling haha.
Can't wait to see and use this!
As you know the current setup with langpal's API is literally just next API routes from the marketing site. Bit of a strange and hacky coupling haha.
Can't wait to see and use this!
Excelent news! Excuseme but where can i manage my free celest-cloud? i could run celest deploy with success but now i dont know how to use it and keep with the testings :D
Glad to hear you ran a successful deploy!
Currently we just have the CLI to manage your account, although I'm working on a web-based dashboard for better accessibility.
The result of a deployment is just a URL, which is automatically placed in your generated client (see `celest/lib/client.dart`). To switch to this new environment, pass the production arg to your `celest.init` call like this:
Currently we just have the CLI to manage your account, although I'm working on a web-based dashboard for better accessibility.
The result of a deployment is just a URL, which is automatically placed in your generated client (see `celest/lib/client.dart`). To switch to this new environment, pass the production arg to your `celest.init` call like this:
void main() {
celest.init(environment: CelestEnvironment.production);
runApp(MyApp());
}
Just to clarify what Dillon said:
When you do `celest deploy` it sends your current code to the cloud. After that if your code contains: `celest.init(environment: CelestEnvironment.production);` it will use that code you just sent to the cloud. If your code contains `celest.init(environment: CelestEnvironment.local);` it will use the code you have in your local machine.
But in practice you develop locally, so you don't need to deploy all the time.
Also, you can call `celest.init` as many times as you like, while the app is running, to change from local to cloud and vice-versa, on the fly!
When you do `celest deploy` it sends your current code to the cloud. After that if your code contains: `celest.init(environment: CelestEnvironment.production);` it will use that code you just sent to the cloud. If your code contains `celest.init(environment: CelestEnvironment.local);` it will use the code you have in your local machine.
But in practice you develop locally, so you don't need to deploy all the time.
Also, you can call `celest.init` as many times as you like, while the app is running, to change from local to cloud and vice-versa, on the fly!
We love Celest! This is the future of flutter.
The free plan says it includes
"5,000 function invocations / project"
I presume that's per month, not just 5000 free then pay up?
How does this compare to hosted AppWrite, which also lets you write backend cloud functions in Dart?
I presume that's per month, not just 5000 free then pay up?
How does this compare to hosted AppWrite, which also lets you write backend cloud functions in Dart?
Per project, per month, yes. Felt like a mouthful to write, but I'll make that more clear.
Celest's biggest strength with cloud functions is its integration with the Dart language. The CLI generates a strongly-typed API client for you which matches the declaration of your function, and handles all serialization out-of-the-box.
So, if you write a top-level Dart function like this
Celest's biggest strength with cloud functions is its integration with the Dart language. The CLI generates a strongly-typed API client for you which matches the declaration of your function, and handles all serialization out-of-the-box.
So, if you write a top-level Dart function like this
// In `celest/functions/my_api.dart`
Future<String> sayHello(String name) async => 'Hello, name!';
celest.functions.myApi.sayHello(name: 'Celest'); // Hello, Celest
How do you handle versioning? Are there any guidelines/rules one must abide by?
It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
Do you support protobuf/cap'n'proto?
It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
Do you support protobuf/cap'n'proto?
> How do you handle versioning? Are there any guidelines/rules one must abide by?
Versioning is not fully fleshed out yet, but we have an open issue for it here: https://github.com/celest-dev/celest/issues/4
It's a problem I want to tackle correctly, so that you'd need to put as little thought into it as possible. It should "just work". Vercel's skew protection [1] stands out as a recent example of doing this well.
> It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
JSON was chosen as the primary serialization format for the reasons mentioned here [2]. Primarily, familiarity to Flutter developers, availability of JSON-compatible types in the wild, and integration with non-Dart clients.
The JSON structure is outlined here (working on a full spec): https://celest.dev/docs/functions/http-requests
built_value types can be used in Celest currently by giving the class `fromJson`/`toJson` methods. I haven't implemented auto-serialization for them, yet, but it should be straightforward. I've used built_value heavily in the past and agree there's no better alternative for some use cases.
> Do you support protobuf/cap'n'proto?
In the future, I plan to support more serialization formats, including protobuf and binary protocols. I will check out cap'n'proto, it was not yet on my radar.
[1] https://vercel.com/docs/deployments/skew-protection
[2] https://x.com/dillonthedev/status/1749806407510381054
Versioning is not fully fleshed out yet, but we have an open issue for it here: https://github.com/celest-dev/celest/issues/4
It's a problem I want to tackle correctly, so that you'd need to put as little thought into it as possible. It should "just work". Vercel's skew protection [1] stands out as a recent example of doing this well.
> It looks like you using Flutter's Dart<=>JSON serialization; do you recommend using built_value for immutable data structures?
JSON was chosen as the primary serialization format for the reasons mentioned here [2]. Primarily, familiarity to Flutter developers, availability of JSON-compatible types in the wild, and integration with non-Dart clients.
The JSON structure is outlined here (working on a full spec): https://celest.dev/docs/functions/http-requests
built_value types can be used in Celest currently by giving the class `fromJson`/`toJson` methods. I haven't implemented auto-serialization for them, yet, but it should be straightforward. I've used built_value heavily in the past and agree there's no better alternative for some use cases.
> Do you support protobuf/cap'n'proto?
In the future, I plan to support more serialization formats, including protobuf and binary protocols. I will check out cap'n'proto, it was not yet on my radar.
[1] https://vercel.com/docs/deployments/skew-protection
[2] https://x.com/dillonthedev/status/1749806407510381054
Just got the email with access! Congratulations to the you and team on the launch. Looking forward to trying it out.
Much appreciated!
[deleted]
I appreciate the free plan, any goals on adding celest to homebrew and chocolately?
What is the difference to Serverpod?
can you elaborate here so I get a better view?
Yes, absolutely. The main differences are
1. Celest is fully managed and does not require any knowledge of the cloud. With Serverpod, you must have a cloud account and manage your own infrastructure.
2. In Celest, all of your backend and infrastructure logic is defined solely in Dart. This differs from Serverpod which incorporates technologies like Docker, Terraform, and YAML to define your backend.
There are similarities too. Celest will auto-generate a client library for you like Serverpod and provides a local development environment. Uniquely, though, Celest supports hot reload for your backend ;-)
1. Celest is fully managed and does not require any knowledge of the cloud. With Serverpod, you must have a cloud account and manage your own infrastructure.
2. In Celest, all of your backend and infrastructure logic is defined solely in Dart. This differs from Serverpod which incorporates technologies like Docker, Terraform, and YAML to define your backend.
There are similarities too. Celest will auto-generate a client library for you like Serverpod and provides a local development environment. Uniquely, though, Celest supports hot reload for your backend ;-)
I'd say the developer experience is completely different. With Celest you can almost pretend you are writing the frontend and backend code as one single codebase. And then you change a flag and the part of your code that needs to be in the cloud is moved to the cloud, seamless. I think you have to try it out to really grok how much easier it is.
At AWS, I built the Amplify Flutter framework and saw the extraordinary power (and complexity) the modern cloud presents. I wore many hats in that role, but the hat I most disliked was devops. I just wanted to write my business logic and have it work.
As a Flutter developer, I love writing Dart, and I want to use it everywhere. But in order to do so today, it requires stringing together Docker, Terraform and a healthy dose of cloud expertise to make it work. I built Celest so that I never have to use anything but Dart in my backends, and so other Flutter developers won’t either!
Celest brings infrastructure-from-code to Dart in a way that’s fun to write. Cloud functions are just top-level Dart functions and the inputs and outputs are automatically serialized for you. Run celest start to spin up a local environment with hot reload, and celest deploy to deploy to our managed cloud in under a few minutes. A type-safe client is generated for you as you build to create an RPC-like interface for your backend.
Celest currently offers serverless functions, authentication, and authorization. Our goal for the coming months is to further offer an offline-first SQL database and ORM. One cool thing about our authorization mechanism is a novel token format which combines Google’s Macaroons [1] with the Cedar policy language [2] for expressing caveats. I call them Corks! https://github.com/celest-dev/celest/tree/main/packages/cork...
You can download the CLI at https://celest.dev and play in a local environment for free with no sign ups. The client runtime is open-sourced as BSD at https://github.com/celest-dev/celest. There are some examples here: https://github.com/celest-dev/celest/tree/main/examples.
Check us out and let us know what you think!
[1] https://research.google/pubs/macaroons-cookies-with-contextu...
[2] https://www.cedarpolicy.com/en