Given that I’m using DDP, and it’s possibly wasteful to have to send a bunch of queries instead of one what does it really give me?
Long story short, I suspect it’s meant to be easy to build with rather than an improvement given that there’s a diagram comparing meteor to graphql and there’s not a mismatch although I don’t understand what is microservice or etc.
- you can request just the data you need so it can be more efficient than a generic Meteor method
- strongly typed schema for the (graphql) API make it less error prone and easier to use (esp. with new team members)
- multiple queries can be batched in one request
- easier to maintain with new features as custom endpoints don’t have to be created (eg a new publication
- no versioning needs to happen, when fields no longer used can be deprecated so older apps can consume them without breaking but new users won’t use this field
- stateless operation allows for cheap/easy scaling (eg you wont need 1 server per 100 users)
Also in the future GraphQL will support websocket connections but, as far as I know, only tcp/http are currently supported.