Your GraphQL Groove

Rate this content
Bookmark
Slides

Building with GraphQL for the first time can be anywhere between daunting and easy-peasy. Understanding which features to look for in your client-side and server-side tooling and getting into the right habits (and ridding yourself of old habits) is the key to succeed with a team of any size in GraphQL.

This talk gives an overview of common struggles I've seen numerous teams have when building with GraphQL, how they got around common sources of frustration, and the mindset they eventually adopted, and lessons learned, so you can confidently stick with and adopt GraphQL!

This talk has been presented at GraphQL Galaxy 2022, check out the latest edition of this Tech Conference.

FAQ

Urkel is a GraphQL client originally founded by Formidable. It supports frameworks such as React, Preact, Vue, and Svelte.

Urkel is currently maintained by Phil, among other contributors. It recently moved to an independent GitHub organization called Urkel-GraphQL.

GraphQL's popularity is growing due to its strong value propositions such as type safety, introspection, and its ability to solve common API problems like overfetching and performance issues.

Common pain points include error handling, performance problems, client caching, schema stitching, and versioning.

Teams can set themselves up for success by understanding GraphQL's value proposition, making informed tool choices, and focusing on solving bigger problems rather than just basic issues.

The state of GraphQL survey highlighted type safety, introspection, and the ability to solve overfetching as strong points of GraphQL.

The Urkel team decided to drop ReScript support due to low traction, maintenance burdens, and a shift in focus towards supporting TypeScript and multiple UI libraries.

Best practices for evaluating GraphQL clients include focusing on immediate developer experience, making decisions based on current needs, and being prepared to adapt as requirements change.

Schema design is crucial in GraphQL as it serves as a common language for both front-end and back-end teams, helping to communicate data requirements effectively.

Challenges include managing multiple APIs, integrating with various data sources, ensuring performance, and making informed choices about GraphQL clients and schema builders.

Phil Pluckthun
Phil Pluckthun
31 min
08 Dec, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

The Talk discusses the value proposition of GraphQL and its ability to solve common pain points in API development. It highlights the importance of making informed decisions when choosing GraphQL clients, servers, and schema builders. The Talk also emphasizes the need to focus on the best developer experience in the present rather than seeking a perfect long-term solution. Additionally, it mentions the future of the Urkel GraphQL client and the reasons for dropping ReScript support. Overall, the Talk provides insights into the current state and future trends of GraphQL development.
Available in Español: Tu Ritmo con GraphQL

1. Introduction to GraphQL and Common Pain Points

Short description:

Hi, I'm Phil and today I'm here to talk about finding your GraphQL groove. I'll share my perspective on getting started in today's ecosystem, the growth of GraphQL, and the common pain points that still exist. Despite the strong selling points of GraphQL, there are some concerns I have, such as overfetching and the reliance on schema stitching.

♪ Hi, I'm Phil. And today I'm here at GraphQL Galaxy to talk to you about finding your GraphQL groove. This talk is a bit of a perspective from myself on getting started in today's ecosystem, what you might encounter, what problems I've seen people encounter, and what it means to use GraphQL today.

A bit about myself, the usual socials you can find me under Kitten on GitHub or at underscore PhilPL on Twitter, or on Mastodon, if that's your thing. I currently maintain Urkel, some other people. And Urkel is a GraphQL client that was originally founded by Formidable and supports frameworks such as React, Preact, Vue, and Svelte. We're currently working on Unoco, a supporting team that will basically full-time maintain this project.

Currently, what we've seen in the last year is that Urkel has grown a lot, and that corresponds to the growth of GraphQL overall. Not only is Urkel growing, but if we're looking at Apollo clients number, we can see that similarly, the numbers are only going up and GraphQL is becoming more popular. More people than ever are adopting GraphQL and onboarding on top of it.

This kind of leads us to a couple of problems, and I get a lot of questions around Urkel. I get a lot of questions around GraphQL. Typically, these problems aren't really new to me. But at the current maturity of GraphQL, I'm asking myself about some of these questions, why are we still struggling with easy problems? Nothing answered that better than the state of GraphQL survey 2022. In that survey, they've basically asked people to answer a host of questions and measure the popularity of libraries and happiness with the ecosystem. But they also had a section around GraphQL pain points, and people could vote on several things on what they currently find painful in the ecosystem.

If we look at that, we see a couple of common points that might not be too surprising. We see people deal with error handling, and that's painful, performance problems, client caching, and so on. What I find surprising here, though, are a couple of these points I really wouldn't expect to see at this point in the ecosystem. So we see people are struggling to get their API maybe to be performance. They're struggling with schemas, ditching and versioning. And I find that worrying, but at this point, I'm a bit surprised that we haven't moved on from these problems and don't have good answers for them.

GraphQL, of course, also has strong points as well, and the state of GraphQL survey measured that. And similarly, here, we see very strong selling points that you would find in any introduction to GraphQL. For instance, type safety at the top, introspection next. But it's a couple of points here that I'm worried about. Overfetching is still seen as a major strong point that GraphQL solves. However, overfetching is not even a core principle of what GraphQL aims to solve. In fact, I see it as a core problem that any well architected API should probably address. We also see schema stitching here come up again, and this is quite interesting, as it means that a lot of people think schema stitching is both a strong advantage of GraphQL but also a major pain point.

2. Entering GraphQL and Value Proposition

Short description:

I find it surprising that people struggle to see the GraphQL community as welcoming as it should be. As you're entering GraphQL, you might ask yourself, how do I set myself up for success? How do I get my team to succeed? Many teams regret early choices and make small adjustments. What is GraphQL's value proposition? How do you set yourself up for success? How do I stay on the happy path? GraphQL has a different value proposition for different people. It changes depending on front-end or backend perspectives, as well as the size of the organization or team. GraphQL has strong answers to basic API problems, such as overfetching. Let's cut through the GraphQL hype and focus on the frontend perspective.

Lastly, we see community as the very last point on strong points in GraphQL. And years into GraphQL, and with many different options to choose from, I find it surprising that people struggle to see the GraphQL community as welcoming as it should be. As you're entering GraphQL, I think you're following a very similar trajectory as many other teams are, and that you start out thinking that GraphQL's value proposition is very exciting and amazing, and you're looking forward to solving your problems. Later on, you might ask yourself, okay, now I want to get started. How do I set myself up for success? How do I get my team to succeed? Things get a bit troublesome afterwards for most people. You're asking yourself questions like, am I getting value out of GraphQL in general? Or are you really finding the right tools for the job? And later on, a lot of teams, I found, are regretting a lot of early choices and are making small adjustments Mistakes were made, at this point, people are going back and review their decisions.

This talk has been a bit difficult to write. Now I see a lot of different people enter the GraphQL space. Very different teams might get started at any given point in time, and everyone has different expectations from GraphQL. And many teams probably also run out of time trying to fix their problems and leave the space before they can communicate what they needed from GraphQL. To go back to these three different points, the questions that I want to pose is, okay, what is GraphQL's value proposition? If you are now entering GraphQL, and you're probably at this conference because you either want to use it or because you're already using GraphQL, what is it that you want out of GraphQL? And how do you set yourself up for success if you already know what you want? And then lastly, how do I stay on the happy path? GraphQL can be very overwhelming, but how do I stay on track to use it well? The first question I think is what everything revolves around. Why would I use GraphQL? And that's what I want to start with. I think GraphQL has a different value proposition for a lot of different people. And I think we have to look at two axes here. We have to use an axis that shows us how front-end people think about it or how you think about it when you're looking at your front-end stack. And how a backend team might look at it. A backend team might look at it. But GraphQL also changes depending on whether you look at small or large organizations, small and larger teams, even multiple teams working on it. The difficulty here is that you will be in a different place than anyone else. Most points on this axis will pose some problem in some form, and you might have very different questions depending on where you're at. Depending on whether you're very front-end focused and you're a smaller team, or a larger team that has a lot of backend services. In any situation, you might already still be convinced to use GraphQL, however. After all, you are GraphQL Galaxy. However, this is because GraphQL has very strong answers to basic problems that any API face. I've mentioned overfetching before, but a lot of different solutions might actually come from thinking about how can I solve overfetching. GraphQL is not the only answer if you're only thinking about simple problems. And that kind of brings me to the next part, cutting through the GraphQL hype. Why are we actually using GraphQL? And why the reasons that we're thinking of sometimes a bit too simple. And I want to kind of cut this down into these separate parts on this axis. And I want to start with frontend, since maintaining GraphQL client, I'm most familiar with that.

QnA