Spring GraphQL : Almost ‘Good Enough’
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).
And while Spring has shown themselves to be very professional, their implementation of GraphQL was good in some ways (as it solved SOME inherent issues with GraphQL)… but it didn’t solve enough to make it scalable.
Allow to to break it down…
The GOOD
- 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)
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.
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.
The BAD
- HardCoded Pathing w/ No Versioning : all api’s are requested through a path starting ‘/graphql’ with ZERO VERSIONING for your API
- Hardcoded API Naming/Methods : In trying to copy RESTful design, they force hardcoded naming/response methods which can create confusing API naming for business logic and lack of dynamism.
- Request/response data unchecked : Since the binding is at the data layer, the object being returned is always the same and unfiltered for the request/response is unchecked per Role which is in violation of OWASP: API3 :2019 (https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa3-excessive-data-exposure.md)
The UGLY ‘Truth’
- Stitching tied to schemas/subschemas
In Spring GraphQL implementation, your controllers map the schema to the API via an annotation called @querymapping. This is actually a shortcut to @SchemaMapping (https://docs.spring.io/spring-graphql/docs/current-SNAPSHOT/api/org/springframework/graphql/data/method/annotation/QueryMapping.html).
In order to access your schemas, you have to call the api endpoint. You have to validate token, pass CORS, check ROLES, etc. Calling a SCHEMA directly cannot pass these security checks!
And so when ‘stitching’, you are during a redirect for EVERY SINGLE SCHEMA you call. This creates several issues (see below):
Not only that but every redirect leaves you open to MITM attacks to listen in and intercept.
- Scalability : As always because you are adding additional layers for mapping/processing queries to apis via redirects, GraphQL is not scalable as far as API’s go. It is VERY SLOW!
Spring did a great job on resolving alot of Graphql’s inherent issue which I shouldn’t be surprised at as they have extremely bright engineers. And this is perhaps the BEST and ONLY GraphQL implementation worth using. But if you need a scalable solution, Graphql (in any form) is probably not ready for prime time yet.
If you want a GraphQL implementation for your next project though, definitely go down this road because Spring Graphql is probably the only one I would ever implement and I wouldn’t use anything else at this point!
