New maintainer about mst-gql

[DonnyVerduijn]

I honestly feel that MST or at least its philosophy, deserves more attention, but it might also need to incorporate for the needs that we have today. In my opinion, the future efforts into MST-GQL, should also be considered by taking that perspective.

If we compare MST to Solid.js and more specifically its Store API, we see that MST certainly benefits certain usecases, where it avoids reinventing the wheel. Solid.js its API actually refers to the use of the "createMutable" store factory method, for interop with external systems like Mobx or Vue, so it is reasonable to assume they understand there is a limit to what they should offer themselves.

That being said, i think that flexibility is key and the concept of having multiple stores, and the ability to combine them would be paramount to its success.

There's also a question how large the API surface should be, and which problems it is going to solve. One of the major features of MST, is the ability to reactively traverse the graph by index and create computed properties, where the API allows for a clear separation between the view model and the view.

Having interop with GraphQL stays relevant, because what is the point of enabling traversal without being able to populate the store? However we also have to acknowledge the popularity of tRPC because it is cutting down on ceremony and provides OOTB client/server type safety.

I'm fully aware this is far beyond what is possible under MST-GQL. It would require a different project, but is possibly relevant to consider, given we might want to consider such a project to be a direct replacement?

[beepsoft]

@DonnyVerduijn, thanks for your comments!

I agree, tRPC is great, but it is only viable if your backend is in TS/JS.

With GraphQL + MST-GQL you can have your backend of choice. Of course, if you have to write your GraphQL backend "by hand" that is a struggle. I myself use MST-GQL exclusively with Hasura, which gives me instant Graphql on Postgresql (Mysql, etc.) or any REST (OpenAPI) endpoint, plus you can plug your own functions (Postgresql or Javascript) and expose it via GraphQL.

With such automated GraphQL API generators the DX with MST-GQL gets quite close to tRPC. The only ceremony is the regeneration of the MST-GQL client classes, but that could also be automated when your backend (in case of Hasura most of the time: when your datamodel) changes.