Today when we think about conventional web design, RESTful has become the standard in the industry for the design of API. REST is wonderful, and it or something like it is essential for the growth we see in web design today. I mean where would we be today without stateless servers or structured access to resources? While this is wonderful, times are changing and so is the tech world, needless to say, REST is having problems adapting to the new standards. So what are our alternatives? Well, we have quite a few, the big hitters being Falcor APIs, JSON-Pure APIs, OData API. Today I’d like to talk to you about GraphQL, and how it stands up to RESTful API. Let’s begin by talking about data fetching, and how this applies to performance, starting with REST.
Let’s take for example a fetch to a RESTful API for a website that displays a user and their posts. Conventionally to reach such an endpoint we would have to hit multiple endpoints to display this information. Typically we would start with an HTTP GET request to the endpoint/users/<id>, we would do this to grab the single user and the attributes assigned to this particular user. Next, if we wanted to get this user’s post we would then have to hit the GET endpoint of /user/<id>/posts to reveal the posts this user made. Even further if we wanted to access some other information of the user we would have to make another request to another endpoint. While this may seem tedious, this is the standard access protocol for a RESTful API, which we’ve been using for quite some time. Now let’s look at GraphQL For this we simply send a single query to the GraphQl server with the defined parameters, and in return, we get a simple JSON object with all the information included. For example:
Using GraphQl the client can simply state with data they want to grab from the server, with one trip. This greatly cuts back on Over and Under fetching, which has a massive impact on Big O notation.
The next best thing about GraphQl is the structure of its API. Typically in a RESTful API when changes need to be made to the database, this can be quite the hassle. Rollbacks are needed and version control, and depending on the direction of the company, it might be necessary to bring in a whole team, just to make the branch of the new API. Time and asset consuming, right? Well, let us discuss A schema type that you might find in GraphQl. A schema server is a contract between the client and the server to define how a client can access the data. What this means is once the schema is defined, the frontend and backend teams can do their work without communication, because they both have a definite structure of the database over the network. This adds a world of wonder to front end production, mostly on efficiency. If changes need to be made, the schema is simply updated by adding or deleting what is needed, nothing more, nothing less. While these are just a few of the great wonders of schema-based databases, there are many more. I encourage you to dig deeper into this type of database, as it could improve your companies productivity.
