TreeQL vs. GraphQL

04 Oct 2018 - by 'Maurits van der Schee'

Many people compare GraphQL to REST and come to the conclusion that both have their strengths. In this post I argue that you can have the best of both worlds by using TreeQL, an improved REST protocol.

Downsides of GraphQL

According to Stubailo and Doerrfeld the downsides of GraphQL (compared to REST) are:

It's results can't be cached using HTTP caching.
It has limited endpoint security enforcement.
It doesn’t have as many tools yet.

That last point is fortunately changing fast, as GraphQL adoption is rising.

Benefits of GraphQL

According to Yegulalp and Eschweiler the benefits of GraphQL (compared to REST) are:

It reduces number of requests as related resources can be combined.
It reduces transfer size as you can request exactly what you need.
It is self-documenting by default, using a formal definition.

Sturgeon also warns us that GraphQL has false advertised benefits, such as that you "never have to version anything."

TreeQL, an improved REST protocol

TreeQL is an improved REST protocol. You could also say that it is a pragmatic GraphQL. It allows to request related entities, limit results to specific records and columns and has built-in documentation. With these it has the same benefits over REST that GraphQL has. Some of the benefits TreeQL has over GraphQL are:

It uses database reflection, so you do not need to define a schema.
It has handlers that allow you to easily implement a security model.
It uses REST with HTTP verbs and is compatible with HTTP caches.
It is documented in the OpenAPI 3 specification (formerly Swagger).

Another benefit of TreeQL is that it will feel familiar for most people. TreeQL is basically a standardized REST API with some features added to it.

Links

PS: Liked this article? Please share it on Facebook, Twitter or LinkedIn.

TQ
dev.com