GraphQL at Scale - Panel Discussion

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

GraphQL at Scale refers to the capability of GraphQL technology to handle scalability across various dimensions such as technical scalability (managing larger technical loads), product scalability (handling more products or product variability), and team scalability (expanding teams in size, geography, skills, etc.).

GraphQL can significantly influence scalability by allowing flexible and efficient data interaction, which can adapt as the requirements of different clients and products evolve over time. This flexibility supports the scaling of clients that change over time without requiring constant versioning or server changes.

Notable contributors include Dan Schaefer, a co-creator of GraphQL and Facebook Engineering Director, Nick Schrock, also a co-creator and founder of Elemental, and Tanmay Gopal, CEO of Hasura, who focuses on technologies like React, GraphQL, and Kubernetes.

Apollo Federation allows different teams or lines of business to maintain autonomy while contributing to a unified GraphQL schema. This approach helps manage and scale complex systems by defining how different parts of a schema relate to each other, supporting a cohesive yet flexible architecture.

Handling errors in GraphQL is complex due to its nature of potentially returning partial data along with errors. This behavior is different from traditional APIs that use standard HTTP status codes, making it challenging to integrate with existing monitoring tools that rely on these codes.

GraphQL enables a healthier interaction between server-side and client-side engineers by allowing server-side engineers to publish a schema that client-side engineers can consume. This setup promotes a clear separation of concerns and efficient collaboration across different roles.

Tanmai Gopal
Tanmai Gopal
Nick Schrock
Nick Schrock
Dan Schafer
Dan Schafer
Danielle Man
Danielle Man
Taz Singh
Taz Singh
39 min
02 Jul, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
The panel discussion on GraphQL at scale highlights how GraphQL technology can handle scalability across technical, product, and team dimensions. The panelists delve into the benefits of Apollo Federation, which allows different teams to maintain autonomy while contributing to a unified schema, managing complex systems efficiently. They discuss how GraphQL provides flexibility in defining data models and connecting various databases, making it easier for different clients to use the data. Error handling in GraphQL is a challenge due to partial errors and the need for response inspection. The discussion also touches on the importance of built-in documentation and the need for better tooling around GraphQL. The panelists emphasize that the decision to use GraphQL or other technologies should be guided by specific use cases and organizational needs.

1. Introduction to GraphQL at Scale

Short description:

Today, we are here to host a panel on GraphQL at scale. GraphQL can have a profound effect on how you scale in various ways. We have gathered top minds on GraphQL to discuss different ways to scale GraphQL. Let me introduce our panelists: Dan Schafer, GraphQL co-creator and Facebook engineering director; Danielle Mann, engineering and design manager at Apollo; Nick Schrock, GraphQL co-creator and founder of Elemental; and Tanmay Gopal, CEO and co-founder of Hasura. They have extensive experience in various technologies. Now, let's dive into the discussion!

It's good to be here. I hope you're all doing well. It's been an insane conference so far and it's been so much fun to watch from the sidelines, but it's my pleasure today to be here with all of you to host this panel on GraphQL at scale.

But first and foremost, what do I mean about GraphQL at scale? I mean, scale can be a lot of different things, right? There's technical scalability, so accommodating a larger technical load. There's product scalability, accommodating more products or more product variability. There's team scalability. There's expanding your team in a variety of different ways, whether that be geography or size or so on, so forth, skill sets and so on, so forth. I mean, there's a whole lot more ways to scale than what I've even just mentioned just now. And in fact, I was speaking to Uri before the conference and he told me, Taz, if you start to scale up your hair, just like Uri's hair, I can start to understand GraphQL a bit better. Well, I tried and I still don't get it. I still don't get it, Uri. So, I'm afraid that one doesn't work so well. So, you got to give me another tip, man, because that one's not working out so well. But anyway, for me, what I've found is that GraphQL can have a pretty profound effect on how you scale. The technology decision itself can affect how you scale in all those different ways that I mentioned, and we've managed to get some of the top minds on GraphQL from across the entire galaxy here for you today to talk to you about different ways you can scale GraphQL.

So, without further ado, it's my sincere pleasure to introduce you to our panelists. So, Metin already introduced them, but I'll take another stab at it in introduce everyone again. So, first and foremost, Dan Schafer, if I can ask you to give a little wave, Dan. He's the GraphQL co-creator, Facebook engineering director. We have Danielle Mann, engineering and design manager, helping build things for GraphQL at Apollo, currently working on the Apollo Explorer. You get a wave, Danielle. Nick Schrock, the GraphQL co-creator, founder of Elemental, working on Daxter, ex-Facebook engineer. Gonna get a wave, Nick. And last, but certainly not least, Tanmay Gopal, CEO and co-founder of Hasura. He is a stack overflow powered full stack developer's area of interest and work span React, GraphQL, Node.js, Docker, Postgres, and Kubernetes. He is passionate about making it easy to build complex things, and is the instructor of India's largest massive open source online course, The Introduction to Modern Application Development, with over 250,000 students. Can we get a wave, Tanmay?

And I think maybe my first question, how do you remember all those names? I mean, I can remember like three names, but 250,000 names, that must be a really long attendance session at the beginning of all your lessons. That's a lot of people. Yep, yep. Just the online nature of the course really helps with that.

1. Introduction to GraphQL at Scale

Short description:

Introduction to GraphQL at Scale panel and the various aspects of scalability in technology, product, and team dimensions.

It's good to be here. I hope you're all doing well. It's been an insane conference so far, and it's been so much fun to watch from the sidelines. But it's my pleasure today to be all of you to host this panel on GraphQL at Scale. But first and foremost, what do I mean about GraphQL at Scale? I mean, scale can be a lot of different things, right? There's technical scalability, so kind of accommodating a larger technical load. There's product scalability. There's accommodating more products or more product variability. There's team scalability. There's like expanding your team in a variety of different ways, whether that be geography or size or so on and so forth, skillsets and so on and so forth. I mean, there's a whole lot more ways to scale than what I've even just mentioned just now.

2. GraphQL at Scale: Challenges and Solutions

Short description:

GraphQL is inherently a technology of scale. It was formulated at Facebook to address the challenges of scaling their data layer. The ability to scale within a given client and add features without versioning the server is one of the original scaling factors of GraphQL. GraphQL provides a formalism for technology teams to interact and handle scale. It offers technical aspects like fragments, type safety, and batching, but also addresses the organizational human problem of scale by providing a way to specify and exchange information about APIs.

That's awesome, dude. Well, it's a pleasure to meet you all. And it's a pleasure to talk to you all about GraphQL at scale. So I guess, without further ado, let's kick it off with a question.

So as I mentioned before, I think GraphQL is inherently a technology of scale. I believe it was formulated at Facebook when scaling their data layer to accommodate multiple device form factors. So what aspects of GraphQL drew you to it when addressing those types of challenges of scale? I guess we can start with Dan.

Yeah, I think the way in which it scales is sort of interesting, because it scaled differently over time, sort of in its evolutions at Facebook. Where the original problem of scale, I think we anticipated the need for multiple clients, but it wasn't even multiple clients at the same time. It was actually the scaling of clients that change over time, where we knew that the newsfeed that we wanted to ship in, the original proto version of the native Facebook app in February 2012, was going to be different than April, was going to be different than June. Just the speed of evolution was going to change. And so it obviously has proved very helpful in having multiple clients at once, but even just scaling within a given client, the ability for a client engineer to say, hey, I'm going to add this feature now, and they don't have to version a server. They don't have to potentially make a server change if the data's already there because of the graph nature of it. I think that was probably one of the original scaling factors that I think didn't necessarily draw us to it, but drew us to create it.

I think one of the things that drew me to GraphQL, especially from the scale aspect, was I think especially over the last few years from what I've seen in the ecosystem is that there's two aspects to scale that are particularly important with GraphQL. The first is this technical aspect, which is that your technology team is scaling and there's a bunch of work that you're doing that is going to be repeated across all of these engineers. Whether they're consuming the API or building the API and whatnot. And GraphQL really creates a formalism for people to interact when they hit those levels of scale. You realize that, Oh, well, we need to have something like fragments, but then turns out when GraphQL has it, you need to have type safety and GraphQL has it as spec. So those technical aspects, so you realize that you're making multiple API calls, you should just be making a better batch API call, and GraphQL is in a way this amazing batching technology. And so that aspect is exciting for sure. But I think there's another very interesting aspect of GraphQL at scale. And I see this, especially in enterprise with what really appeals to people about GraphQL, is not so much the technical awesomeness of what GraphQL lets you do, which is let's say performance and type safety. Okay. To a degree, maybe type safety, but also not the performance aspect of it and whatnot, but more the metadata aspect of it, which is that this aspect of saying that we have this ability, or we have this formal way or this way of specifying our API and exchanging information about our API. And this is more of an organizational human problem of scale rather than the technical aspect of scale, which is saying that we should have really just done this right the first time. We should have had APIs, we should have documented them, we should have had open API specs or whatever. It should have been better, but it's not. And for them, the appeal of GraphQL is, oh finally, yes, this makes sense. We should have this Explorer tool, GraphQL.

2. Discussion on GraphQL Scalability

Short description:

Discussion on the impact of GraphQL on scalability and the introduction of top minds in GraphQL for scaling solutions.

And in fact, I was speaking to Uri before the conference, and he told me, Taz, if you start to scale up your hair, just like Uri's hair, I can start to understand GraphQL a bit better. Well, I tried, and I still don't get it. I still don't get it, Uri. So I'm afraid that one doesn't work so well. So you got to give me another tip, man, because that one's not working out so well.

But anyway, for me, what I found is that GraphQL can have a pretty profound effect on how you scale. The technology decision itself can affect how you scale in all those different ways that I mentioned. And we've managed to get some of the top minds on GraphQL from across the entire galaxy here for you today to talk to you about different ways you can scale GraphQL.

So without further ado, it's my sincere pleasure to introduce you to our panelists. So Metin already introduced them, but I'll take another stab at it and introduce everyone again. So first and foremost, Dan Schaefer, if I can ask you to give a little wave, Dan. He's the GraphQL co-creator, Facebook Engineering Director. We have Danielle Mann, Engineering and Design Manager helping build things for GraphQL at Apollo, currently working on the Apollo Explorer. You can get a wave, Danielle. Nick Schrock, the GraphQL co-creator, founder of Elemental, working on Dagster, ex-Facebook Engineer. Gonna get a wave, Nick. And last but certainly not least, Tanmay Gopal, CEO and co-founder of Hasura. He is a Stack Overflow-powered full-stack developer with an area of interest and works on React, GraphQL, Node.js, Docker, Postgres, and Kubernetes. He is passionate about making it easy to build complex things and is the instructor of India's largest massive open-source online course, The Introduction to Modern Application Development, with over 250,000 students. Can we get a wave, Tanmay?

3. Challenges with GraphQL Tooling and Adoption

Short description:

We should have built-in documentation for the API, at least the spec. Users often prioritize GraphQL metadata over the API method. In enterprise, some prefer REST or GRPC endpoints due to existing tooling. There is a lack of tooling around GraphQL compared to other technologies.

This makes a lot of sense. Why don't we have it? Why haven't we have it? We should have built in documentation about at least the spec, if not the usage pattern of the API. At least the spec of the API should be documented and should be a part of the thing. And what I see from those kinds of users is that they don't really care about GraphQL, the API method. They care more about GraphQL, just the metadata. They're like, you know what, at the end of the day, in fact, especially in enterprise, I would rather not consume a GraphQL API. I would rather consume a REST endpoint or a GRPC endpoint, something that we have the rest of our organization tooling around, because we don't have so much tooling around GraphQL. And so we have so much tooling around so many other things.

4. GraphQL at Scale: Building on Existing Abstraction

Short description:

GraphQL at scale is powerful and accessible. Building on an existing abstraction, the GraphQL layer on top of the internal Facebook abstraction was thin. This allowed for a better relationship between different types of engineers in the organization. Server-side engineers could publish a schema in a constrained way to mobile engineers, resulting in a healthy relationship and better scalability.

Is that they really kind of just fall in love with that metadata, that graph idea that ultimately all of your entities are related in some sort of a graph. And they really liked that aspect. So I think the organizational scale aspect of GraphQL is very, very powerful, right. And is also kind of very accessible to people. So that's kind of been two very interesting things to me about GraphQL at scale.

Yeah. That's super interesting. Yeah, no, I'd like to build on that. Because I think I would have a unique perspective since I was the one who built the first prototype of the thing. And to Dan's point, it was not the fact that it was multi-device. It was kind of the realization of one, up until that point, my career at Facebook had been spent effectively being one of the people who really took it upon themselves to save our application monolith, which bleeds into another subject that we're going to get into later. But we had done a ton of work to build these abstraction layers, and we had actually horizontally scaled our monolith across hundreds of engineers. And then, kind of started to see what would happen with mobile. And what was relatively clear is that you would have mobile engineers going up into the rest, going up and building custom rest APIs. And it was fairly self-evident. Maybe it wasn't self-evident, but I believe at the time that that would've been a disaster. It would've been like the mobile engineers like Visigoths invading Rome and burning down the monolith we had saved. So, really, the critical thing here is one, it was vertically integrated on top of an existing abstraction that was working. So, the GraphQL layer on top of the internal Facebook abstraction was very thin. That's why I was able to build the prototype so quickly, not because I'm some amazing engineer, but because it had stacked on top of work that a whole team had done for like three years. And so, that was one aspect. And then it was really about having a better relationship between the different types of engineers in the organization. Because you could have server side engineers publishing schema in actually a pretty constrained way to mobile engineers that would then consume it. And that turned out to be a very healthy, well, relatively healthy relationship that ended up scale. And I think dramatically better than the inevitable. Because like, this would have been something like move fast, break things, Facebook culture, would have just like spawned, like I said, like an invasion. And I think would have been really challenging to manage. Ironically, not the dependency era, I think in like non Facebook usage of GraphQL is inverted from in Facebook. Is graphical word, but Facebook had a concept of like, yes, these are the objects, you know, call them, and obviously talk more about that. Cause I was, you know, his almost baby, but like it is, you know, they existed and we'd had them for years and they were almost de facto and GraphQL was like, okay, well, we have this concept of the graph.

5. GraphQL: Defining Data Model and Schema Design

Short description:

The graph is great. GraphQL provides flexibility in defining the data model for a company. It simplifies the process of connecting different types of databases and allows for abstract usage by various clients. When designing a schema, it can be tailored to views for efficient app performance. However, using GraphQL to define the data model for the entire company and bringing it up to the API layer can streamline the process and enable direct usage by clients. This approach also facilitates client-side caching and promotes code reuse.

The graph is great. These things have relationships. We understand how to fetch them. We understand how to connect the edge between them. If only we had this on mobile and listening to Tom and talking to, with folks on the outside, it's actually very often people are like, oh, GraphQL makes a lot of sense because I really want that representation. And you almost like you realize how valuable that representation is because it's the representation that makes GraphQL feel most natural. Well, the reason this is a representation that makes GraphQL feel most natural is because it's the representation we had and it's almost this inverted dependency.

Yeah. I think one of the things that really draws me to GraphQL is the idea that once you define what your graph is, you don't have to know exactly how people are going to use it for it to be really useful to them and the right thing for them. One of the things that originally drew Apollo to GraphQL was the idea that it could maybe be a technology to connect many different types of databases together and it's just a really powerful thing to be able to define something that can be used abstractly by any different number of clients because the types of things people are building now are just way beyond what they were even 10 years ago. And you can't always predict how people are going to want to use your API or even keep up with it. So it's best to build flexibility from the get-go.

Danielle, I have a question for you on that front. In Out in the Wild of GraphQL, because I actually don't have too much visibility into it, do you see people building GraphQL schemas that are specific to views? We used to call them view models. Or do you see more GraphQL schemas that are kind of like the core data model?

That's a great question. I mean, I think people do it all sorts of ways. And earlier on, I think our recommendation was that you should design your schema for views because that's going to be the most efficient thing for your apps. And I think when you are building an app, your schema should correlate to it because that's the best thing for the application. But what we've been talking about lately, especially in Apollo, is you should use GraphQL to be the way that you define your data model for your company. And instead of having your data models and lots of different microservices in different places across many different teams, you know, like dedicated teams building the graph, have them define the data model, how every microservice team figure out how they fit into that and build into that. And then your data model can be, like, if you bring it up to the API layer, then it cleans a lot of things up, and it can just be directly what the clients use. Yeah. And it makes client-side caching dramatically more straightforward. Yeah. And also reuse. Sorry, go ahead. And also reuse. One of the things that are sort of amazing is after we define the user object within Facebook, someone went out of field to user, and then the next person came around and was like, oh, shoot, I'm going to need to be able to show, you know, the users cover photo. Oh, it's already there. Cool.

6. Scaling GraphQL Across Organizations

Short description:

GraphQL can be structured around views or used to describe core data models. The use cases for GraphQL vary, from client-centric use cases to platform-centric use cases. The trade-offs and optimization depend on the specific problem being solved. Scaling a graph across an organization can be achieved with Apollo Federation, which allows for defining entities, extending schemas, and relating partial schemas. Federation helps organizations scale their graphs by federating services into an overall picture. Tools are being developed to support this approach. Other opinions on the right way to scale a graph exist.

I'm ready to go. Exactly. Yeah. I think from, to kind of, to answer, to take a stab at Nick's question, right, I've seen both. I've seen people kind of really, like, structuring GraphQL around views. And then, especially for people who are kind of going towards the event-driven microservices kind of style of things to kind of start thinking of, like, GraphQL is the Q in a CQRS kind of workflow, right? So that's, that idea has, that idea seems to have some weight, some momentum. And then I've also seen, of course, ideas where people like having GraphQL kind of describe or, or using GraphQL and kind of the core data models. And I think it kind of boils down to the use cases that people have for GraphQL, right? And I think the, like the client-centric use case, which is perhaps the original kind of the OG use case for GraphQL, right, which is the better client API specifically for front ends, right, to communicate with back ends. But then there's also kind of that platform centric use case, right, which is the use case of like, well, I mean, I don't know what 10,000 models I have, and I want a better way of kind of understanding my models and what methods I have on my models or how to query my models and mutate them or whatever. And so there's, there's both. But you know, it's, and I think like the trade offs and like what people want out of it and what people want to optimize for kind of depends on, you know, what they're really solving for with GraphQL, right, or what is that kind of problem that they really want to attack, whether it's a back end for front end kind of problem that they have so many microservices and they want a better API, or whether it's kind of like our API is just a mess and it's horrible for humans to browse. And how many types are in the Facebook GraphQL scheme of these days? I don't know, but it's got to be five digits. I would have to check. It's not a real scheme until it crashes GraphQL. That's what we used to say. It was very, very apparent where things were quadratic and graphical. I guess these days it's a matter of if you can load it with an Apollo Explorer, if it's going to load or not. But I mean, like I know, Daniel, like, you and your team are working with massive teams and massive graphs, and you're building a lot of tooling and infrastructure to really support all of those teams at scale. So I guess my question is like, essentially, what I'm hearing a lot from the panel so far is that it seems to be more of an organizational scalability type of challenge. It's how do I scale across more engineers, and how do I make the actual domain modeling of my graph kind of self-evident to adding more engineers to the team? You mentioned that that's something that you recommend at Apollo. And I'm just curious, in terms of the tools and the infrastructure that you're working on there, is there anything that you offer within that tool set that can basically help with those types of things? Well, I think the big thing for scaling a graph across the organization that we offer at Apollo is Apollo Federation or Federation in general. I know there are a lot of opinions out there on the right way to build a graph out of multiple subgraphs, and there are many options, but the one that we've been developing is really like to come back to that idea that I said where your API and your graph should be your data model and everything should be feeding into it. Federation is really meant to help you do that because it helps you kind of define entities in certain places, extend them in other places, define how these partial schemas relate to each other. And that's the way that we see organizations being able to scale their graph because you could imagine kind of one service per team in a big company where everyone is kind of federating into the overall picture. So what we're trying to do is build tools to help you use federation and follow a model like that where you can really scale those things effectively. But there, I know that there are probably even on this panel a lot of opinions on what the right way to do that is, so I'm curious to hear from everyone else. Yeah, Tanmay, have you found any sort of ways to be more optimal in scaling?

7. GraphQL Federation and Use Cases

Short description:

It boils down to the use case and the organization. GraphQL or a federation approach with GraphQL can solve the problem of interrelated data between microservices. Traditional enterprises have different problems with a large number of teams catering to specific customer segments. Introducing a single graph for collaboration can overload users and may not be suitable for all use cases. The use case should guide the federation approach and the decision to use GraphQL.

I think, again, it kind of boils really to the, it boils down to the use case of like what you're trying to generate, right? Like, for example, again, if you have this situation where you are, we genuinely have this situation where you have a bunch of mobile or front-end applications, and they've been querying 20 different microservices, and it turns out that all of these services do actually have a lot of interrelated data, right? And you want to create and operationalize a process of maintaining a central API that allows these front-end clients to consume that API, right? And so now you can have different approaches of building that out, right? And I think, again, like it depends on the organization. I've been a little bit skeptical of automatically assembling that federated thing because it'll be interesting to see how that works because it kind of goes almost against the idea of microservices itself to say that, well, we wanted to make these teams independent, but now we've made them dependent again. And they're kind of talking to each other like they should have been perhaps but outside a usual channel of code. And so maybe GraphQL or a federation approach with GraphQL is a way to solve that problem again. But of course, there's more traditional ways of solving that problem, which is just go back to everybody goes back to Monit or you maintain a GraphQL gateway in the center that some team maintains or whatever. So that's kind of one kind of problem that you have. But I think this idea of saying that we should have when you think about like all of the APIs and all of the services in enterprise, not all companies in the world are Facebook, obviously. And they all have very different problems. In fact, traditional enterprise, it's very weird. It is not at all like a tech giant like Facebook. It's extremely different. There's a very, very large number of teams in LOBs like lines of businesses that are catering to very specific customer segments. And for them, the APIs that they're producing, the reason why microservices caught on in the first place was because for them, the APIs that they're producing have a very particular cognitive model around the API that they have. So now, if you suddenly say that I want all of the APIs in my enterprise, which is insane because it's not possible for this massive traditional Fortune 10, Fortune 100 companies to have like this. It is not the same API, they don't even have the same customer. I mean, it's insane across these different LOBs, right? And so here, if you're introducing kind of this idea of saying, well, let's all collaborate on a single graph. It's going to introduce more, an increased cognitive kind of overload on people in consuming that API. They'd be like, no, no, no, no. Please, I don't understand anything that's happening. Please take me back to the 10 endpoints that show me how to make a payment to a merchant and how to refund that payment from a merchant. That is all I want. I don't want to see this graph. So what problem you're trying to solve and what sections you're trying to maybe unify and why you're trying to unify them, right? Again, is it driven from a technical performance back-end or front-end type use case? Is it driven from a platform-centric use case of saying that, well, these 10 teams should have actually been one team and we should have actually had one coherent API. What is the use case? And that use case will kind of guide that different kind of federation approach, or whether you should even be using GraphQL or not, right? Those kinds of things will kind of come out of that, right? It's risky to say that there can be just one approach to GraphQL, because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we use GraphQL for and making that case.

8. GraphQL Use Case and Federation Approaches

Short description:

What is the use case? Different federation approaches and the decision to use GraphQL or not are guided by the use case. The popularity of GraphQL can be explained by the desire to have a monolith back. Assembling microservices into a single schema creates a distributed monolith. Moving compute back into the federation layer gives client teams autonomy. Separate services and GraphQL schemas per line of business are appropriate for completely disaggregated bounded contexts. The decision to use microservices comes down to tradeoffs and the ability to horizontally scale the organization. Separation of concerns is good when the concerns can be separated. Facebook operates as a monolith with separate back ends for different functionalities.

What is the use case? And that use case will kind of guide that different kind of federation approach, or whether you should even be using GraphQL or not, right? Those kinds of things will kind of come out of that, right?

It's risky to say that there can be just one approach to GraphQL, because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we use GraphQL for, but GraphQL for and making that case. Yeah. Tim, I actually love the way that you framed that up about decomposing technical and organizational determinations, because, you know, I have very strong and polemical views on microservices. I think they're overused for sure. And, you know, the way that I think it actually ironically explains a lot of the popularity of GraphQL, because a GraphQL schema is your subconscious telling you that you want your monolith back. And if you want to assemble a set of microservices into a single schema, which in microservices speak would be a single bounded context, if you're kind of into that language, domain-driven design, in my opinion, if that feels correct, then what you have is a distributed monolith, and it should've been a monolith in the first place. And, you know, I think there's going to be this really interesting counter reaction. And you see it in systems, like out of Airbnb, there's a system called Viaduct coming out. At Twitter, there was a system called Strato, where they're actually moving compute back up into this federation layer. And that gives the client teams autonomy where somewhere they can push code where they don't have to talk to the microservice team. And I'm going to be really interested to see if more and more the business logic naturally moves to that, I think you referred to as a GraphQL gateway, maybe it'd be like a smart gateway or something, or to call it like the application microservice, then everyone will be willing to accept it. Whatever it takes. But in the case that you're talking about this separate lines of business, it's actually appropriate, I think, that a separate service and a separate GraphQL schema per line of business, because they are completely disaggregated, bounded contexts or schema. So that's where I'm at. It's a fascinating thing to see, because obviously not everyone who does microservices is an idiot. There's a reason why people feel compelled to do it. They can no longer horizontally scale their org. So I totally get that. So I'm trying to be less flippant on this. You have changed, Mick. This is a change. It all ultimately comes down to tradeoffs, as well. And the one that always comes to mind for me is this separation of concerns. Separations of concerns is good when the concerns can actually be separated, when you're like, hey, these two things can operate independently. And I think what I see Facebook sort of legendarily as a monolith, kind of. Newsfeed has its own back end. Timeline has its own back end. Search has its own back end. It is a monolith in terms of its business logic is monolithic. But in terms of some of, if you're trying to store stateful logic for Newsfeed, yes, that's going to be in a service.

9. Business Logic and Microservices

Short description:

The concerns of the Facebook application cannot be separated due to the interrelated nature of the data. Decoupling microservices can lead to false dependencies. The natural complexity of teams and organizational structures can make it difficult to choose between microservices and monoliths. Some business logic, such as authorization and caching, can be absorbed into a common GraphQL layer. The microservice and federation model is beneficial when different teams want autonomy but need to bring related things together. It depends on the specific situation and organizational structure.

Well, why is the business logic in a monolith? Because of feed. Because fundamentally, you cannot separate the concerns of the Facebook application, the app that you opened. Because you're in a feed, and you see a story about Nick attending this event, and you see a photo that I posted. And you see the fact that Danielle checked in someplace. And all of these sort of things that could presumably be independent services, they do inherently. You cannot separate those concerns. And I exactly sort of shared in a second, which is, if you've got 10 microservices, and they all have the same API, and everyone goes, of course these have the same APIs. Well, how did you actually separate those concerns there? If those 10 things fundamentally need to relate, if the interaction between those 10 services can't be decoupled, they can't be decoupled, and yet we chose to decouple them. And on the other hand, if you can decouple them, it's like, these two graphs are independent, I actually have no idea what value you would get by putting them into the same GraphQL API. That feels sort of like a false dependency.

There is a little more... I think sometimes reality ends up being a little... It's a little harder to say upfront, are we going to be dependent on each other, or are we never going to talk to each other? It's hard to say, right? What we've seen from people is where we've seen separate kind of LOBs, right, or lines of business adopt that, adopt kind of GraphQL, get very productive with it. But then suddenly this team realizes, oh man, there is some data that that team has, which if I had, it'd be amazing. And now suddenly they're like, oh my goodness, what do we do, right? How do we set this up together? We have to build some things. I wish we didn't have to build this, right? So there's a little bit of the natural dirtiness of life that gets in where things are not clear and people don't know how to do things that make it a little bit harder to think about what should be what upfront, right? Especially in teams, which, especially in teams where the organizational structure, promoted autonomy rather than collaboration, right? If you think about with microservices, what's happening is you're having organizations that promote autonomy. With Monoliths, quote unquote you have organizations that are promoting collaboration, right? It's two sides of the, it's the same thing, but a little bit different, right? So, so I think, I think that kind of complicates that it makes it a little bit harder for people to choose upfront, right? So there's some interesting things there. To Nick's point, though, one thing I'd like to add is I like our crazy idea or hypothesis is that there are some kinds of business logic that you can actually absorb into that GraphQL layer that is repetitive that maybe you don't have to repeat again and again, right? And, and for us, our gut feeling is that authorization, when related to data and caching, are two infrastructural, almost concerns, but still concerns that every single developer has to deal with, that could be brought into a common layer, right? So that's kind of the lens that we're taking. Whether it's not necessarily a GraphQL lens, but it's kind of a lens of, like, this is repeat work that we're doing across a bunch of people that maybe we can bring somewhere, right? Which is a type of business logic that can be made common across a large number of people, right? So it would be interesting to kind of see how that evolves, of course. I'd like to hear Danielle's thoughts on this, because I feel like, as a Apollo employee, you're dealing with the kind of aggregating microservices problem a lot.

Yeah, I think where the microservice and federation model shines is like close to what Tanmay said when you have different teams or lines of business that want to have autonomy yet have things that relate to each other and still want to be able to bring those things together. So, I mean, even inside Apollo, we build a big SaaS tool, we use federation, and we have this debate all the time, like, we have some microservices, but we don't have, you know, four teams working on them. We have two and we're like, why do, why did we split these things up? In some ways, we're creating more overhead for ourselves than is beneficial. But in other cases, you know, when you have another team that's entirely independent of you, that's running services that don't relate to you, you're not on call for them, you don't want to be responsible for them. Yet you still, in abstract, think that it's a good idea for those two services to go into the same graph. Then that's where something like federation, I think, shines and kind of enables you to contribute to the same overall thing, while letting teams remain autonomous and keep their own life cycles. So yeah, I mean, it's all like, it depends, right. It depends on what you're trying to do, what's right for you, how your organization is structured. Yeah, it's the messiness in humans. Awesome, that's fantastic.

10. Excitement and Challenges with GraphQL Paradigms

Short description:

With more paradigms being added to GraphQL, there is excitement about seeing the GraphQL spec being applied to those paradigms. A GraphQL lite version is desired for platform-centric use cases, simplifying the mapping between GraphQL queries and REST APIs. Error handling in GraphQL is a challenge due to partial errors and the need for response inspection. A return to a simpler world where existing API tooling can work seamlessly with GraphQL is sought. Software layers on top of GraphQL can help solve compliance and error handling issues.

And yeah, I think we can talk a lot more on this topic, but in the interest of the wider audience that we have, let's move on to a slightly different one. But maybe let's get back to this one before we end things off.

So in terms of the GraphQL spec, I mean, we're all here today because of GraphQL and we're all here today because of the GraphQL grammar and the GraphQL spec. And since the time I've been using GraphQL, it's remained mostly unchanged in terms of the core grammar. The core grammar was fundamentally what it was. But of course, as we keep applying more paradigms to that same grammar, we're starting to see a bit of an evolution in terms of the grammar, in terms of the spec, and in terms of how GraphQL is being used.

So I guess my question is that with more paradigms being added, essentially, what are you most excited to see in terms of GraphQL? Which paradigms are you most excited about? And in which ways are you most excited about seeing the GraphQL spec being applied to those paradigms? And I guess we can start with Tamay. I have a non-controversial answer to this question, which is that I feel like what I would really like is a GraphQL lite, which is a reduction of the GraphQL spec for some of those platform-centric use cases that I talked about, where what I would like to do is say, for example, get rid of, let's say, interfaces and unions, and kind of simplify that a little more. So that essentially the purpose would be so that what I would like to achieve is almost kind of a bijection or a mapping between any GraphQL query to a REST API. And I feel like that can't happen right now because GraphQL has more specific things. It's harder to achieve. Right now, it's a little more complicated, but simplifying that so that we can have like a mapping to a REST API model, I feel like that would be extremely useful to a lot of people who are looking at de-risking their adoption of GraphQL, because then what happens is that they have a lighter way to kind of enter GraphQL with a subset of the spec, but in a way that the rest of their existing tooling doesn't go to the dogs, right, so that there's like... that existing tooling can start to emerge and work, because there's just a tremendous amount of like inertia that the existing API tooling that people have and the tools that they're using and how they've gotten used to it, everything from to API management to error handling, right? Error handling is so confusing in GraphQL because you get partial errors, right? This is a problem that people just... Yeah. Sorry. No, it's not just. It's the forever skeleton in our closet. It's the 200 response problem, right? It's like everybody is used to... there's so many vendor tools today, where if you just plug that into your API, you kind of get like this tool that says, you know, this API is not working because the status code is 4xx or 5xx or whatever, right? But now with GraphQL, you can't do that. You have to kind of inspect the response. So now your vendor tool needs higher privileges to inspect your response. Now nobody's prepared for this because it violates all of their compliance, right? They're like, what? No, there's no way this monitoring tool is getting access to my response body. And so what they want is the return to a simpler world where they're like, well, no, you know, we had already done this. This problem was solved. So maybe... I'm not sure if this moment is even feasible or make sense, but it's just a random idea, right? It's like a random thought process of like, what would happen if GraphQL was maybe a little bit simpler on some things, or maybe simpler is not the right word, right? That that allowed kind of that intercompat or incremental evolution to happen from where people's APIs are today.

So that's a absolutely not a fair question. To be fair, I think a lot of the problems you're describing can be solved with software, software layers on top of GraphQL. So like, you know, like for example, the compliance thing you make, makes total sense. And the the so like, for example, if I was, you know, dealing with that problem, you know, I would try to distinguish errors that are like non ideal states in the application from hard errors, and then have a software layer that translates the hard errors to exactly 100.

11. Challenges with Errors and Streaming Responses

Short description:

I don't think you need to change the spec to solve that. You can choose not to support certain features on the server side. The standardization of tools is important. Errors in the spec need improvement. The community is innovative and can come up with better ideas. AdStream and AdDefer are exciting for streaming responses.

Right, exactly. I don't think you need to change the spec to to solve that actually, 100%. You know, for example, you can also choose server side just simply not to support or to link to a search against using certain features, such as the bijection that you're talking about. So got it. You know, I think you we you know, we can solve that. And so completely agreed.

Yeah. Yeah. And I, the reason why I used I said spec is because I think those tools need to get a little bit standardized, right? Because what people don't want to do is they're like, wait, no, I don't want to build this software that will do this for me, right? Like I don't want another piece of software to maintain. I just want this to be done. Right? So you want to rescue our spec? I want to rescue. Exactly. That's the I would love to see continued work in errors. I mean, Nick and I were sort of laughing at it. I have a very distinct memory of a conversation where I was just like, what do we do with errors in the spec? And it's like, well, the way that we handle errors is bad. So we can put that in and that's a bad idea, or we could guess and try and put something else in there or we could leave it relatively underspecified. And like, I think it is, it is a really hard problem. And if, you know, evolution in the community, a better idea, like I, I don't like how errors are handled right now. I hope we come up with something better. And the community is innovative. Like I actually think that Saatchi's pattern, Oh yeah. The union era pattern. It's just like, what's that? And I was like, why don't we think of that? But thank God we had the generalized abstractions to support that. That time I wants to get rid of, no, I'm just kidding.

One thing that I'm really excited about is AdStream and AdDefer. Where I feel like those sorts of, you know, streaming responses is something that, you know, we, I think it was probably 2013 when we realized, okay, yeah. If we're vending 10 feed stories, we can't wait for all 10. And we don't want to do multiple round trips to do one plus one plus eight. We need some sort of stream. And, you know, we used, it wasn't built into GraphQL.

12. GraphQL Batch API and the Value of Directives

Short description:

It was built into the graph API, a batch API. And then we built a GraphQL batch API. I think it's some real value that it can create. It comes up so much in our tooling requests, AdStream and AdDefer, that is like top of the list for years. One nice thing about the spec in general is that directives do let you extend it in a lot of ways. Directives are great.

It was built into the graph API, a batch API. And then we built a GraphQL batch API. And I think we're finally sort of reaching something that really is a nice declarative model. It's complex. The fact that we've been able to work on it with the community and that a lot of the work in the open source has been community driven, but using the sort of like work that we did within Facebook to try it out, I think we're going to come to a really nice conclusion.

I also think it's nice in that if you don't want AdStream and AdDefer, which in many cases you don't, like ban those directives, sure. Like that is entirely reasonable, but I think a lot of people are going to realize, hey, this is extremely valuable. I am, you know, ultimately I have a UI collection view or I have a list view. It's kind of nice to be able to bend exactly the first screen and then get the rest in order to improve performance. It's a common enough need. It's a complex enough problem that I think it's some real value that it can create. It comes up so much in our tooling requests, AdStream and AdDefer, that is like top of the list for years.

Yeah, no, I know. I will say one nice thing about the spec in general is that directives do let you extend it in a lot of ways. I mean, you guys are smiling, that was very forward thinking. That has allowed people to do a lot more than I'm sure you imagined at the beginning. Dylan do you want to tell everyone? This is I pushed back pretty strongly on adding directives because it was brand new in the spec and I was very much the person in the room being like, if we haven't tried it internally, are we really just going to guess and check in the spec? And a lot of things did not make it in based on the are we really going to guess and check? And directives, Nick and they are like, yes, yes, we are. This is really good. And they were absolutely... Yeah. I was like, Dan, this time Lee is like the Babe Ruth of distractions. Directives are great. He's calling it. I will stake my reputation on this. And rightly so. Well, hey, fantastic. Thank you all so much, everyone. I just got the one minute time notification that we're almost out of time. So, while I would honestly love to just keep talking because I've had so much fun just listening to all the wisdom that's been shared today. And I really want to dive deeper on a lot of those fantastic topics.

13. Closing Remarks and Contact Information

Short description:

But maybe we can catch you guys in spatial chat or somewhere else and keep the conversation going. I'm sure the community would love to hear more. But I guess we're out of time. Thank you all so much for all of your kind thoughts and kind wisdom. If you'd like to hear more from the panelists, I'm sure you can find them on the GraphQL Galaxy website. See you around. Thank you.

But maybe we can catch you guys in spatial chat or somewhere else and keep the conversation going. Because I mean, it's a pretty good one, and I'm sure the community would love to hear more. But I guess we're out of time. So that's it for the panel. And thank you all so much for all of your kind thoughts and kind wisdom.

I'm sure everyone that I'm seeing in the Q&A is really enjoying it. And yeah, if you'd like to hear more from the panelists, I'm sure you can find them on the GraphQL Galaxy website, and they have their contact information on there. And thank you all so much once again. See you around. Thank you.

QnA

Exploring GraphQL Scaling Benefits

Short description:

Discussion on the importance of GraphQL in scaling technology efficiently and addressing common challenges in large-scale projects.

That's a lot of people. Yep, yep, yep. Just the online nature of the course really helps with that. That's awesome, dude. Well, it's a pleasure to meet you all and it's a pleasure to talk to you all about GraphQL at scale.

So I guess without further ado, let's kick it off with a question. As I mentioned before, I think GraphQL is inherently a technology of scale. It was formulated at Facebook when scaling their data layer to accommodate multiple device form factors. So what aspects of GraphQL drew you to it when addressing those types of challenges of scale? Let's start with Dan. Yeah, I think the way in which it scales is interesting because it scaled differently over time in its evolutions at Facebook. The original problem of scale anticipated the need for multiple clients, even just scaling within a given client.

I think one of the original scaling factors that didn't necessarily draw us to GraphQL but drew us to Create was the ability for a client engineer to add features without versioning a server. Another aspect of GraphQL at scale is the technical aspect, where technology teams can scale and repeat work efficiently. GraphQL provides formalism for interactions at scale, offering solutions for common challenges like type safety, batching API calls, and more. This technical aspect of GraphQL's scalability is exciting and crucial for handling large-scale projects.

Exploring GraphQL Scale Aspects

Short description:

Discussion on the significance of GraphQL in enabling efficient scaling and formalizing interactions for technology teams to address common challenges.

It obviously has proved very helpful in having multiple clients at once. Even just scaling within a given client, the ability for a client engineer to say, hey, I'm going to add this feature now. They don't have to version a server. They don't have to potentially make a server change if the data's already there because of the graph nature of it. I think that was probably one of the original scaling factors that I think didn't necessarily draw us to it, but drew us to Create.

I think one of the things that drew me to GraphQL, especially from scale aspect, was I think especially over the last few years from what I've seen in the ecosystem, is that there's two aspects to scale that are particularly important with GraphQL. The first is this technical aspect, which is that your technology team is scaling. There's a bunch of work that you're doing that is going to be repeated across all of these engineers whether they're consuming the API, building the API and whatnot. And GraphQL really creates a formalism for people to interact when they hit those levels of scale. You realize that, oh, well, we need to have something like fragments. But then it turns out, well, GraphQL has it. You need to have type safety and GraphQL has to expect.

Understanding Organizational Impact of GraphQL

Short description:

Discussion on the organizational scale aspect of GraphQL and its appeal for metadata management in enterprise contexts. It highlights the preference for GraphQL's metadata over API methods and the power of structuring entities in a graph. Additionally, it delves into the unique perspective of building the first prototype and the challenges faced in transitioning to mobile development amidst existing architectural complexities.

So those technical aspects, or you realize that you're making multiple API calls, you should just be making a better batched API call. And GraphQL is in a way, this amazing batching technology. And so that aspect is exciting for sure. But I think there's also another interesting aspect of GraphQL at scale. And I see this especially in enterprise with what really appeals to people about GraphQL is not so much the technical awesomeness of what GraphQL lets you do, which is let's say performance and type safety. And to a degree maybe type safety, but also not the performance aspect of it and whatnot, but kind of more the metadata aspect of it, which is that this aspect of saying that we have this ability or we have this formal way or this way of specificifying our API and exchanging information about an API. And this is kind of more of a organizational human problem of scale rather than the technical aspect of scale, right? Which is saying that we should have really just done this right the first time, right? Like we should have had APIs, we should have documented them, we should have had like open API specs or whatever, right? It should have been better, but it's not. And for them, the appeal of GraphQL is, oh, finally, yes, this makes sense. We should have like this Explorer tool, like graphical. This makes a lot of sense. Why don't we have it? Why haven't we have it? We should have built-in documentation about at least the spec, if not the usage pattern of the API, at least the spec of the API should be documented and should be a part of the thing. And what I see from those kinds of users, right, is that they don't really care about GraphQL, the API method. They care more about GraphQL, just the metadata. They're like, you know what? At the end of the day, in fact, especially in enterprise, I would rather not consume a GraphQL API. I would rather consume a REST endpoint or a gRPC endpoint, something that we have the rest of our organizational tooling around, because we don't have so much tooling around GraphQL. And so we have so much tooling around so many other things is that they really kind of just fall in love with that metadata, that graph idea that ultimately all of your entities are related in some sort of a graph, right. And they really like that aspect, right. So I think the organizational scale aspect of GraphQL is very, very powerful, right, and it is also kind of very accessible to people. So that's kind of been two very interesting things to me about GraphQL at Skip. Yeah. That's super interesting. Oh, go ahead. Yeah. No, I'd like to build on that because I think I would have a unique perspective since I was the one who built the first prototype of the thing. And it was to Dan's point, it was not the fact that it was multi-device. It was kind of the realization of one, up until that point, my career at Facebook had been spent effectively being one of the people who really took it upon themselves to save our application monolith, which bleeds into another subject that we're going to get into later. But we had done a ton of work to build these abstraction layers and we had actually horizontally scaled our monolith across hundreds of engineers. And then it kind of started to see what would happen with mobile. And what was relatively clear is that you would have mobile engineers going up into the rest state, going up and building custom REST APIs. And it was fairly self-evident, maybe it wasn't self-evident, but I believe at the time that that would have been a disaster.

Fostering Engineer Relationships with GraphQL

Short description:

Discussion on the critical integration of GraphQL within existing abstractions at Facebook, emphasizing the thin GraphQL layer on top of internal abstractions. It highlights the importance of fostering relationships between different types of engineers for successful scaling and contrasts the dependency era between Facebook and non-Facebook use of GraphQL, focusing on the concept of the graph and its representation.

It would have been like the mobile engineers like Visigoths invading Rome and burning down the monolith we had saved. Um, so really the critical thing here is one, it was vertically integrated on top of an existing abstraction that was working. So the, the GraphQL layer on top of the internal Facebook abstraction was very thin. That's why I was able to build the prototype so quickly, not because I'm some amazing engineer, but because the, the, it had stacked on top of work that a whole team had done for like three years. And so that was one aspect. And then it was really about having a better relationship between the different types of engineers in the organization. Cause you could have server side engineers, publishing schema, and actually a pretty constrained way to mobile engineers that would then consume it. And that turned out to be a very help. Well, relatively healthy relationship that ended up scale. And I think dramatically better than the inevitable. Cause this would have been something where move fast, break things, Facebook culture would have just spawned, like I said, an invasion. And I think would have been really challenging to manage. Ironically enough, the dependency era, I think, in non-Facebook usage of GraphQL is inverted from in Facebook use of GraphQL where Facebook had a concept of, yes, these are the objects, call them ends, and Shrek can obviously talk more about that cause I was, his mom was a baby, but like it is, they existed and we'd had them for years and they were almost de facto. And GraphQL was like, okay, well we have this concept of the graph. The graph is great. These things have relationships. We understand how to fetch them. We understand how to connect the edge between them. If only we had this on mobile and listening to Tanmay and talking with folks on the outside, it's actually very often people are like, oh, GraphQL makes a lot of sense because I really want that representation. And you almost like, you realize how valuable that representation is because it's the representation that makes GraphQL feel most natural.

Defining Flexible Data Models with GraphQL

Short description:

Discussion on the flexibility and power of GraphQL in abstractly defining data models for various client needs, highlighting the importance of building flexibility into APIs from the beginning and the shift towards using GraphQL to define company data models for efficient application development and client-side caching.

Well, the reason this is a representation that makes GraphQL feel most natural is because it's the representation we had. And like the, it's almost this inverted dependency. I think one of the things that really draws me to GraphQL is the idea that once you define what your graph is, you don't have to know exactly how people are going to use it for it to be really useful to them and the right thing for them. Like one of the things that originally drew Apollo to GraphQL was the idea that it could maybe be a technology to connect many different types of databases together. And it's just a really powerful thing to be able to define something that can be used abstractly by any different number of clients because the types of things people are building now are just way beyond what they were even 10 years ago. And you can't always predict how people are going to want to use your API or even keep up with it, so it's best to build flexibility from the get-go.

And you know, I have a question for you on that front. And in out in the wild of GraphQL, because I actually don't have too much visibility into it. Do you see people building GraphQL schemas that are specific to views? We used to call them view models. Or do you see more GraphQL schemas that are kind of like the core data model? That's a great question. I mean, I think people do it all sorts of ways. And earlier on, I think our recommendation was that you should design your schema for views, because that's going to be the most efficient thing for your apps. And I think when you are building an app, your schema should correlate to it, because that's the best thing for the application. But what we've been talking about lately, especially in Apollo, is you should use GraphQL to be the way that you define your data model for your company.

Instead of having your data models in lots of different microservices in different places across many different teams, dedicate a team to building the graph, have them define the data model, have every microservice team figure out how they fit into that and build into that, and then your data model can be... If you bring it up to the API layer, then it cleans a lot of things up, and it can just be directly what the clients use. And it makes client-side caching dramatically more straightforward. Sorry, go ahead. And also reuse. One of the things that was sort of amazing is after we defined the user object within Facebook, someone went out of field to user, and then the next person who came around was like, oh, shoot, I'm going to need to be able to show the user's cover photo. Oh, it's already there. Cool, I'm ready to go.

Structuring GraphQL for Varied Use Cases

Short description:

Discussing the varied approaches to structuring GraphQL around views or core data models based on different use cases and organizational scalability challenges, touching on the complexity of Facebook's GraphQL schema and the need for tools and infrastructure to support large teams in scaling GraphQL across organizations.

Exactly. Yeah, I think to take a stab at Nick's question, right? I've seen both I've seen people kind of really like structuring GraphQL around views. And then especially for people who are kind of going towards that event-driven microservices kind of style of things to kind of start thinking of like GraphQL as the Q in a CQRS kind of workflow, right? So that idea seems to have some weight and some momentum. And then I've also seen, of course, ideas where people like having GraphQL kind of described or using GraphQL around kind of the core data models. And I think it kind of boils down to the use cases that people have for GraphQL, right? And I think the client-centric use case, which is perhaps the original kind of the OG use case for GraphQL, right? Which is the better client API specifically for frontends, right? To communicate with backends. But then there's also kind of that platform-centric use case, right? Which is the use case of like, well, I mean, I don't know what 10,000 models I have and I want a better way of kind of understanding my models and what methods I have on my models or how to query my models or mutate them or whatever. And so there's both, but, you know, and I think like the trade-offs and like what people want out of it and what people want to optimize for kind of depends on, you know, what they're really solving for with GraphQL, right? Or what is that kind of problem that they really want to attack? Whether it's a back end for front end kind of problem that they have so many microservices and they want a better API or whether it's kind of like our API is just a mess and it's horrible for humans to browse, right?

Anne, how many types are in the Facebook GraphQL schema these days? I don't know, but it's got to be five digits. I would have to check. 25. It's not a real scheme until it crashes graphical, that's what we used to say. It was very, very apparent where things were quadratic and graphical earlier on. Exactly. I guess these days it's a matter of if you can load it with an Apollo Explorer if it's going to load or not. But I know, Danielle, you and your team are working with massive teams and massive graphs, and you're building a lot of tooling and infrastructure to really support all of those teams at scale. So I guess my question is, essentially what I'm hearing a lot from the panel so far is that it seems to be more of an organizational scalability type of challenge is how do I scale across more engineers? And how do I make the actual domain modeling of my graph kind of self-evident to adding more engineers to the team? So you mentioned that's something that you recommend at Apollo. And I'm just curious in terms of the tools and the infrastructure that you're working on there, is there anything that you offer within that tool set that can basically help with those types of things?

Optimizing Federation for GraphQL Scale

Short description:

Discussing the importance of Federation in scaling GraphQL graphs by defining entities, extending schemas, and facilitating collaboration among teams within organizations to achieve effective scaling and providing different perspectives on federation approaches for optimizing and scaling GraphQL based on specific use cases and organizational needs.

I know there are a lot of opinions out there on the right way to build a graph out of multiple sub graphs, and there are many options. But the one that we've been developing is really to come back to that idea that I said where your API and your graph should be your data model and everything should be feeding into it. Federation is really meant to help you do that because it helps you kind of define entities in certain places, extend them in other places, define how these partial schemas relate to each other. And that's the way that we see organizations being able to scale their graph, because you could imagine kind of one service per team in a big company where everyone is kind of federating into the overall picture. So what we're trying to do is build tools to help you use Federation and follow a model like that where you can really scale those things effectively.

I know that there are probably even on this panel a lot of opinions on what the right way to do that is, so I'm curious to hear from everyone else. Yeah, Tenmai, have you found any sort of ways to be more optimal and scalable? I think, again, it kind of boils down to the use case of what you're trying to federate, right? For example, again, if you have this situation where you are like, we genuinely have the situation where you have a bunch of mobile or front-end applications, and they've been querying 20 different microservices, and it turns out that all of these services do actually have a lot of interrelated data, right? And you want to create and operationalize a process of maintaining a central API that allows these front-end clients to consume that API, right? And so now you can have different approaches of building that out, right? And I think, again, like it depends on the organization.

I've been a little bit skeptical of automatically assembling that federated thing because it'll be interesting to see how that works. Because it kind of goes almost against the idea of microservices itself to say that, well, we wanted to make these things independent, but now we've made them dependent again. And they're kind of talking to each other like they should have been perhaps, but outside a usual channel of code. And so maybe GraphQL or a federation approach with GraphQL is a way to solve that problem again. But of course, there's more traditional ways of solving that problem, which is just to go back to everybody goes back to Monith or you maintain a GraphQL gateway in the center that some team maintains or whatever. So that's kind of one kind of problem where you have this.

Navigating GraphQL Federation Challenges

Short description:

Discussing challenges in aligning diverse enterprise APIs with the concept of a unified graph, emphasizing the cognitive overload of a single graph for varied business segments and the necessity to evaluate the use case for federation. Highlighting the complexity of unifying APIs in traditional enterprises and the risk of assuming a singular GraphQL approach due to diverse API and GraphQL utilization, prompting the consideration of technical, organizational, and platform-centric use cases in federation decision-making.

So that's kind of one kind of problem where you have this. But I think this idea of saying that we should have... When you think about all of the APIs and all of the services in enterprise, not all companies in the world are Facebook, obviously, right? And they all have very different problems. In fact, traditional enterprise, it's very weird. It is not at all like a tech giant like Facebook, it's extremely different. There's a very, very large number of themes in LOBs like lines of businesses that are catering to very specific customer segments. And for them, the APIs that they're producing, the reason why microservices caught on in the first place was because for them, the APIs that they're producing, there's a very particular cognitive model around the API that they have. So now, if you suddenly say that I want all of the APIs in my enterprise, which is insane, because it's not possible for this massive like traditional Fortune 10, Fortune 100 companies to have the same. It is not the same API. They don't even have the same customer. I mean, it's insane across these different LOBs.

And so here, if you're introducing this idea of saying, well, let's all collaborate on a single graph, it's going to introduce more of an increased cognitive overload on people in consuming that API. They'd be like, no, no, no, no. Please, I don't understand anything that's happening. Please, take me back to the 10 end points that show me how to make a payment to a merchant and how to refund that payment from a merchant. That is all I want. I don't want to see this graph. So what problem you're trying to solve and what sections you're trying to maybe unify and why you're trying to unify them, again, is it driven from a technical performance back-end or front-end-type use case? Is it driven from a platform-centric use case of saying that, well, these 10 teams should have actually been one team and we should have actually had one coherent API. What is the use case? And that use case will guide that different kind of federation approach or whether you should even be using GraphQL or not. Those kinds of things will come out of that.

It's risky to say that there can be just one approach to GraphQL because all of us here have very different ideas of what we use APIs for and what we use GraphQL for, what we used GraphQL for or built GraphQL for, and make an advanced decision. Tim, I actually love the way that you frame that up about decomposing technical and organizational determinations because I have very strong and polemical views on microservices. I think they're overused for sure. I think it actually ironically explains a lot of the popularity of GraphQL because a GraphQL schema is your subconscious telling you that you want your monolith back. And if you want to assemble a set of microservices into a single schema, which in microservices speak would be a single bounded context. If you're kind of into that language, domain different design. In my opinion, if that feels correct, then what you have is a distributed monolith, and it should have been a monolith in the first place. And I think there's going to be this really interesting counter reaction. And you see it in systems like out of Airbnb, there's a system called Viaduct. It's coming out.

Balancing Interrelated Microservices in GraphQL

Short description:

Exploring the necessity for separate GraphQL schemas per line of business to accommodate distinct concerns and the challenges of integrating independent yet interrelated microservices in a unified API architecture. Highlighting the fine balance between autonomy and collaboration in organizational structures regarding microservices and monolithic architectures, emphasizing the complexities of decision-making regarding dependency and independence within GraphQL implementations.

At Twitter, there was a system called Strato where they're actually, they're moving compute back up into this federation layer. So that gives the client teams autonomy where somewhere they can push code where they don't have to talk to the microservice team. And I'm going to be really interested to see if more and more of the business logic naturally moves to that, you know, I think you referred to as a GraphQL gateway, maybe be like a smart gateway or something, or to like, call it like the application microservice, then everyone will be like, willing to accept it. You know, whatever it takes. So but in the case that you're talking about this separate lines of business, it's actually appropriate, I think that a separate service and a separate GraphQL schema, per line of business, because they are completely desegregated. bounded context or schema. So that's kind of where I'm at. It's a fascinating thing to see, because like, obviously, like not everyone who does microservices is like an idiot. You know, there's like a reason why people feel compelled to do it. They can no longer horizontally scale their org. So I totally get that. So I'm trying to be less flippant. I'm this. You have changed, Vic. It ultimately comes down to tradeoffs as well. And so, you know, the one that always comes to mind for me is this separation of concerns. Like separations of concerns is good when the concerns can actually be separated. When you're like, hey, these two things can operate independently.

And I think, you know, what I see if Facebook sort of legendarily is a monolith, kind of like News Feed has its own backend, Timeline has its own backend search has its own backend, like, you know, it is a monolith in terms of its business logic is monolithic. But in terms of some of, you know, if you're trying to store stateful logic for News Feed, yes, that's going to be in a service. Well, why is the business logic in a monolith? Because of feed, because fundamentally, you cannot separate the concerns of the, you know, Facebook application, the app that you open, because you're in a feed, and you see a story about, you know, Nick, attending, you know, this event, and you see a photo that I posted. And you see, you know, the fact that, you know, Danielle checked in someplace and all of these sort of things that could presumably be independent services, they do inherently, like you cannot separate those concerns. And I exactly sort of shared an excitement, which is if you've got 10 microservices, and they all have the same API, it goes, of course, these have the same API's. Well, how did you actually separate those concerns there? If those 10 things fundamentally need to relate if the interaction between those 10 services, you know, can't be decoupled, we can't be decoupled, and yet we chose to decouple them.

And on the other hand, if you can decouple them, it's like these two graphs are independent. I actually have no idea what value you would get by putting them into the same GraphQL API that feels sort of like a false dependency. There is a little more, I think sometimes reality ends up being a little, like, it's a little harder to say upfront, are we going to be dependent on each other, or are we never going to talk to each other, right? It's hard to say, right? Like, what we've seen from people is where we've seen like separate, like kind of LLBs, right, or lines of business, adopt that, adopt kind of GraphQL, get very productive with it. But then suddenly this team realizes, oh, man, there is some data that that team has, which if I had, it'd be amazing, right? And now suddenly they're like, oh, my goodness, what do we do, right? Like, how do we set this up together? We have to build some things. I wish we didn't have to build this, right? So there's a little bit of like the natural dirtiness of life that gets in, where things are not clear and people don't know how to do things that make it a little bit harder to think about what should be what upfront, especially in teams which especially in teams where the organizational structure promoted autonomy rather than collaboration, right? If you think about, with microservices, what's happening is you're having organizations that promote autonomy.

Evolving Microservices and GraphQL Specifications

Short description:

Exploring the integration of business logic into the GraphQL layer, focusing on authorization, data, and caching concerns for developers. Highlighting the benefits of the microservice and federation model in promoting autonomy while enabling collaboration and discussing the evolving nature of GraphQL specifications and paradigms.

With monoliths, quote-unquote, you have organizations that are promoting collaboration, right? It's two sides of the, it's the same thing, but a little bit different, right? So, I think, and I think that kind of complicates that it makes it a little bit harder for people to choose upfront, right? So there's some interesting things there. To Nick's point, though, one thing I'd like to add is, like our crazy idea hypothesis is that there are some kinds of business logic that you can actually absorb into that GraphQL layer. And it's repetitive that maybe you don't have to repeat again and again, right? And, for us, our gut feeling is that authorization when related to data and caching are two infrastructural almost concerns, but still concerns that every single developer has to deal with that could be brought into a common layer, right? So that's the lens that we're taking with it. It's not necessarily a GraphQL lens, but it's a lens of, like, this is repeat work that we're doing across a bunch of people that maybe we can bring somewhere, right? Which is a type of business logic that can be made common across a large number of people, right?

But so it would be interesting to kind of see how that evolves, of course. I'd like to hear Danielle's thoughts on this because I feel like as an Apollo employee you're dealing with the kind of aggregating microservices problem a lot. Yeah, I think where the microservice and federation model shines is, like, close to what Tanmay said, when you have different teams or lines of business that want to have autonomy yet have things that relate to each other and still want to be able to bring those things together. So I mean, even inside Apollo, we build a big SaaS tool, we use federation, and we have this debate all the time. Like, we have some microservices, but we don't have, you know, four teams working on them, we have two, and we're like, why do why did we split these things up? In some ways, we're creating more overhead for ourselves than but in other cases, you know, when you have another team that's entirely independent of you, that's running services that don't relate to you, you're not on call for them, you don't want to be responsible for them, yet you're still in abstracting that it's a good idea for those two services to go into the same graph.

Then that's for something like federation, I think, shines and kind of enables you to contribute to the same overall thing while letting teams remain autonomous and keep their own life cycles. So yeah, I mean, it's all like it depends, right? It depends on what you're trying to do, what's right for you. Higher organization is structured. It's yeah, it's the messiness of humans. Awesome. Wichita. That's fantastic and, yeah, I think we can we can talk a lot more on this topic, but in the interest of the wider audience that we have, let's move on to a slightly different one, but maybe let's get back to this one before we end things off. So in terms of the GraphQL spec, I mean, we're all here today because of GraphQL and we're all here today because of the GraphQL grammar and the GraphQL spec. And since the time I've been using GraphQL, it's remained mostly unchanged in terms of the core grammar.

Evolving Paradigms and GraphQL Lite Proposal

Short description:

With the evolution of GraphQL, the idea of a 'GraphQL Lite' is proposed to simplify the spec for platform-centric use cases, aiming for a more straightforward mapping to rest APIs to ease adoption and integration with existing tooling.

The core grammar is was fundamentally what it was. But of course, as we keep applying more paradigms to that same grammar, we're starting to see a bit of an evolution in terms of the grammar, in terms of the spec, and in terms of how GraphQL is being used. So I guess my question is that with more paradigms being added, like essentially, what are you most excited to see in terms of GraphQL? Like, which paradigms are you most excited about? And in which ways are you most excited about seeing the GraphQL spec being applied to those paradigms? And I guess we can start with Tami.

I had, I was, I had a, I have a, I have a non-answer controversial answer to this question, which is that, I feel like what we can, I feel like what I would really like is a GraphQL Lite, which is a reduction of the GraphQL spec. For, for some of those kinds of platform-centric use cases that I talked about, where what I would like to do is kind of like, say, for example, get get rid of like, let's say, interfaces and unions, right. And kind of like simplify that a little more so that essentially the purpose would be so that what I would like to achieve is almost a kind of a bijection or a mapping between any GraphQL query to a rest API.

And I feel like that can't happen right now, because GraphQL has more specific things. It's harder to achieve right now. It's a little more complicated. But simplifying that so that we can have like a mapping to a rest API model, I feel like that would be extremely useful to a lot of people who are looking at de-risking their adoption of GraphQL, because then what happens is that they have a lighter way to kind of enter GraphQL with a subset of the spec, but in a way that the rest of their existing tooling doesn't go to the dogs, right? So that existing tooling can start to emerge and work right, because it's just a tremendous amount of like inertia that the existing API tooling that people have and the tools that they're using and how they've gotten used to it.

Challenges with Error Handling in GraphQL

Short description:

Error handling complexities in GraphQL lead to challenges with vendor tools and compliance, suggesting a need for simplification and software solutions to address error distinctions and standardization efforts.

Everything from OAuth to API management to error handling. Error handling is so confusing in GraphQL because you get partial errors, right? This is a problem that people just, yeah. So sorry... No, no, no, no. It's not just, not it's not just a forever skeleton in our closet. Yeah. It's the 200 response problem, right? It's like everybody is used to, there's so many vendor tools today where if you just plug that into your API, you kind of get like a tool that says this API is not working because the status code is 4xx or 5xx or whatever, right? But now with GraphQL you can't do that. You have to kind of inspect the response. So now your vendor tool needs higher privileges to inspect your response. Nobody's prepared for this because it violates all of their compliance, right? They're like, what? No, there's no way this monitoring tool is getting access to my response body. And so what they want is the return to a simpler world where they're like, well, no, we had already done this, this problem was solved. So maybe I'm not sure if this moment is even feasible or make sense, but it's just a random idea, right? It's like a random, like a thought process of like what would happen if GraphQL was maybe a little bit simpler on some things or maybe simpler is not the right word, right? That allowed kind of that intercompat or incremental evolution to happen from where people's APIs are today. So, that's a- To be fair, I think a lot of the problems you're describing can be solved with software, software layers on top of GraphQL. So like, for, you know, like, for example, the compliancy you make makes total sense and the, so like, for example, if I was, you know, dealing with that problem, you know, I would try to distinguish errors that are like non-ideal states in the application, from hard errors and then have a software layer that translates the hard errors to a- Exactly. To a hundred, right? Exactly. I don't think you need to change the spec to solve that actually. A hundred percent. You know, for example, you can also choose server-side just simply not to support or to link or assert against using certain features, such like the bijection that you're talking about. So- Correct, correct. You know, I think you, we, you know, we can solve that in the software- Completely agreed. Yeah, yeah. And I, I, I, the reason why I, I used, I said spec is because I think those tools need to get a little bit standardized, right? Because what people don't want to do is they're like, wait, no, I don't want to build this software that will do this for me, right? Like I don't want another piece of software to maintain, I, I just want this to be done, right? So- You want to, you want to rescue our spec, that's what I'm saying. Yeah, I want to rescue, exactly, that's the- I would love to see continued work in errors. I mean, Nick and I were sort of laughing about it. I have a very distinct memory of a conversation where it was just like, what do we do with errors in the spec? And it's like, well, the way that we handle errors is bad. So we can put that in, and that's a bad idea. Or we could guess and try and put something else in there, or we could leave it relatively underspecified. And like, I think it is, it is a really hard problem. And if, you know- Understand. Evolution in the community a better idea.

Innovative Approaches in GraphQL Directives

Short description:

Expressing dissatisfaction with current error handling methods, optimistic about innovative community solutions like AdStream and AdDefer for streaming responses, and the value they bring in improving performance and complex problems. Acknowledging the flexibility and forward-thinking nature of directives in GraphQL specifications.

Like, I don't like how errors are handled right now. I hope we come up with something better. And the community is innovative. Like, I actually think that Saatchi's pattern of- Oh yeah, the union error pattern. It's just like, it's just like, what's that about? And I was like, what? Ugh, what do we think of that? But thank God we had the generalized abstractions to support that. That time I once get rid of- No, I'm just kidding. Um, one thing that I'm really excited about is AdStream and AdDefer. Where I feel like those sorts of, you know, streaming responses is something that, you know, I think it was probably 2013 when we realized, okay, yeah, if we're vending 10 feed stories, we can't wait for all 10 and we don't wanna do multiple round trips to do one plus one plus eight. We need some sort of stream. And, you know, we used, it wasn't even built into GraphQL. It was built into the graph API, a batch API, and then we built a GraphQL batch API. And I think we're finally sort of, you know, reaching something that really is a nice declarative model that's complex. The fact that we've been able to work on it with the community and that a lot of the work in the open source has been community driven. You know, but using the sort of like work that we did within Facebook to try it out, I think we're gonna come to a really nice conclusion. I also think it's nice in that if you don't want AdStream and AdDefer, which in many cases you don't, like ban those directives, sure. Like that is entirely reasonable, but I think a lot of people are going to realize, hey, this is extremely valuable. I am, you know, ultimately I have a UI collection view or I have a list view. It's kind of nice to be able to vend exactly the first screen and then get the rest in order to improve performance. It's a common enough need. It's a complex enough problem that I think is some real value that it can create. It comes up so much in our tooling requests at stream and AdDefer that is like top of the list for years. But one thing is like... Yeah, I know, I know. Seriously, I will say one nice thing about the spec in general is that directives do let you extend it in a lot of ways. Like that, I mean, you guys are smiling. I just, that was very forward thinking that has allowed people to do a lot more than I'm sure you'd imagined at the beginning. Dan, do you want to tell everyone? No, I pushed back pretty strongly on adding directives because it was brand new in the spec and I was very much the person in the room being like, if we haven't tried it internally, are we really just going to guess and check in the spec? And a lot of things did not make it in based on the, are we really going to guess and check? And directives, Nick and Lee are like, yes, yes, we are. This is really good and they were absolutely- Yeah, I was like, Dan, this time, Lee is like the Babe Ruth of distractions. Directives are great, he's calling it. I'll stake my reputation on this.

Concluding Remarks and Gratitude

Short description:

Expressing gratitude for the engaging conversation and shared wisdom during the panel. Encouraging further discussions in spatial chat or other platforms. Thanking the audience for their participation and directing them to connect with panelists on the GraphQL Galaxy website.

And rightly so. Well, hey, fantastic. Thank you all so much, everyone. I just got the one minute time notification that we're almost out of time. So while I would honestly love to just keep talking because I've had so much fun just listening to all the wisdom that's been shared today and I really want to dive deeper on a lot of those fantastic topics. But maybe we can catch you guys in spatial chat or somewhere else and keep the conversation going because it's a pretty good one and I'm sure the community would love to hear more.

But I guess we're out of time so that that's it for the panel. And thank you all so much for all of your kind thoughts and kind wisdom. I'm sure everyone that I'm seeing in the Q&A is really enjoying it. And yeah, if you'd like to hear more from the panelists, I'm sure you can find them on the GraphQL Galaxy website and they have their contact information on there and thank you all so much once again.

See you around. Thank you. Thanks for having us.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

From GraphQL Zero to GraphQL Hero with RedwoodJS
GraphQL Galaxy 2021GraphQL Galaxy 2021
32 min
From GraphQL Zero to GraphQL Hero with RedwoodJS
Top Content
Tom Pressenwurter introduces Redwood.js, a full stack app framework for building GraphQL APIs easily and maintainably. He demonstrates a Redwood.js application with a React-based front end and a Node.js API. Redwood.js offers a simplified folder structure and schema for organizing the application. It provides easy data manipulation and CRUD operations through GraphQL functions. Redwood.js allows for easy implementation of new queries and directives, including authentication and limiting access to data. It is a stable and production-ready framework that integrates well with other front-end technologies.
Local State and Server Cache: Finding a Balance
Vue.js London Live 2021Vue.js London Live 2021
24 min
Local State and Server Cache: Finding a Balance
Top Content
This Talk discusses handling local state in software development, particularly when dealing with asynchronous behavior and API requests. It explores the challenges of managing global state and the need for actions when handling server data. The Talk also highlights the issue of fetching data not in Vuex and the challenges of keeping data up-to-date in Vuex. It mentions alternative tools like Apollo Client and React Query for handling local state. The Talk concludes with a discussion on GitLab going public and the celebration that followed.
Principles for Scaling Frontend Application Development
React Summit 2023React Summit 2023
25 min
Principles for Scaling Frontend Application Development
Top Content
Watch video: Principles for Scaling Frontend Application Development
This Talk discusses scaling front-end applications through principles such as tearing down barriers, sharing code in a monorepo, and making it easy to delete code. It also emphasizes incremental migration, embracing lack of knowledge, and eliminating systematic complexity. The Talk highlights the use of automation in code migration and the importance of removing barriers to enable smoother code migration.
Batteries Included Reimagined - The Revival of GraphQL Yoga
GraphQL Galaxy 2021GraphQL Galaxy 2021
33 min
Batteries Included Reimagined - The Revival of GraphQL Yoga
Envelope is a powerful GraphQL plugin system that simplifies server development and allows for powerful plugin integration. It provides conformity for large corporations with multiple GraphQL servers and can be used with various frameworks. Envelope acts as the Babel of GraphQL, allowing the use of non-spec features. The Guild offers GraphQL Hive, a service similar to Apollo Studio, and encourages collaboration with other frameworks and languages.
Building a Web-App: The Easy Path and the Performant Path. Why Are They Not the Same?
JSNation 2023JSNation 2023
31 min
Building a Web-App: The Easy Path and the Performant Path. Why Are They Not the Same?
Misko Havry introduces himself and discusses the impact of JavaScript on performance. The concepts of reconciliation, hydration, and resumability are explored, along with the importance of clean code and compiler optimization. The Talk includes demos of application components and showcases the power of code extraction. The QUIC framework is highlighted for its ability to optimize code loading and prioritize interactions. The service worker is used to selectively download components for improved performance. SEO and debugging in QUIC are also discussed, along with comparisons to other frameworks.
Rock Solid React and GraphQL Apps for People in a Hurry
GraphQL Galaxy 2022GraphQL Galaxy 2022
29 min
Rock Solid React and GraphQL Apps for People in a Hurry
The Talk discusses the challenges and advancements in using GraphQL and React together. It introduces RedwoodJS, a framework that simplifies frontend-backend integration and provides features like code generation, scaffolding, and authentication. The Talk demonstrates how to set up a Redwood project, generate layouts and models, and perform CRUD operations. Redwood automates many GraphQL parts and provides an easy way for developers to get started with GraphQL. It also highlights the benefits of Redwood and suggests checking out RedwoodJS.com for more information.

Workshops on related topic

Build a Headless WordPress App with Next.js and WPGraphQL
React Summit 2022React Summit 2022
173 min
Build a Headless WordPress App with Next.js and WPGraphQL
Top Content
Workshop
Kellen Mace
Kellen Mace
In this workshop, you’ll learn how to build a Next.js app that uses Apollo Client to fetch data from a headless WordPress backend and use it to render the pages of your app. You’ll learn when you should consider a headless WordPress architecture, how to turn a WordPress backend into a GraphQL server, how to compose queries using the GraphiQL IDE, how to colocate GraphQL fragments with your components, and more.
Build with SvelteKit and GraphQL
GraphQL Galaxy 2021GraphQL Galaxy 2021
140 min
Build with SvelteKit and GraphQL
Top Content
Workshop
Scott Spence
Scott Spence
Have you ever thought about building something that doesn't require a lot of boilerplate with a tiny bundle size? In this workshop, Scott Spence will go from hello world to covering routing and using endpoints in SvelteKit. You'll set up a backend GraphQL API then use GraphQL queries with SvelteKit to display the GraphQL API data. You'll build a fast secure project that uses SvelteKit's features, then deploy it as a fully static site. This course is for the Svelte curious who haven't had extensive experience with SvelteKit and want a deeper understanding of how to use it in practical applications.

Table of contents:
- Kick-off and Svelte introduction
- Initialise frontend project
- Tour of the SvelteKit skeleton project
- Configure backend project
- Query Data with GraphQL
- Fetching data to the frontend with GraphQL
- Styling
- Svelte directives
- Routing in SvelteKit
- Endpoints in SvelteKit
- Deploying to Netlify
- Navigation
- Mutations in GraphCMS
- Sending GraphQL Mutations via SvelteKit
- Q&A
Relational Database Modeling for GraphQL
GraphQL Galaxy 2020GraphQL Galaxy 2020
106 min
Relational Database Modeling for GraphQL
Top Content
Workshop
Adron Hall
Adron Hall
In this workshop we'll dig deeper into data modeling. We'll start with a discussion about various database types and how they map to GraphQL. Once that groundwork is laid out, the focus will shift to specific types of databases and how to build data models that work best for GraphQL within various scenarios.
Table of contentsPart 1 - Hour 1      a. Relational Database Data Modeling      b. Comparing Relational and NoSQL Databases      c. GraphQL with the Database in mindPart 2 - Hour 2      a. Designing Relational Data Models      b. Relationship, Building MultijoinsTables      c. GraphQL & Relational Data Modeling Query Complexities
Prerequisites      a. Data modeling tool. The trainer will be using dbdiagram      b. Postgres, albeit no need to install this locally, as I'll be using a Postgres Dicker image, from Docker Hub for all examples      c. Hasura
React at Scale with Nx
React Summit 2023React Summit 2023
145 min
React at Scale with Nx
Top Content
WorkshopFree
Isaac Mann
Isaac Mann
We're going to be using Nx and some its plugins to accelerate the development of this app.
Some of the things you'll learn:- Generating a pristine Nx workspace- Generating frontend React apps and backend APIs inside your workspace, with pre-configured proxies- Creating shared libs for re-using code- Generating new routed components with all the routes pre-configured by Nx and ready to go- How to organize code in a monorepo- Easily move libs around your folder structure- Creating Storybook stories and e2e Cypress tests for your components
Table of contents: - Lab 1 - Generate an empty workspace- Lab 2 - Generate a React app- Lab 3 - Executors- Lab 3.1 - Migrations- Lab 4 - Generate a component lib- Lab 5 - Generate a utility lib- Lab 6 - Generate a route lib- Lab 7 - Add an Express API- Lab 8 - Displaying a full game in the routed game-detail component- Lab 9 - Generate a type lib that the API and frontend can share- Lab 10 - Generate Storybook stories for the shared ui component- Lab 11 - E2E test the shared component
Build and Deploy a Backend With Fastify & Platformatic
JSNation 2023JSNation 2023
104 min
Build and Deploy a Backend With Fastify & Platformatic
Top Content
WorkshopFree
Matteo Collina
Matteo Collina
Platformatic allows you to rapidly develop GraphQL and REST APIs with minimal effort. The best part is that it also allows you to unleash the full potential of Node.js and Fastify whenever you need to. You can fully customise a Platformatic application by writing your own additional features and plugins. In the workshop, we’ll cover both our Open Source modules and our Cloud offering:- Platformatic OSS (open-source software) — Tools and libraries for rapidly building robust applications with Node.js (https://oss.platformatic.dev/).- Platformatic Cloud (currently in beta) — Our hosting platform that includes features such as preview apps, built-in metrics and integration with your Git flow (https://platformatic.dev/). 
In this workshop you'll learn how to develop APIs with Fastify and deploy them to the Platformatic Cloud.
Building GraphQL APIs on top of Ethereum with The Graph
GraphQL Galaxy 2021GraphQL Galaxy 2021
48 min
Building GraphQL APIs on top of Ethereum with The Graph
Workshop
Nader Dabit
Nader Dabit
The Graph is an indexing protocol for querying networks like Ethereum, IPFS, and other blockchains. Anyone can build and publish open APIs, called subgraphs, making data easily accessible.

In this workshop you’ll learn how to build a subgraph that indexes NFT blockchain data from the Foundation smart contract. We’ll deploy the API, and learn how to perform queries to retrieve data using various types of data access patterns, implementing filters and sorting.

By the end of the workshop, you should understand how to build and deploy performant APIs to The Graph to index data from any smart contract deployed to Ethereum.