Carta Operum

Journal ◆ Server

One set of models from phone to database

What sharing Dart classes between Flutter and Serverpod buys, and what it costs.

In Galley a restaurant, a menu item and an order are defined once, in a Serverpod model file. The generator writes the Dart class for the server and the one for the Flutter app, with the database table and the serializers on the way. A field added on Monday is in the phone's code on Monday.

The benefit is not typing saved. It is the class of bug removed: the app and the server cannot disagree about whether a price is a number or a string, or whether a courier may be null. The compiler finds the mismatch before a reviewer or a user does. Endpoints are typed the same way, so a client call is a method that returns a model, not a map to be picked apart.

The cost is coupling. Releasing the server may mean a new client, and an old app in a pocket will meet a new field. I treat every change to a model as a change to a public API: add fields as optional, retire them slowly and keep the migration reversible. With that discipline the shared models are the least troublesome part of the stack.