When is it recommended to use GraphQL for a Ruby on Rails app with React?

Before we dive into the question at hand, I have to get something off my chest. Do not be seduced by technology. Do not adopt a new tool because it’s trending. GitHub and Facebook left REST behind for GraphQL. Don’t assume if it worked for them, it’ll work for you. Here, you have failed to factor in your context. In simpler words, what do you want GraphQL to do for you? This might seem like an obvious point, but before embracing new tools, you must educate yourself on its advantages and disadvantages.

What is GraphQL?

GraphQL is a language used to define how two applications talk to each other. You define data types, then actions to perform on those data types. If you want a fancier definition, GraphQL is a language for manipulating and querying data. See, in GraphQL the response format is described in the query and defined by the client instead of the server. That’s why they are called client‐specified queries. To put it another way, if your application needs data and JSON is the answer, then GraphQL is the question.

GraphQL is a great way of asking the question because it aligns the way you fetch data to the way product developers and designers think about consuming data. Remember GraphQL is a specification between the client and the server. It is not specific to any one programming language. Any client should be able to communicate with any server if they speak GraphQL.

The Facebook story

GraphQL was created by Facebook to solve some of the challenges they faced while scaling the world’s largest social network. Therefore, no article on GraphQL is complete without the Facebook story. Up until around 2007, Facebook was a web-centric company. This was before mobile phones took the world by storm and companies realized these smartphones were not just a new fad, but something here to stay. Here on out, Facebook and many other companies had to change their strategy and rearrange everything from the technology they practiced to the approach they used for mobile development.

Facebook started by building HTML5 mobile apps in a Native view to fit their web content into smartphones. The experience for people using Facebook’s mobile apps at this time was predictably terrible. Web browsers on smartphones just couldn’t keep up with the complexity of Facebook’s app. You see, they still practiced a Mobile Afterthought and not a Mobile First strategy. In 2012, Facebook started building native mobile applications. They didn’t just rewrite their mobile apps from the ground up. They rethought the entire technology stack.

With these changes in the stack, the center of gravity shifted to the user’s device, which was a smartphone in most cases. The web tier became more like an app server. Facebook removed Restful API’s with a plethora of end points and mega endpoints since it became unmanageable over time. They realized Rest API’s weren’t the way to go because most mobile developers think regarding user interface design and not in terms of resource URLs. You see, when you think about fetching data, you’re thinking of graphic data. This was Facebook’s realization, so they developed GraphQL, a query language for, well, graphs of data.

The core principles

GraphQL at its core is like a type system. The server owns a type system, and the type system expresses all the capabilities of the server. When the client has requirements, the server broadcasts the capabilities. The client asks for stuff during the runtime, and the server knows what’s possible, and the client knows what it needs. This approach allows the clients and servers to evolve and scale independently from one another.

 GraphQL enables a new contract between the server and client. With GraphQL now, you have to support multiple content types(XML, JSON, etc.). While REST provides you a uniform interface between the client and server, meaning they speak in the same format.

The Composition is another important principle. GraphQL can co-locate and build up a mega query which is single query serviced by more distinct backends or internal requests. Here, with GraphQL you will have to consider a case where one of them may fail, but there is a simple solution. Split up the queries.

Where is GraphQL useful?

1. Combining data from multiple points is a huge advantage of GraphQL and so is the flexibility it provides you in your data model.
2. In Rest API’s you have to version your API to evolve, whereas GraphQL allows you to evolve without versioning. This means your API becomes less resource hungry and cleaner.
3. GraphQL has a flexible response format. This helps when your mobile or web client needs to avoid further queries and a massive data transformation.
4. Use a GraphQL server to make it easy for your mobile client developer to change the response format without any need to ask for changes on the backend.
5. With GraphQL, you get to describe the required data in a more natural way, which is why GraphQL is known for speeding up app development.

The pain points

1. The lack of clear documented use-cases tends to be a problem. Remember API documentation is more than the description of its interface contract along with an inventory of queries and objects. The API and its documentation together are the key for a good developer experience.
2. With REST API’s, you could rely on HTTP’S caching system, but when it comes to GraphQL, this option is no longer there. You have to depend on the Client to handle the cache. This might not be a problem in the future as GraphQL evolves.
3. GraphQL requires a data loader to be efficient. With GraphQL, you have to state what you want explicitly. This means on each request the consumers have to send an entire query. Complex, massive requests could impact your infrastructure if you have a lazy developer.
4. It’s hard to find and stick to good naming conventions for queries, mutations and the arguments for them all. The good news is there are enough articles on good naming practices to help you through this issue
5. Some GraphQL users face a problem with the complexity Relay adds to their data model.

Is it recommended to use Rails, React and GraphQL together as a tech stack?

It’s difficult to give you a yes or no answer without understanding the problem you’re trying to solve. If React provides a technological advantage for a particular project that merits its use, then it’s worth ensuring the success of that implementation, although it’s doubtful whether React alone will provide the necessary technical infrastructure. See, React is awesome for building front-end applications.

Now Rails is perfect for the backend. It doesn’t do anything “innovative” on the front-end. For a project that requires a backend which boasts of a reliable well-documented database along with a history of stability and steady growth, Rails is the way to go. Rails and React both works very well together.

Now GraphQL is a great option to opt for when you have a dynamic front-end. It decouples your front-end developers from your back-end engineers, enabling both to make their queries to get the data they need without relying on each other. Take Facebook’s case, they prototype a lot, so this saves them time by eliminating some of the back and forth communications between their backend and front-end developers.

This should help you make a more informed decision on when to use GraphQL in your next project.