GraphQL and Typescript: Revisiting an Echobind Case Study

Today I’m reflecting on the synergy between GraphQL and Typescript, and how it’s helped us to write better code here at Echobind. I recently wrote a case study for a client of ours and detailed how valuable these two pieces of technology were for our success. Below, I summarize the essential nature of the client’s challenges, and how GraphQL and Typescript set us up for success.

One of the core challenges of this project was the necessity for two separate applications, geared to serve two separate user demographics. Statistical data showed that one user group was typically a younger demographic in their 20s and 30s, and due to their comfort with technology and the mobile nature of their job, they would heavily favor a native mobile application. The other group tended to be a bit older and expressed a strong preference for a web application that would typically be accessed on a desktop computer in their home. The interactions between the native mobile app and the desktop web app would be numerous, as the app ecosystem needed to facilitate a number of features requiring input from both user roles such as messaging and interviewing. The challenge was how to ensure that the two applications communicated flawlessly from a technical standpoint while allowing developers to contribute to both platforms easily with minimal context shifting.

The solution came in the decision to use a GraphQL API for the backend architecture and to leverage a superset of Javascript known as Typescript for the frontend apps. One of the major reasons people use GraphQL over REST is when there are a number of preexisting REST APIs that are desired to be woven together. In this case, GraphQL is serving as more of a “middle layer” than a true backend. But is there ever a reason to use GraphQL as a true backend that accesses the underlying databases itself? We think so. The creation of a GraphQL API implicitly necessitates creating an organized “schema” of all of the data elements the backend provides and their hierarchical relations. This effectively serves as a “data contract” between the frontend and backend. This was useful on this project as it allowed developers to work on any portion of either frontend application, and to already be familiar with the underlying data structures since their implementation was uniform throughout. In short, GraphQL helped keep both frontend apps synced, and helped to keep developers sane as they contributed to both platforms.

While GraphQL ensured both applications were externally synced on the same relations with the backend, Typescript ensured that both applications were internally synced. Using Typescript and some additional tools (namely graphql-codegen), we took the GraphQL schema and converted it into a set of data “types” that were stored in the frontend codebases. By keeping the types in the frontend applications up to date, we ensured developers always had the latest data and documentation at their fingertips (by means of their editors TS plugins), and that many potential bugs would be caught before the code ever even compiled.

TL;DR:

• GraphQL’s typed schema helps keep multiple frontend applications synced with minimal context shifting for developers.
• Using TypeScript on the frontend helped expose the GraphQL schema to developers as it was updated, keeping the code safe, and developers up to date on the latest data models.

The outcome was a robust and scalable application ecosystem that provided seamless interaction between the various user roles on their separate application platforms. The usage of Typescript ensured bugs were minimal in quantity and significance in both the web and mobile applications, and the GraphQL backend provided a solid foundation for not only the first iteration of the ecosystem but many future iterations to come. Scalability, clear documentation, and strong typing are some of the things Echobind loves about GraphQL and TS and keeps us coming back to them again and again for our best work.