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?
1 Like
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.
3 Likes
I suppose it offers convenience on front end, but apollostack.com advertises some of it’s perks, with an article in documentation explaining the why part towards the bottom if you can’t tell any better. Mocking is a big plus that im adopting now (test data generation).