[Technical Post] Why we choose to adopt GraphQL

We are currently building laimuna.com to help accelerate the adoption of SaaS products in Arabic businesses. In this post, I will explain our decision to choose GraphQL to communicate with our backend servers. Laimuna is content-driven and we rely heavily on data to power our articles and pages. Our backend server contains all the data we need, and we need a way to efficiently access and use that data. Initially, we considered using a REST API to communicate with our backend server implemented with the amazing Strapi CMS for Node.js. Strapi has a documentation plugin that generates OpenAPI (f.k.a Swagger) specifications for your API. We made this choice because of the simplicity of REST APIs and because most engineers are quite familiar with them. We were able to generate a Swagger file for our API and started prototyping with it. I had previously written an open-source library called open-ts to generate TypeScript clients from Swagger definitions, but due to updates to the specs and some breaking changes, the generation process wasn’t as smooth as we hoped. This was a minor issue, but it added some complexity to our development process and tools. We had a closer look at Strapi GraphQL and decided to give it a try. GraphQL APIs are more complex than REST APIs, but the advantages are many. First, the GraphQL spec is more mature and stable, which means that the generated clients are more reliable. Second, GraphQL allows for more granular control over what data is requested and returned. It wasn't immediately obvious to us how important this was until we started using GraphQL. Since we are using React as our front-end library, using GraphQL was a natural fit. React components can request the data they need from the GraphQL server, which means that the client only requests the data it needs. This is in contrast to REST where the client typically requests all the data from the server, even if only a small subset is needed (Note that Strapi has a feature called “Population” that tries to address this issue, but it’s not as effective as using GraphQL). Our database is highly normalized and has a lot of tables and relationships. We found that querying the data with GraphQL was much more efficient than querying it with a REST API. This coupled with GraphQL Playground, which is a great tool for testing and exploring GraphQL APIs, made it easy for us to quickly develop our front-end. Overall, we are very happy with our decision to use GraphQL. It has helped us to develop our front-end more quickly and efficiently. We would recommend considering GraphQL for any project that relies heavily on data.

External Links
[Laimuna] https://laimuna.com

[Strapi] https://strapi.io/

[open-ts] https://lnkd.in/gyzQrWXM