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?
Show HN: Celest – Flutter Cloud Platform
11–20 of 50 posts
Re: Show HN: Celest – Flutter Cloud Platform
#12How long have you been working on it? Looks cool
Re: Show HN: Celest – Flutter Cloud Platform
#13I 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?
Re: Show HN: Celest – Flutter Cloud Platform
#14The 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?
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 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.Re: Show HN: Celest – Flutter Cloud Platform
#15Re: Show HN: Celest – Flutter Cloud Platform
#16Excelent 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
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/celestRe: Show HN: Celest – Flutter Cloud Platform
#17Right now this looks fine for a hobby project, but massive lock-in/risk for production (what if you shut down, get bought up etc?).
Re: Show HN: Celest – Flutter Cloud Platform
#18The 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?
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` F…
It looks like you using Flutter's DartJSON serialization; do you recommend using built_value for immutable data structures?
Do you support protobuf/cap'n'proto?
Re: Show HN: Celest – Flutter Cloud Platform
#19Looks 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?).
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.
Re: Show HN: Celest – Flutter Cloud Platform
#20Earlier quoted context omitted.
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` F…
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?
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 DartJSON 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.