Show HN: Celest – Flutter Cloud Platform (celest.dev)
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...
49 comments
[ 2.7 ms ] story [ 97.1 ms ] thread1. 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 ;-)
Question: I know a few Clojure enthusiasts who really enjoy Clojure+Dart backend. Is Celest compatible for this workflow?
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?
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
and save the file, you'll get a Flutter client which you can call as You can pass just about any Dart class between the frontend and backend, and it will just work. We're going for an RPC-style interface which means your types/parameters can never get out of sync.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?
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
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:
Let me know if you face any issues! We have a Discord (https://celest.dev/discord) server, and you're more than welcome to open a GitHub issue if you experience problems: https://github.com/celest-dev/celestWhen 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!
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?).
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.
Agreed. I'll look into how we can add that.
https://github.com/marcglasberg/SameAppDifferentTech/tree/ma...
[1] https://podcasts.apple.com/us/podcast/celest-the-flutter-clo...
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?
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
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.
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!?
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...
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?
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.
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?
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.
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!