- To build an automated translation layer from REST APIs to GraphQL (with GraphQL schema rebuilt every 5mns):
- Each service in their infrastructure was able to dynamically provide a list of REST resources running on it.
- For each of those resources, they introspected the list of endpoints and arguments (i.e. a course endpoint would have a fetch by id, or lookup by instructor).
- Received Pegasus Schemas, defined by their Courier schema language for each model returned.
- To relate resources between services/endpoints:
- developers annotated resources and relations
- Part V: Should you use GraphQL is a great summary of the tradeoffs
Happy FEDs: From a frontend developer's perspective, GraphQL is all wins.- Communication
- The schema first development, inspired by DDD and strong typed languages, forces frontend and backend devs to speak about the important things early, leaving the less important things (the implementation) for later.
- Versioning
- GraphQL offers backward & forward compatibility, which means no breaking changes, ever.
- Young
- Production ready since September 2016 only
- Most of the tutorials come from pet projects. Many tutorials on the Internet are outdated.
- When you step outside of JavaScript, GraphQL is a dangerous place.
- loose ends in the specification, no published good practices yet for pagination, filtering, metadata, and more importantly authentication
- Performance
- GraphQL servers are no faster than REST servers - they may even be a bit slower, due to the latency added by the gateway.
- Frontend devs tend to create utterly complex queries that can hit several backends and be super expensive. Backend developers must take extra care of the server monitoring, log the slow queries, use
DataLoader, and limit the allowed complexity of queries.All this requires more development, as the backend tooling is not as sophisticated as the frontend packages. - Caching: server-side caching is hard
- caching GraphQL with a reverse proxy is not straightforward
- using DataLoader below the GraphQL server doesn't save against query parsing
- GraphQL server becomes Single Point of Failure
- Logging is hard
- Use "named queries" for better logging and debugging.
- GraphQL queries are much more verbose than their REST equivalent.
- Security
- To protect a GraphQL server from DOS attacks, a team must spend at least a few more days of development.
- File uploads are not natively supported, but possible in a "hacky" way.
- Persisted Queries help mitigate caching, DOS, and logging issues. However, they complicate the deployment of GraphQL apps, since frontend and backend apps need to be synchronized.
- Summary
Most of the time: Take the leap! If the architecture is API-centric, and some of the usage is mobile.
GraphQL is a fabulous idea, a great piece of technology, and a booming community.
You may not need GraphQL immediately, but you will probably use it in the future.
But GraphQL does come with its own shortcomings. Don't expect a bed of roses, and be prepared for the extra complexity and longer development times.