I have a bit of a dumb question: where does GraphQL fit in a stack? I've seen in used primarily as a means of aggregating a bunch of disparate microservices, but then I see things like this that put it in the role of app server, almost. What advantages does this give over, for example, a Rails API (also on Postgres)? If it is supposed to fill the role of app server, how do you handle things more involved than simple CRUD operations? Like, if I sign up a user, how -- in a GraphQL world -- would I send a welcome email, typically?
The most prevalent use case for GraphQL right now is to act as a thin API layer over a bunch of microservices (which is what Facebook originally developed it for) -- but that is not the only use case.
GraphQL is actually much less than a replacement for a REST API. Its really just a type system with an execution engine that can map queries against that type system to resolvers (functions). That's it. This means that you can actually use it all over the place:
- Because it provides a strongly typed interface, you could use GraphQL as the basis of an RPC protocol (infact, GraphQL doesn't specify a transport mechanism, since its only job is to map queries to functions, so you could send GraphQL queries over RabbitMQ if you wanted to.. or encode them with protobuf and send them via HTTP/2).
- You could use a GraphQL schema to define the internal object model of an application and use GraphQL internally as a data access layer. You don't even have to expose it outside your codebase.
- You can use the tooling that comes with GraphQL (at least in the Node.js implementation) to parse incoming queries into their abstract syntax trees and to all kinds of fun stuff with them (automagically stitch multiple GraphQL schema's together into a combined API).
- I'm actually working on a proxy layer that can actually sit on top of an existing GraphQL API and apply additional logic to the incoming request and outgoing responses (it would actually be a good fit as a business logic layer for a Hasura based GraphQL api)
I think that in the future we'll see lots of very interesting uses of GraphQL that go beyond is current status as "REST API replacement"
*To answer your question "if I sign up a user, how -- in a GraphQL world -- would I send a welcome email, typically?" -- Define a mutation (update method) in your GraphQL schema to create a new user. Inside the resolver (function that is executed) for that mutation, write code to create a user (API call? Database update?) and send an email (drop a message in a queue to your email sending serivce?). It works just like it would for any other application codebase, you just initiate process with a GraphQL query, instead of, say an HTTP Post to a REST API.
We’re experimenting with it on a new product at my company, and this is how we use it. Specifically, we use it as an API gateway in front of a bunch of restful services.
Another benefit is a more robust type system than you get with JSON. GraphQL supports union types, interfaces, etc., allows you to provide more strongly typed contracts between the backend and frontend.
One downside though - while the responses can become smaller, with fewer round trips, the requests get A LOT bigger (than with REST), as you have to specify every field, subfield, etc. This is especially true if you make heavy use of union types - then you have to specify all the fields, sub fields, etc. of all the various concrete members you might get back. Like requests with payloads over 1KB is not uncommon. If you’re polling, and the result of the polling is generally an empty response, you may end up sending significantly MORE data over the wire, not less.
There could be 2 ways to solve that specific problem of sending a welcome email:
1) Write a GraphQL schema stitching gateway, that can write a custom mutation that delegates to another API (or GraphQL API) to write to the database, or writes to the database directly. This is becoming popular as more backend services expose their functionalities via GraphQL.
2) React asynchronously after the database write is done. Put the database event in a queue, for example, that runs the email send async-ly.
In practice it is like exposing a very limited interpreter directly to the public internet. Instead of working with resources and limited verbs and hypermedia or SOAP (which is literally just documents) you allow clients to submit what are essentially programs with are then evaluated. In other words its mobile code all over again. [1]
well yeah, there is a reason why graphql gets called 'sql for web services' after all.
but I wasn't trying to draw a parallel between implementations...
while you're obviously right that the implementation and the way you actually interface with GraphQL is very different from REST, just like that differed from SOAP, its nonetheless the same use-case.
They're all communication protocols between different software components.
I believe it's intended as an API gateway, a means of creating a single front-facing web API for one or (usually) more back-end services. That way, clients can pick and mix apis and the data they want from it (e.g. streaming posts for mobile, or 20 posts at a time for desktop), without a developer having to create a REST / Rails API endpoint for each possible use case / client.
I always thought it was in the name- a web API standard inspired by SQL over a graph data structure. This way, rather than having to predefine API endpoints that are super customized, you define fewer that follow the standard and act as a standard interface. Like if HTTP client = ODBC and GraphQL = SQL.
