[dillonnys]

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]

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]

> 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