Since JavaScript became so powerful in the browser, a big part of the web applications is executed on the client and therefor needs to communicate with the backend to get data. We got used to build some API for such purpose and often tried to follow standards like REST. Over time, it seems that REST was not solving all requirement of an API, some new standards appear, like GraphQL or gRPC.
Like many of us, I follow the GraphQL hype and I was very excited when I first heard about it. I thought it would be a magic tool that would solve many problems I had with REST. But I quickly understood this would not be the case. While trying GraphQL, I started to get disappointed. I had to learn a new language, a new data structure and after some time I saw that it was causing much more overhead than REST. Of course it has some advantage in comparison to REST but in many cases REST can do much of what GraphQL does. I am now using GraphQL for more than a year and I really don’t get along with it. Instead of implementing features, I too often spend more time on making my application communicating by implementing the resolver, the GraphQL schema, the GQL and so on. One other big issue was the performance to load the data. Since GraphQL should be flexible in how the client can request for data, the way to load data is much more complex and might bring you to run more queries than necessary to your database. Of course there are some tools like dataloader to solve this but then it becomes too complicated. Feeling a bit frustrated, I searched some articles to see if I find some similar experience and I found a very nice post https://blog.logrocket.com/5-reasons-you-shouldnt-be-using-graphql-61c7846e7ed3/ . I still think that GraphQL can be a great tool, especially for companies working with separated teams between backend and frontend, or for applications that need to expose their data to third parties.
Today, it became a challenge to find the perfect protocol to build your web application, where REST is very simple but maybe too permissive and GraphQL very powerful but causing so much overhead. At the end, you should ask yourself, what do you really need? What if you don’t need any of that! Why to spend so much effort on building an API that will most likely only be used by your web application? Is exposing your API really necessary?
As a fullstack developer, I often wonder why is it so complicated to make the frontend and the backend communicate together, I believe that the communication should be implicite. Now, let’s imagine if you could build a JavaScript application where the UI is calling directly the server functions, without to use an API. After my frustration with GraphQL, I started to build Isomor. This tool gives you the possibility to develop a web application in a single project by abstracting the layers between frontend and backend. Instead to implement an API, using REST or GraphQL, isomor will allow you to call the server functions directly from the user interface, without to think about the communication protocol. Isomor will take care to generate automatically those layers for you.