Your GraphQL Groove

♪ 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.

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.

And when you're looking at GraphQL on frontend today, you might find that the value that people are seeing GraphQL is diminishing and that people are not as excited as they used to be. We have a lot of options today in boosting the productivity of frontend developers. And when you're setting up a new project, you have a host of options to choose from. You might go with a Jamstack static site generation approach, Reactor server components on the horizon, loader patterns are popular again, and you've seen those in next and coming up in Remix. And you have new libraries coming up like TRPC, they're making foreign functions easily callable and typed. And the whole value proposition of GraphQL loses its edge if we're focusing on too many different problems that are a bit too small. For instance, if we're looking at these two different things, people ask about, okay, is TRPC easier, but adds the same value to my project? Or is static site generation so detached from actually needing GraphQL, though we might as well use much simpler methods to get our data.

And I'd like to go back a step here and say, okay, I think of front development in terms of having UI views that are made up of trees of components, and each component has a set of data requirements. If we look for instance at static site generation from that perspective, then we can export our views ahead of times and the data providers like GraphQL disappear on the client side. But this leaves out important points around interactions and use cases like if a view isn't serializable. So if you're thinking mobile apps or non web apps, PWAs and so on. The next point is then obviously okay, but RPC and REST can still solve these problems. What if we just lose the schema and we just use RPC? What do we actually lose if we ditch GraphQL and we are just going input output, we're getting our data and we're happy? That's the problem, if we're choosing to actually compare GraphQL with data retrieval methods, then a lot of these supposed strong points that people think of when they think of GraphQL disappear. These points might be over fetching, but we might also thinking about preventing water falling requests, we might think of performance problems where GraphQL gives us tools to optimize resolvers. We might think about fragmenting our data, but all of these points can be solved with RPC based solutions.

So, if we return to the second idea and we think about data requirements in GraphQL, I think this is where GraphQL really shines and where the value proposition becomes very strong. If you think of GraphQL as its schema mapping directly to your app data structure, then that is where you're finding a lot of value. That you might be missing if you're thinking about technical problems like over fetching. So, the question that I want to ask to anyone that already got started with GraphQL and that got a bit disillusioned when first trying it out in a team was, well, you may be sold on basic problems rather than focusing on the bigger problems and the stronger solutions that GraphQL can offer you. After all, GraphQL is a pretty batteries included spec and runtime and framework, and it can help us write declarative data models, it can help us have a type schema. And it also, to kind of give an example, goes into a concept I'd like to say of GraphQL being a lingua franca, that one of GraphQL's primary design principles, as also listed in the overview section of the spec, lists that GraphQL is product centric. And in that, it can serve as a common language not only technically for the server and for the client and the API communication, but it's also a language that your front end engineers and back end engineers can use to communicate what they mean when they talk about data. So the kind of learning I have from that, and the thing that I want to tell as many people as possible is ask yourself, compared to without it, what will GraphQL do for your team? And if you can answer that question for yourself, you're already in a much better place. And that's when you kind of become ready to have a different perspective on GraphQL's astronomically big ecosystem and the different choices you have to make. And I said earlier, one of the advantages of GraphQL is that it's batteries included. And it is, in some senses, the spec has the reference implementation. We get documentation built in. Introspection is a big feature, but we still have to make a lot of choices. And that's when the other axis of small orgs and large orgs becomes very important, because you might make different choices depending on what requirements you have, depending on how large your team or teams are. And you are exposed to a lot of choices these days if you're looking at GraphQL.

Even if we're just looking at web and JSFirst development, you have a lot of decisions to make. You have to choose between different GraphQL clients. So, for instance, you might see, am I going to use Relay, Urql, or Apollo Client? You might have to choose a GraphQL server. And you might choose Mercurius, GraphQL Yoga or Apollo Server. You might choose a GraphQL Schema Builder. And that kind of gives you access to a nicer way of organizing your API. So, you might choose Pothos, TypeGraphQL, GraphQL Nexus or GraphQL Code Generator. And that choice might even fall away or change if you're using a GraphQL generator. So, you might use AWS AppSync or Amplify. You might use Graphil, Hazura, DGraph or GraphQL Mesh to generate an API, and that kind of replaces some of the manual schema building. And that depends more on your data sources. So, these are a lot of choices. And the good news is while this may seem like a lot, this depends on your team's needs, but there are still a lot of choices to make. You often have a smaller selection of things to choose from, however, if you're considering your constraints and requirements.

So, your server client might not be written in JS, in which case all of the backend choices, if you're writing in a different language might narrow themselves down to a whole host of different solutions, but a smaller set. Or on the client side, you might have a specific UI framework you're working with, and not all GraphQL clients will support all UI libraries and frameworks. Or you have specific runtime requirements and what your client does, or what your backend has to do. Not all clients will support that. Normalized caching is basically a requirement that I often see from people, and I've only limited the set of GraphQL clients on that list to ones that have normalized caching.

You might also already have specific opinions on how you want to author GraphQL queries and that might factor into this as well. And Relay comes baked in with some of these decisions. From my perspective as an Urql maintainer, we see a lot of different combinations, but very fixed combinations in these tools. So for instance, for Urql, we see, for instance, GraphQL Yoga mixed with GraphQL Nexus a lot. But if you're using PostGraphQL Relay together, that might be a more tightly coupled choice than others because Relay has certain requirements on the schema as well and PostGraphQL has a lot of opinions as well that mix well together with Relay.

If you're designing on a client, one of these things you have to do is structuring your queries and data requirements and looking at how you're building these queries or kind of patterns you want to apply is probably more important than specific small features on the client. For example, Relay has, as I just said, a lot of opinions. So it has opinions on how you merge queries and how one view will typically run a single query and hoist and compose fragments together into that. If you're into that, then for instance, take a look at Relay or apply the same pattern to other GraphQL clients and your decision will become much easier.

On the schema builder side, I would focus more on the team structure and you might have to after all. You might not want to choose any given GraphQL server or any given schema builder because it's technically interesting, but you might want to look at who's writing your schema and who's your schema author and then fit those offering practices to the team structure and the schema builder you will choose.

Lastly, I want to talk a bit of backend teams and that's the furthest away from what I do every day, but I have a lot of experience one, building APIs and accompanying people as a consultant through the journey of building a GraphQL API. And if we're thinking about a GraphQL API, you might think about a monolithic GraphQL schema. So this is the kind of structure that I might imagine if we're thinking about GraphQL. GraphQL aggregates and data and combined data from different data sources, be it maybe Stripe billing together with your database, together with some kind of asset pipeline, who knows? And those resources go into your GraphQL Gateway, you have a schema on your app, access is done. Of course, other people and other teams might think about it the other way around, they might be thinking about multiple apps they have, maybe they have an Android iOS and Web App. And they think about how all of these clients want slightly different ways to access that schema and then access the resources via that schema. In reality, people quickly find out that it's obviously a combination of the two. You have a lot of different resources that are provided via schema to those apps. And you as a schema designer are responsible for making sure that that access works for all of these apps and matches what they are trying to display.

A lot of people get hung up on the idea of, okay, we have multiple resources, we have multiple services. So clearly we could group GraphQL into separate schemas. And then merge those schemas together into a gateway. People get almost paralysed by this decision sometimes on whether to already go into a more microservices architecture with GraphQL. And while there are different terms for it and while we could look at separate ways of going about that decision, consider, is it a technical problem whether you want to already structure your GraphQL service as multiple microservices or whether you have a governance question instead of you have multiple teams that are working on separate resources and separate APIs and you want them to be still able to work separately. A lot of times I've seen teams struggle with that. And the answer is often you have to set up some governance. And it's worth it a lot more if everyone designs a schema together and comes together to build a monolith first. Even if you're not building a monolith and you're choosing one of these other solutions, then you might still decide that coming together and designing the schema with a centralized team is really worth it in the beginning when starting out. GraphQL monoliths are gateways. So this also opens up to different, easier answers. A lot of people who are migrating to GraphQL are making the GraphQL gateway and access to old REST APIs or old APIs in general. So the other question you have to consider is where do you want to start using GraphQL. Often, GraphQL is a back and for front and killer and that can really take over a lot of the functionality of what we previously did with writing purpose built APIs per app. But you have to ask yourself do I want GraphQL to go further and replace all of my services past all of my old APIs? And often you can just absorb that functionality into the monolith instead. So the problem is asking yourself what's the minimal architecture that your team can adopt today to benefit from GraphQL. Now all of these separate categories of problems are basically problems of how do we avoid falling in the GraphQL ditch? All of these problems are very similar and that they're questions you might ask yourself early on, but that lose importance if you focus on making things work today and if you stick to your choices. However, the ecosystem doesn't always have great answers, you might be asking yourself, what happens if I want to move to federated schemas in the future? What happens if I need normalized caching in the future? I need to change my decision on what GraphQL clients to use. And the answer to that is, the ecosystem doesn't have great answers for that yet, we don't have all the answers around how to move when you are growing as an organization to new solutions, except for traditional solutions of starting over with some parts.

The other side is, clearly I've stated, the client side has a lot of possible opinions and approaches to writing your queries and structuring your app. But that guidance can be pretty unclear. And today only Relay has the most and most solid opinions on how to structure your app. And while that works for React and there are adaptations for other UI frameworks, we're still a bit further away from having the perfect developer experience paired with good opinions that are giving you more guidance to build these apps.

So when you build your GraphQL APO, if you're getting into GraphQL, what I can recommend to you is for your team, find the largest intersection of features, of requirements of what you need. Choose the tools and don't get distracted early. A lot of people are happy with GraphQL and productive with GraphQL, be it small or large organizations, because they've made solid decisions. And when those decisions turn out to have flaws, they still stuck with them for a bit to find out what the actual problems were. Because sometimes there might be governance problems instead.

Now, this is only 20 minutes and that's my talk. But if you have more questions, you can come to the Q&A or you can contact me on Twitter or Mastodon, or you can go to the Oracle docs instead on this link. Cheers. Brian, hi again, good to be here. Thanks so much for being here. Awesome. And so we're going to go ahead and get started with the Q&A. Just as a reminder, you can continue to ask questions on Discord in the Andromeda Q&A channel. Let's go ahead and start though, by taking a look at the answers to your poll question. This is a fun one. So the question was, how do you feel about GraphQL in one word? It looks like you got some positive responses here. What do you think about the results, Phil? Wow, that's really positive. That's interesting. What an interesting time in GraphQL. And I feel we're kind of on the verge of a lot of things. So I'm glad to see that it's positive. On the other hand, I would have expected at least a bit of negativity. I don't know. Who else hopes for negativity? I shouldn't hope for that. I think it's good to hope for feedback, right? You can always grow when you get feedback. But I guess maybe the audience here today is feeling good about after seeing all the talks and everything.

So happy to see it. Awesome. So we can go ahead and get started with some of the questions that we do have. First question is, what is the future of the Urkel GraphQL Client? That's a very timely question. Yesterday, we announced that Urkel is actually moving into an independent GitHub organization. Urkel was founded at Formidable. If you've already seen the Urkel repository, you might be very used to seeing Formidable associated with that. And I used to work there. Jorvi and I maintained Urkel heavily while we were at Formidable. And that's why I helped kind of start the project and shaping it to what it is today. We've been in a lot of talks with them about the future of the project and the longevity of it. We've come to an interesting agreement, which is, okay, if we've already been maintaining it, why don't we make that very explicit? So Urkel's now pretty independent. You'll see this Urkel-GraphQL as an Org on GitHub. We basically vouch that we'll continue maintaining it, but we're leading it towards a new plateau and trying to find new stability in the project where anyone can come in and help. That's really awesome. Congratulations. That's exciting news for sure.

Then as far as the future of the client as well, from a technical perspective, anything that's coming soon that you wanted to point out or that you're working on? Yeah, to reference a bit of my talk, I think we're at an interesting point where a lot of new people are coming into GraphQL and a lot of people are finding out how we can grow GraphQL. We're so many years in already that people are reaching the limits of where they started with GraphQL. So people are starting their first projects and APIs is one thing, but we're also seeing a lot of people who are now scaling it multiple APIs, who's scaling it towards bigger and bigger organizations. And I've seen a lot of companies and teams struggle with that. It's funny saying teams because in some organizations they might be a crossroads where another team is joining the development of a GraphQL API, and you're already at the point where you're maintaining multiple apps using that API. And maintaining a GraphQL client, from my perspective, I think we're not doing enough yet to help people out, both people who are getting started and people who are scaling to really large applications. Obviously, we have heard about GraphQL Code Generator today. We've heard about other clients today. And I think the big message here is that if you're looking at GraphQL clients today and, for instance, you're looking at Relay, you're already seeing a lot of opinions and a lot of help to get started with that. Although the biggest criticism of Relay has been in the past that it's documentation is not amazing. On the other hand, with Urql, the biggest criticism we get is that we don't do enough because we're not good at advertising how it should be used. So, I really am looking forward to focusing with Urql on building a coherent story of this is how you use it and getting to that better stage of developing experience where people can just get started and work with it as it is. Yeah, there's definitely developers, especially as you're scaling, that do like that opinionated type of documentation or here's how you should use it, here's how you should approach decision-making. In that same vein as far as scaling and as organizations scale and they evaluate which clients to use or if they're going to bring in a specific tool, like, what are some best practices for evaluating those? I think the first thing that I always started with is, I suppose the longer answer is in my talk is just keep with what you're comfortable with. And a lot of times people are looking at finding the perfect answer that works for them in, let's say, months or years. And I think when I'm evaluating tools, what I'm looking at is okay, how can we get the best developer experience right now? And that's maybe a bit of pragmatism. I've worked as a consultant for a lot of years. And what you're looking at is okay, how do we make our team happy right now? How do we get you to a productive, kind of happy phase of the project? So the initial setup period is often overstated by a lot of people because they're looking at okay, but if we get this wrong, we'll get stuck here, and we'll keep iterating. And we'll have to come back to this. And the truth of the matter is, I think GraphQL has reached a point where it's so big and popular that we'd expect it to be super mature right now. We'd expect there are no wrong choices. But in reality, I think GraphQL has developed a bit differently from other communities like the React community. Where everything is not really surrounding a single library, but everything is surrounding a single spec and a single way of doing things. And that meant for libraries and tools, we have a lot of different choices to make. And you can get really lost in that if you're thinking about, okay, what if I get this wrong? Because the answer is probably in six months, whatever you choose now is maybe not going to be the right tool for you anymore. And you have to be willing to embrace that. You have to be willing to say, let's focus on the outcome. The business logic I'm writing, that's what I'm focusing on. How do we write that? I think one kind of GraphQL tools you should choose is probably the first question that you should get over with very quickly. Yeah, so great points there.

I think it is very easy to get stuck in that analysis paralysis, and sometimes you just have to go with what's best for the problem that you're solving in front of you. So, yeah. Great points.

We do have another question, probably the last one that we'll have time for. But why did the Urkel team decide to drop ReScript support? Any answer there or any information there? I have not heard about reason and Rescript in quite a while.

So, the reason Urkel project was maintained by someone at Formidable, that was Parker, and Parker at some point even before I did, left Formidable. And at that point, that project was basically in maintenance mode. And now some core parts of Urkel were written in Reason originally, which is kind of a streaming mechanism library. We recently migrated that to TypeScript as well. And there are two reasons for that. So, the reason why we got rid of ReScript slash reason and the core library is it hasn't really gained enough traction where enough people can write it anymore. And it was kind of holding back external contributions when we switched that sub-repository over to TypeScript, we immediately got contributions again, which is pretty amazing, almost within a week. The other part is in terms of reason at Urkel, it's like not only is Reason-ReScript a separate language, although it integrates very closely with React, it is still a separate programming language. So, we were looking at completely different patterns and maintaining those completely separate patterns was becoming a bit of a burden. So, at the end of the day, we said, well either we can say in the next year or months, we're going to focus on TypeScript and do that really well, or we are going to focus less on that and expand it to more sectors. But since we're already focusing on supporting multiple UI libraries and having good TypeScript support, putting Reason-ReScript on top was a bit of a tall order.

Okay, yeah, that makes sense. Thanks so much for answering that question. All right, so we only have a minute left. Thank you so much for being here with us, Phil. Anything else you'd like to add before we sign off with you? I'm not sure. I'm not sure about that. That's why I was hoping for the poll to be a bit more spicy and a bit more controversial. Well, if you have any spicy takes for Phil, you can find him online, or reach out to him with any of your constructive feedback. But thank you so much for being here, Phil, and for answering our questions and for your really interesting talk.