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