A typed query language will definitely help for anything you store either locally or remotely. In this case, it would provide information to compiler to do most of the type checking for you.

It is not only GraphQL itself I had in mind though. It is also about implementing a client library similar to Apollo GraphQL where you can provide watch queries wrapping your UI components. Watch queries provide great developer ergonomics for handling the flux data flow, that is, whenever there is a change to your data in store, if the corresponding elements in datastore are watched by a query, the UI components wrapped by this watch query are re-rendered with new data, automatically.

I think this combination will help desktop development by helping to reduce boilerplate code and by providing a convention to development team. We enjoy this combination already in web UI development for the last one year, in our team.

I think GraphQL is useful for getting data for UIs on any platform.

- build views without being blocked waiting for a new rest endpoint

- get exactly what the UI needs to render

[edit]

Although to negate my own first point, nb4 being blocked on waiting for new mutations and queries :P

Native applications don’t need that, though. Modern languages embrace async/await and don’t waste cycles or block the UI or even the backend unnecessarily waiting for network/local IO or user interaction.

In that regard, rust is actually behind. Async/await is still coming.

Native applications don’t get blocked waiting for backend engineers to implement a new REST endpoint?

Native applications don’t benefit from smaller responses of just the data they need to render a view?

I am confused.

Also, you can use it to query local data too.

This enables you to transparently move data-source around.

That’s a good point! Never thought about local data sources. I’ve only mapped over SQL, REST, and redis/etc.