Time to market is pretty important in this day and age, but sometimes this paradigm is exploited to such a degree that a total rewrite of the entire codebase is necessary for the business to grow larger. And exactly this can, in the end, cost more money than spending a little more time on the product.
It stands to reason that it's a good idea to be on the lookout for tools that can lower the time to market, but keep up high code quality.
I believe GraphQL to be such a tool.
GraphQL is a concept developed to help define the communication between a client, and a set of backend services.
Basically, GraphQL defines a schema, and this schema serves as a contract between the clients and the data/backend layer.
As to not to implement this abstraction yourself, in the examples provided in this post, I will be using a very specific set of tools that I would argue really makes you write less code for more functionality.
GraphQL is a sort of abstraction. It tries to give a way of declaring and structuring a backend service so the service gives a contract that different frontend clients can use.
The structure of a GraphQL query
A sentence that you would undoubtedly have heard if you know about GraphQL is
Ask for what you need, get exactly that
In this example, I have asked my service to find me the user with an id of 1 and return me the name of that user.
Notice how good a GraphQL query reads, when you just go over it line by line.
This means that a frontend developer can, with the GraphQL schema in hand, without endless swagger/openAPI doc surfing develop the features he wants, and get only the data he needs.
Not only is this a win in terms of data sent over the wire, but also in the sense of the developer experience.
But when this is said, GraphQL also provides a whole new way of thinking about resources.
Rest
In the traditional REST-like API's a resource traditionally has a specific path on the API, and the interactions with that resource is a subset of paths extending on the original, example:
get a User: /user/
get a User with id 1: /user/1
This is fine, but as an application grows these endpoints go from 5-10 to 100-1000 different endpoints, which the developer, pretty much without any meaningful help, has to figure out precisely which of those endpoints fits his need.
GraphQL
GraphQL however only specifies a single endpoint: typically /graphql, and from there you do a request for the data you need.
A consequence of having a typed schema means that developers can get help on which resources are available on the schema, and even use the editors IntelliSense capabilities to figure which fields are available on the type.
The power of Zeus, except for autocomplete
There are even tools that live while coding will introspect the backend schema and will, in the editor, show you the fields available, and the types of those fields, and even generate types for the exact queries written.
This reduces the type maintenance there is with having to write and upkeep rest endpoint types.
And let me tell you: the first time that you do and get a list of data available is extremely satisfying.
In two weeks, I will be posting another blog post about how to realize what I have written about here using
- Language: Typescript
- Server: NexusJS
- Frontend-UI: React
- Frontend-Network: Apollo-client
Top comments (0)