I’m asking Simon Wardan, Senior Architect at Terem, a few questions about GraphQL, its pros and cons, and why we use it at Terem. Simon has extensive experience in GraphQL and he’s Terem’s expert at planning scalable and efficient tech-product architecture.
In Wikipedia, GraphQL is described as “[…] an open-source data query and manipulation language for APIs, and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015”.
In this interview, I’m answering the question “Why are so many companies taking advantage of GraphQL features for their tech products?” digging into the main aspects of this language, highlighting the pros and cons coming from our direct experience with it at Terem.
Thank you for your time, Simon. Today we’re talking about GraphQL. I have a few questions for you about this technology used by many major companies all around the world such as Facebook, Atlassian, Airbnb, Github, Twitter, and many more. So, what’s GraphQL?
GraphQL is many things. It’s defined as a query language for APIs, but it is also the runtime for fulfilling queries with your existing data, and this is what I think sets GraphQL apart.
And tell me, Simon, what are the main benefits of using GraphQL?
It allows you to request exactly the kind of data you need rather than being constrained by a particular API design. It also forms a very strong contract between the front-end and back-end because you use it in both, and it allows you to verify every single query you make against the documented schema, which is shared between the two environments.
Can you spend a few words talking about the aspects of the relationship between frontend and backend, using GraphQL?
One thing that you’ll see with frontend-backend interaction is there’s been in many cases a shift away from dealing with individual objects or collections, applying the pattern “Backends For Frontends” (BFF). So what that means is allowing your back-end to deliver content the way the front-end needs it. An example of that would be you load up a mobile app and when you load up this app, you’re maybe seeing three different things, three different types of data. Traditionally those would be three different API calls to various collections that are restful and describe specific objects. If you use GraphQL, it’s possible to get all of those data points in a single call instead.
What type of projects would take advantage of GraphQL features?
I think any Greenfield project or anything that hasn’t started yet where that layer between the front-end and back-end remains to be defined. I would say GraphQL is a very good contender for owning that layer and does a really good job of it. Also, it’s really useful in just any application where you want to abstract your data sources from how they’re consumed. You may have three or four different sources of data or services and you can have GraphQL between them and your front-ends, whether they’re web or mobile, to consolidate them. This means front-end engineers don’t need to know that there’s a service A, service B, or service C, but they can just make requests against the schema. GraphQL gives you the defined structure that you can use as well as being the actual service that delivers it. This allows teams to avoid very time-consuming activities of data definition and agreements around API contracts.
In what cases GraphQL doesn’t help?
I think it’s hard to make it a small part of a broader platform. It wants to own the layer between the front-end and the back-end. You could add GraphQL in an existing project gradually, but it’s a particular piece of technology that benefits from being across that entire layer between the front and the back it benefits from being there across the board. In terms of places where it doesn’t work, the tricky thing with GraphQL is it just does its own thing in every single possible way starting from the actual query language itself down to the protocol it uses. Traditionally with RESTful APIs, you generate different API endpoints, but with GraphQL the way it’s typically delivered is a single URL that you just send all your queries to so it breaks REST in that way. For some people, that’s a big deal and they don’t like that – That’s not a downside for me. I think it’s an interesting way of doing things and I’m not a fan of just following well-known patterns just because they will take you to a proven solution. I think it’s healthy to explore and experiment, and I think GraphQL is a successful technology in doing things differently while still achieving various solid outcomes, but it may end up being an “All or Nothing” approach where it’s hard to gradually put it in. It kind of wants to own that interface between the front-end and the back-end to do its best work. It needs to be everywhere.
Can GraphQL be used in different environments like web or mobile?
It can, yes. You can consume it from any front-end, from mobile as well as web. I’ve seen it being used for both. The one thing I mentioned is it would have been nice if it had JSON formatted responses rather than JSON-like responses. It is quite straightforward and flexible in terms of implementation into your services, but it’s very well defined and easy to follow. I would say it’s definitely an easy learning curve.
Is there anything you would improve or change in GraphQL?
One of the things I don’t love about GraphQL is it’s very similar to JSON in terms of the data presentation however, not quite. It’s considerably nice how it is presented, but it would have been nicer if it was actual JSON.
Are there any GraphQL competitors?
I would say the top competitors are just existing protocols for accessing data. So that would be like REST and maybe SOAP. So I think REST is probably the most dominant pattern used for API access. I don’t think it’s going away anytime soon. SOAP is being phased out generally, but it has some of the same benefits as GraphQL in terms of being self-documenting.
Is GraphQL a good choice when you take into consideration scalability?
I think it can make scalability a bit easier, or it could make it worse too if you’re not careful. For example, if you use GraphQL poorly requesting all the data all the time, you might suffer some performance issues because of that. Instead, if you use it in the way it’s intended where you craft the queries you need, as it even has built-in caching directly on the front-end, this will help the whole process and it can bring huge benefits performance-wise.
Takeaway #1:
GraphQL is an incredibly powerful client-driven tool to plan the back-end of greenfield tech-products that leverage their backend on dynamic data and scalable and flexible architectures without relying on REST endpoints that return predefined and fixed data structures.
Takeaway #2:
For most companies iteration speed is extremely important, and GraphQL enables a more rapid product development because it increases the productivity of front-end developers with features like caching, realtime or optimistic UI updates through libraries like Apollo, Relay, or Urql, which are supported by a large open-source ecosystem and a great community of engineers.
About Alberto
Alberto Camillo is a Senior Software Engineer at Terem and our interviewer. With more than 9 years of experience designing and implementing software, Alberto is a very passionate Software Engineer experienced in web and mobile development. Alberto has been part of Terem in Sydney for over 3 years and he’s always focused on delivering excellent and quality code for our clients. In his free time, he’s also a volleyball coach, a bass & guitar player, and a Dungeons & Dragons lover.