[HN Gopher] Show HN: Celest - Flutter Cloud Platform
___________________________________________________________________
Show HN: Celest - Flutter Cloud Platform
Hi HN! I'm Dillon, the founder of Celest (https://celest.dev).
Celest is a backend-as-a-service that lets you build full-stack
Flutter and Dart apps without leaving your IDE. There's a short
demo video here: https://www.youtube.com/watch?v=Evs1f0zHpzk 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
Author : dillonnys
Score : 83 points
Date : 2024-04-01 14:00 UTC (8 hours ago)
(HTM) web link (celest.dev)
(TXT) w3m dump (celest.dev)
| adityathakurxd wrote:
| Just got the email with access! Congratulations to the you and
| team on the launch. Looking forward to trying it out.
| dillonnys wrote:
| Much appreciated!
| DerCommodore wrote:
| What is the difference to Serverpod? can you elaborate here so I
| get a better view?
| dillonnys wrote:
| 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 ;-)
| marcglasberg wrote:
| 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.
| mark_l_watson wrote:
| 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?
| dillonnys wrote:
| 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.
| moomoo11 wrote:
| How long have you been working on it? Looks cool
| dillonnys wrote:
| Thanks! I started working on it in November, but most of the
| effort has been over the past three months.
| Alifatisk wrote:
| I appreciate the free plan, any goals on adding celest to
| homebrew and chocolately?
| dillonnys wrote:
| Yes, I definitely want to at some point. In the short term,
| I've implemented a `celest upgrade` method in the CLI, so it's
| just a one-time manual install.
| dgellow wrote:
| Winget would make more sense than chocolatey
| Alifatisk wrote:
| Right, it doesn't matter in my case
| flax wrote:
| 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?
| dillonnys wrote:
| 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
| // In `celest/functions/my_api.dart` Future<String>
| sayHello(String name) async => 'Hello, name!';
|
| and save the file, you'll get a Flutter client which you can
| call as celest.functions.myApi.sayHello(name:
| 'Celest'); // Hello, Celest
|
| 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.
| gresrun wrote:
| 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?
| dillonnys wrote:
| > 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
| evanlance wrote:
| 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
| dillonnys wrote:
| 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:
| void main() { celest.init(environment:
| CelestEnvironment.production); runApp(MyApp());
| }
|
| 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/celest
| marcglasberg wrote:
| 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!
| e12e wrote:
| 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?).
| dillonnys wrote:
| 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.
| marcglasberg wrote:
| 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.
| dillonnys wrote:
| > It could be part of the service contract.
|
| Agreed. I'll look into how we can add that.
| mradek wrote:
| I really like flutter and dart. All the best with this Dillon!
| dillonnys wrote:
| Cheers!
| ruben_burdin wrote:
| We love Celest! This is the future of flutter.
| marcglasberg wrote:
| 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...
| hemmert wrote:
| Just what I needed for my next moonlight project :) Happy to try
| this out and give you feedback!
| dillonnys wrote:
| Nice! Glad to hear it :-)
| circafuturum wrote:
| 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...
| mixmastamyk wrote:
| Neat! Looks like you are using Flutter for the web front-end, is
| that right?
|
| I remember folks complaining about the 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?
| dillonnys wrote:
| 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
___________________________________________________________________
(page generated 2024-04-01 23:00 UTC)