New maintainer
beepsoft opened this issue · comments
Hi all,
I just got maintenance rights to the repo from @mweststrate and will try my best to contribute to the progress of mst-gql.
I made attempts to contact the current (or former) maintainers, @jesse-savary and @Benz19, through all available communication channels without success, therefore, I haven't had the opportunity to discuss their objectives for the project. Nevertheless, I want to thank you guys for your work so far!
Considering the lack of development, communication, and new releases for 15 months, I decided to pick up where they left off, because I don't want to see mst-gql die.
I occasionally use mst-gql in my projects, and when I do, I often find the time - and the need :-) - to improve mst-gql itself, whether it's to address bugs or to add new features. My aim is to review and merge PRs, address bug reports, and engage in discussions about new features with the community - in a best effort manner.
Some time ago, Jesse initiated several discussion topics that are still of interest, and I would like to invite all of you to participate, particularly regarding features you wish to see in v1.0.0 or any challenges you face while using mst-gql.
- Request for Comment: Towards mst-gql v1.0.0
- Announcement: Looking for Trusted Reviewers
- Request for Comment: Supporting Legacy (0.x.x) Versions
Looking forward to your contributions and discussions!
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?
@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.