I have recently implemented GraphQL as an enhancement to an existing REST microservice application (written in Akka HTTP Framework) and here are a few random thoughts:
- Sangria certainly makes things easy to adapt GraphQL to most Scala projects. The way the resolvers are implemented are elegant and simple; e.g. there's no explicit way of different handling whether your resolve method is a
Future[T]or just a value; it's treated the same in code. - Sangria can use existing case classes for the GraphQL objects, and provides macros to avoid boilerplate. However, there are a bunch of caveats and limitations; we are using scalaxb to generate our case classes from XSDs, and sadly these are not workable with the Sangria macros. Fortunately, with the awesome libray Chimney this makes it less painful
- Testability is dialed-up to 11. There are a lot of GraphQL clients available, but the one that I used is graphql-playground. I embedded it as a resource and route it to
GET /rest/v1/graphqland it just works with thePOST /rest/v1/graphqlout of the box. - GraphQL is cool, and extending the REST capability to have it is awesome. However, I don't necessarily agree that it's a replacement with the classic REST endpoints.
There are two use cases that is addressed by GraphQL nicely: discoverability of available data, and clarity of what the client asks for. Building comprehensive UI frontends of existing services makes a good case to use GraphQL, but for high-throughput services where the call pattern and data contracts are pre-determined, GraphQL may be overkill and presents an overhead that's unnecessary.