Choosing an API for my Flutter app

When comparing REST, GraphQL, and gRPC for a Flutter app, I found it more useful to start with a screen than with a protocol.

What does the screen need to show? Which operations change data? Does anything need to stream? Those questions give the comparison something concrete to work with.

For the project I researched, the recommendation was HTTP/JSON with OpenAPI, generated Dart clients, and read responses that bring together the data a screen needs. That was a design recommendation. I hadn’t run a benchmark proving one protocol faster than the others.

OpenAPI describes an HTTP API in a machine-readable contract. I like the prospect of using that contract to generate the repetitive client code and catch mismatches earlier.

GraphQL becomes more interesting when clients repeatedly need different selections of connected data. Its query model addresses that need directly. I would want to see those differences in actual screens before taking on the additional API design work.

gRPC deserves a look when streaming or a shared service definition is central to the application. It doesn’t need to win a general popularity contest to be useful for a particular system.

The decision I want to record is the reason for the choice. What requirement made this approach a good fit? What change would make me reconsider it?

That leaves a more useful note for the future than a declaration that one protocol is best. When the application’s requirements change, I can revisit the argument instead of defending an old preference.