GraphQL is NOT API Automation

GraphQL is receiving alot of buzz recently with people calling it ‘API Automation’ when all it REALLY automates is ‘schema stitching’… and that isn’t even part of the spec or approved by it’s creators:

“Schema stitching is only one technique of many that some GraphQL users employ and I don’t advocate it personally.”

So as a comparison, we did a side by side comparison with several GraphQL frameworks and an API Automation Framework to see how they compare on functionality. Below is what we found.

The Frameworks

First lets supply a list of frameworks that we compared. We wanted to work with some of the most commonly used GraphQL implementations that are in use today by users (and vendors) to show a fairly common set of features as well as address some of the issues and concerns.

We also are showing against an API Automation framework whose features have been adopted by Netflix, VMWare and other major companies and a good comparison of what is possible.

• Apollo GraphQL : Apollo is a GraphQL server for node.js providing a plethora of functionality for testing and maintaining your GraphQL server.
• Prisma GraphQL : Prisma is also a node.js server that has good auth functionality as well as webhooks.
• BeAPI Framework : BeAPI advertises itself as an API automation framework wherein most of your setup is handled through IO state files (what GraphQL users would define as ‘schema’).

So now that we have briefly introduced each, lets quickly define what we mean by automation. The dictionary defines automation as:

Automation : (noun) the technique, method, or system of operating or controlling a process by highly automatic means,as by electronic devices, reducing human intervention to a minimum.

In other words, automated functionality should not require you to write code; it should be handled for you. This is how automation works.

With that in mind, lets take a look at some of the functionality of these systems:

Webhooks : Apollo documentation does not cover Hooks/webhooks and Prisma covers Hooks/Webhooks but requires coding the solution. BeAPI automates this functionality on the backend so the only thing that is needed is to add a ROLE to your IO State for the endpoint to allow access for the token. No coding required.

Batching : Apollo does not have an implemented solution nor does Prisma. Again, BeAPI is the clear winner by requiring zero coding by the developer for batch API calls. BeAPI automates this functionality on the backend and the only thing that is needed is to add a ROLE to your IO State for the endpoint to allow access for the token. No coding required.

Chaining : While GraphQL implementations implement this with ‘schema stitching’, they do not automate it; a schema must be created defining how the chain works. Proper automation can ‘stitch’ automatically based on: (1) What endpoints the user has access to and (2) The primary and foreign keys of these endpoints. BeAPI does the stitching automatically on the backend allowing users to chain endpoints dynamically without defining schemas.

Mocking : Apollo does do mocking but it requires actually handcoding it in and is not required. Prisma does not address mocking in its docs. BeAPI can autogenerate the mocks and IO state based on your database.

Authentication/Validation : Apollo does not cover authentication in its docs. Prisma requires alot of configuration to be able to get authentication to work. BeAPI automates this functionality on the backend. There is no setup.

API Doc Generation : BeAPI automates this functionality on the backend and the only thing that is needed is to add a ROLE to your IO State for the endpoint to allow access for the token. No coding required.

Final Thoughts…

As you can see, GraphQL is NOT AUTOMATION by any stretch of the imagination. Everything it does requires a developers to code something to do it. Nothing is automated.

API automation frameworks on the other hand actually provide automation out of the box! Thats what automation is about; your developers should not have to figure things out or code solutions; they should be provided in a single solution for them. THAT is automation.

Anything else posing as automation is simply that… a poser.