Since its public release in 2015, GraphQL has been on the rise both in popularity and widespread use. The addition of the data graph changed the development process forever, bringing together data and services in a comprehensive and secure way. An ever-growing number of companies have recognized its vast capabilities, with such entities as Shopify, Microsoft or Yelp adding GraphQL to their development stacks.

GraphQL is alive and well, but how did it grow from a hermetic language used by very few to a widely recognized, almost indispensable tool? It wouldn't be here without quite a few success stories surrounding it.

A perfect example would be a recent migration of Airbnb's API. It has been discussed at length by [Brie Bunge, one of their software engineers, at GraphQL summit](https://www.youtube.com/watch?v=pywcFELoU8E\&feature=youtu.be), where she described the process in some detail. I wanted to take a look at some of the distinct advantages of using GraphQL in these operations in the hope that you, dear reader, might find a solution to one of your problems.

![Migrating from REST to GraphQL](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/graphql-restapi.webp)

##### Source: [undraw.co](https://undraw.co/)

## Better data access

The adoption of GraphQL for their API resulted in quicker access to data and a much more enjoyable interface. Thanks to the step-by-step approach to migration, with hardly any downtime during the whole process. Instead of trying to convert preexisting code at once or even rebuilding from the ground up, Airbnb opted for gradual changes. Consequently, this allowed for a smooth transition without the need to put any services on pause.

## Over-fetching problem

Another improvement gained through switching over to [GraphQL](https://graphqleditor.com/) was the significant reduction in over-fetching. The data has been shaped in a way that doesn’t allow for requesting any more than is needed in a particular instance. This severely reduces unnecessary costs that may have been incurred beforehand, something that must be considered when designing data architecture.

After the whole conversion process was complete, the result was a dependable, streamlined and far-reaching tool. It is able to quickly and reliably access requested data by combining the strengths of its components while getting rid of needlessly complicated code. Furthermore, should the need arise, Airbnb’s implementation of GraphQL is ready to be scaled within reason. According to [Adam Neary](https://medium.com/@AdamRNeary), another software engineer at the aforementioned company, other benefits [include](https://medium.com/airbnb-engineering/reconciling-graphql-and-thrift-at-airbnb-a97e8d290712):

* a strongly typed API schema,
* flexibility in field selection,
* cross-platform client-side development

... and many more.

Despite the indisputable gains from using [GraphQL](https://graphqleditor.com/), this project is far from complete. There are numerous improvements that can be developed sooner or later.

By reshaping the schema into a more data-centric one, they hope to cut down on duplicate requests, further increasing the efficiency and speeding up the caching, which has been a major bottleneck up till then.

This is but one of many examples of GraphQL being a prime choice for data handling at a major company. Nearly a thousand businesses from various branches using this language for all their dealings with queries, showing just how flexible and efficient it is.

The advantages of migrating to GraphQL

One of the core notions of using [GraphQL](https://graphqleditor.com/) is a schema. It strictly defines the potential an API might have by forming a set of concepts and relations between them. Another crucial function of a schema is regulating how and by using which action data can be accessed.

Designing a schema is one of the first steps in the development process, casting a shadow over the following tasks. Due to how many areas are affected by a schema, later on, its architecture should be carefully planned. This, hopefully, leads to a naturally evolving, intuitive, and most importantly secure product.

[![GraphQL Schema](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/schema-1730849614480.webp)](https://graphqleditor.com/)

##### Source: [undraw.co](https://undraw.co/)

## Scaling

Attempting to adjust a project which wasn't designed with greater scope in mind can be quite a headache. Adding something which seems inconspicuous to the end-user may involve a long list of tedious tasks. Deprecating pre-existing concepts, adding new ones only to be renamed a while later, keeping track of what has and what has not been yet modified. This process only gets more complex with every such change required. This can be avoided by following a few simple rules in scalable schema design.

[![Scaling schema-based project is easier](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/scale-1730849610896.webp)](https://graphqleditor.com/)

##### Source: [undraw.co](https://undraw.co/)

##### Keep it simple

The goal of using [GraphQL is to create something transparent](https://graphqleditor.com/blog/what-offers-graphql-api/), easy to understand for everyone involved. However, this is made impossible if a schema can be compared to a labyrinth of connections and sources of data. Think about the developer who comes after you have moved on to other projects. An example of good practices can be using input object type for mutations.

##### Force yourself to be adaptable

To avoid the aforementioned headache in scaling, a schema should be easily adjusted to specific, often unforeseen, requirements. It is often the case that many concepts must be deprecated at once, whereas other ones need to be added without breaking the rest. A good way of doing this is using the tools given by [GraphQL](https://graphql.org/) itself, as opposed to creating one's own. Custom-made tends to be more convenient at the time, but it is less comprehensive looking from the outside.

##### Be creative & specific

Being a little bit more creative when designing a schema tends to pay off in the long run. Instead of going for the easy way out and using something generic, make the type name more specific. When in doubt, consult other people involved in the project, they may have some interesting ideas about how and for what reason you should name a concept in a certain way.

## Security

Carelessly drawn-up schemas may create various possibilities for malicious attacks in different ways. An example of such behavior is exposing data in unanticipated ways.

![Schema security is a crucial issue](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/security-1730849617496.webp)

##### Source: [undraw.co](https://undraw.co/)

##### Think about proper pagination

One of the preventative measures can be proper pagination. This is a feature which is not provided by the language itself, it is mostly left to the imagination of the developer. There are many different ways in which pagination can be implemented, which makes the choice that more difficult. It is imperative to take into account the needs of the project, rather than personal preference.

##### Don't overload the client-side

Allowing the clients to manipulate data is generally frowned upon since it can give birth to a multitude of issues. It is a much better idea to keep as much as possible server-side, most preferably batched in a single large request, as opposed to multiple small ones. This has a two-pronged effect: reduces the amount of data that needs to be repeatedly loaded, and simplifies the result for the end-user.

Do not leave schema design to chance. Make it a group project, spend a couple of sessions together, brainstorming ideas and collaborating with everyone who has something to do with all the data. Hopefully, this leads to a good schema:

* one that is functional,
* malleable and easy to understand.

Future you will surely thank you later.

***

* A guest blog post for [GraphQL Editor blog](https://graphqleditor.com/blog/) by Carl Matte;
  Sources: [Do’s & Don’ts for your schema and GraphQL operations](https://www.youtube.com/watch?v=fG8zy1OROp4), [atheros.ai](https://learning.atheros.ai/blog/graphql-best-practices-for-graphql-schema-design), [apollographql.com](https://www.apollographql.com/blog/backend/schema-design/graphql-building-evolvable-schemas)

How a well-planned schema can change your project?

Whether weaved into an already existing application, or included as an integral part of an application's architecture from day one, an API is a powerful tool in a developer's arsenal. When properly implemented, it can be quite an important factor when it comes to designing the user experience, communicating between software components and providing the building blocks themselves.

However, an unsatisfactory API may become more of a curse rather than a blessing:

* it can drive up the costs,
* case security problems,
* raise project’s complexity & deteriorate the ease of use in general

Let’s take a look at ways in which GraphQL can help avoid some of the pitfalls of making an API.

### Schema as a source of truth

If not carefully planned out, an API architecture can start bleeding money by ever-increasing management and infrastructure costs. GraphQL tackles this problem by forcing its developer to prepare a clearly defined schema ([GraphQL Editor comes in handy](https://graphqleditor.com/)) and, at the same time, limiting the amount of data returned specifically to the requested scope. Designing a schema should incorporate various ideas from a multitude of people working on or with the API in order to create a broad scope of possible use-cases. Due to the fact that schemas naturally evolve by deprecating some fields and adding new ones, this makes GraphQL an elegant answer to swollen, cumbersome APIs. The previously mentioned narrowing of data returns solves the common issue of over-fetching.

### GraphQL makes it simpler

Another cause for a headache that a potential developer might encounter is excessive complexity combined with convoluted documentation. It is of the utmost importance to know how something behaves in certain conditions and why it works in a particular way. This is made nearly impossible, or at least not cost-effective, if the developer cannot find the answers that are sought in the documentation surrounding an API. GraphQL, having been adopted by many communities around the programming world, has the benefit of a continuously growing and largely active developer base. This greatly enhances the experience a potential engineer might have as it makes finding the right tools for the job quite simple.

### Security

Security needs to be taken into consideration. It is quite likely that an API can be explored by certain individuals as a possible gateway to extracting sensitive data or harming the application in other ways. Allowing such malicious attacks to affect the intended user can really tarnish one’s reputation as a reliable programmer. Although GraphQL allows for limiting the scope of possible queries to a prearranged whitelist, there are other, more flexible ways of handling the problem. Setting a cap on how many requests can be made in any given period of time is a common preventative measure for DDoS attacks.

![GraphQL Security](https://graphqleditorcms.fra1.cdn.digitaloceanspaces.com/graphqleditorcms/blogpost/security-1730848290879.webp)

##### Source: [undraw.co](https://undraw.co/)

### Conclusion

The very nature of GraphQL appears to solve many of the issues plaguing a plethora of other APIs. Furthermore, should any other problems arise, they will have surely been already tackled by the rich and vibrant community which surrounds this query language. These factors combined make GraphQL a very appealing option when considering implementing an API.

##### Sources:

##### [MarvelApp.com](https://marvelapp.com/blog/why-marvel-uses-graphql/)

##### [Netlify.com](https://www.netlify.com/blog/2020/01/21/advice-from-a-graphql-expert/)

##### [Devops.com](https://devops.com/challenges-of-designing-api-driven-experiences/)

Posts by Carl Matte