Cover photo by Jez Timms on Unsplash
I began exploring the GraphQL ecosystem in 2018. At that time, REST APIs were a significant part of my daily work, but I was always exploring and looking for new challenges. During that period, I invested much of my time transitioning from the PHP ecosystem to React, React Native, Node.js, GraphQL, and TypeScript.
Leaving GraphQL
While GraphQL enhanced communication between frontend and backend, there were several gaps and obstacles in making it work effectively. Tools like Apollo and now urql have improved the client-side experience with GraphQL. However, ensuring a type-safe experience requires using GraphQL CodeGen. The Guild has made remarkable efforts to streamline this experience, yet there is still room for improvement.
I transitioned from the GraphQL ecosystem to the tRPC world to enhance my daily workflow more than a year ago. This shift was swift and relatively issue-free, resulting in faster and simpler project development backed by TanstackQuery on the front end. Although some costs were involved, the overall benefits and experiences have made it worthwhile.
🪄 gql.tada Makes GraphQL Great Again!
Since last week, I've been testing gql.tada, the new library created by Phil Pluckthun and Jovi De Croock that eliminates the need for codegen and seamlessly integrates GraphQL with TypeScript like never before.
The initialization process is straightforward, requiring only three lines of code in tsconfig.json and one file to export the typed client. The best part is that everything works without additional background processes and is baked into TypeScript.
Three features have made me miss the GraphQL ecosystem again! Let's explore them and see how they change the way you work with GraphQL on the client side.
Autocomplete
The first notable feature is the autocomplete, which feels like having a GraphQL playground built into the TypeScript editor. For me, autocomplete is essential when working with GraphQL. The visibility of available queries, along with their corresponding fields, mutations, and arguments, enhances the developer experience.
Another thing to note is the argument handling by the urql client. It quickly provides feedback about missing arguments or incorrect types.
Fragment masking
The next one is Fragment Masking. Gql.tada adds a layer of "security" to Fragments by preventing accidental access to Fragment types. This feature stops the direct use of fragment data in components without explicitly reading the data. Instead, you must use the readFragment() hook to explicitly read (unwind) the fragment data type. You can learn more about this feature here
GraphQL Fragments can help reduce duplications, as multiple types within the GraphQL Schema can utilize the same fragment. This creates boundaries for composing data structures. As you might have seen in the video, gql.tada also warns you about unused fragments in your codebase.
Unused warning
One of the advantages of GraphQL is its requirement for explicitness; you always have to specify the data set you want to fetch. This can lead to overfetching when unused data is not immediately visible, particularly without an effective tooling. However, with gql.tada, this problem is resolved as it immediately highlights unused fields as you type.
Wrap up
GraphQL demands a degree of explicitness when specifying the data developers want to use. Without appropriate tooling, this could be cumbersome. However, gql.tada fills this gap perfectly. Its features make working with GraphQL enjoyable once more!
All the codebase used for this blog post is here: https://github.com/czystyl/expo-tada
Top comments (0)