Spring GraphQL : GraphQL Done Right

In the past, I have written about the issues with GraphQL implementations (which are abundant for the frameworks for languages such as Python, Javascript, PHP and other scripting languages).

But I was totally surprised and caught offguard when Spring came out with a GraphQL version that solved alot of the issues that previous GraphQL implementations had.

With Spring GraphQL, I am beginning to see the first solid GraphQL implementation I have ever seen and this is looking good enough to actually use in a business environment. For example:

  • not a separate layer : Spring made the code integrated so that there are no additional calls and overhead. The code is fully integrated and acts as your api (not as a separate layer interfacing with your api)
querymapping example

As you can see in the image above, @QueryMapping replaces @RequestMapping to allow for a fully integrated GraphQL (instead of a separate layer like ALL other implementations). This is a vast improvement and decreases the overhead to nothing more than that of a regular API.

  • resolvers more like ORM: Since it is an integrated environment, the resolvers act more like ORM. If you are familiar with Hibernate, this will not be something out of the ordinary for you and simplifies the mapping of your data.
datafetcher example

And the lack of integration that previously caused issues in other GraphQL frameworks are all resolved in Spring GraphQL:

  • no dynamically generated biz logic : In some GraphQL implementations I have seen, the business logic is dynamically generated making the resolvers a direct link to your database so that GraphQL’s ‘query’s are literally nothing more than database queries allowing people to mine your database. THIS IS NOT THE CASE IN Spring GraphQL! You have full control over the return dataset in your controllers so that you can be 100% OWASP compliant
  • Caching/Rate Limiting/etc?? : Because you are using CONTROLLERS as you previously did in a regular API implementation, all previous services/filters/interceptors/etc will work the same when doing a request/response because this is 100% integrated!
  • Additional processing?? : Because Spring integrated their GraphQL implementation and had it act as the endpoints (rather than having it call existing endpoints), the overhead processing is less than minimal. This is a far better (and faster solution) than existing GraphQL implementations.

I shouldn’t be surprised by this because this is Spring and they have extremely bright engineers… but I still am. And this is perhaps the BEST and ONLY GraphQL implementation worth using. At least for me. :)

If you want a GraphQL implementation for your next project, definitely go down this road because Spring nailed this one on the head and I wouldn’t use anything else at this point!

Original Amazon team member, Creator of API Chaining(R), Leader in API Automation