As GraphQL enters its 6th year, we've come a long way as a community and an ecosystem. But there's still a lot of work to be done for GraphQL to go totally mainstream and retain its momentum. In this talk, I'll highlight the top cross-cutting technical and tooling challenges that practitioners face in getting GraphQL adopted and hope to spark new ideas and discussions around what we need to spec out, what we need to build and what need to improve!
I'm excited to share a list of opportunities and ideas that encompass a) the boring things that need to be done (eg: health-check
&
error handling!), b) the hard problems that need to be solved (eg: rate-limiting
&
security) and c) the exciting challenges (eg: GraphQL
&
wasm) facing us as a GraphQL community.
I hope that at the end of the talk we have a real sense of what the top challenges are and why, and that we're excited about going into 2021 discussing these challenges and building potential solutions.
Transcript
About Tanmai
[00:18]: Hey everybody. Super glad to be here. I'm Tanmai and I'm going to be talking to you a little bit about my GraphQL 2021 wishlist. Right. And these are somebody or some challenges and of course through those challenges opportunities that we have as community in front of us to paint, you know, a bit more tooling to a few more specifications that kind of exchange more ideas with each other. To tick things off a little bit with a brief introduction.
I'm Tanmai, the CEO and Co-founder of Hasura, and a lot of what I'm going to explain is kind of, you know, stuff that we've learned from our community from our user community and patterns that we've seen from our enterprise users, especially.
Where are we with GraphQL?
And so with that, let's kind of start things off, wait again, quick stock of two things, one where we are with GraphQL today, right?
[01:08]: So the good news is that, you know, we are super, GraphQL is becoming more and more popular, which is awesome. But the slightly sad news is that it's been five years with GraohQL and GraphQL isn't yet mainstream. Right? If you think about Kubernetes or CNCF, just another huge wave that happened in the ecosystem quite recently it was at a very decent level of kind of adoption and, you know, enterprise kind of interesting investment as compared to where GraphQL is today. And that's not necessarily a bad thing, right. But it's just an interesting thing to kind of note that there are certain inflection points that we still I think need to cross for GraphQL to become mainstream and, and hopefully the kinds of challenges and opportunities that we're going to be talking about are going to help kind of understand that a little bit and, and see if we can build things to solve some of these problems and take GraphQL mainstream over the next two years as a community, right?
Why do people like GraphQL and what are the use-cases?
[02:09] So the two things are two points of context that I'd like to add before we kind of dive into some of these challenges is the reason why people like GraphQL and the use cases are not homogenous. People aren't using GraphQL and people like GraphQL for slightly different reasons. And I think it's important to kind of differentiate between these two, right?
Client-centric
So the first use case, and I'm going to call that a client centric use case, right, is primarily when we're using GraphQL to help people and help our developers build better UI applications. Right. And feel kind of, what's appealing about GraphQL at, at a very technical level is that it gives us the ability or it gives the client a contract and an ability to kind of automatically optimized data fetching logic. Right. so instead of kind of relying, and this is the end plus one REST API called problem, right. Instead of making many, the CPA calls to render or particularly white page, right. You're able to fetch that from the application dynamically in a single kind of batch query and GraphQL is a specification for it essentially doing that. And here the primarily thinking of SQL as a more optimized API to fetch data. Right. And this is kind of a new problem that's kind of come in when we've moved towards more client heavy applications, right. This wasn't a problem with kind of purely silver rendered applications things like PHP or whatnot back in the day where a lot of that data fetching that multiple amount of data required to enter UI component was done on the silver that was rendering the UI itself. And then the UI was just sent to the client that was going to use it right. But as kind of things become more dynamic we've realized that making multiple API calls because of just the network is not good and we need an automatic way.
Another similar convenience and a technical problem here is that Jason, which was the kind of data exchange format that's emerged over the last decade was unpacked. And it required certain typing and GraphQL was a nicer technical way of doing it. Right? And so this is a very technical reason. And into whole GraphQL helping us build a better UI side. And here you're essentially thinking of GraphQL as just, you know, a very abstract, not completely correct way a better way to batch and a better way to type, right. That's essentially it without going into the ergonomics and stuff.
Platform-centric
But the second aspect and the second kind of use case and why people like GraphQL is what I call a platform centric use case, right? And here people like GraphQL specification to drive a unified API experience to say that Hey instead of kind of looking at my, you know, one service and the hottest standing points, I can have one endpoint and then browse of graph of the models that this API solves. Or if I have multiple services, then maybe I can build an aggregator or kind of like a backend or frontend sometimes, or even an internal API aggregator that allows developers to kind of view all of these models together. And it becomes easier to consume and explore the API. And this is a big part of GraphQL's appeal, which is this ease of exploration and consumption, which maybe a slightly controversial statement to make, but which has nothing to do with the technical performance optimization benefit of GraphQL, right?
[05:30] These are almost two independent aspects of the use case and why, you know, why one likes GraphQL. Right. And of course, because GraphQL is kind of for Jason API, it's, it's a great API to interact with you know, when you have hydrogens data sources or services, being able to view that as one unified Jason graph is created kind of like a MongoDB experience over all of your data over an API type. And this doesn't have too much to do with kind of necessarily to do with the technical benefit of GraphQL, which is the batching and whether it's typing, which helps. Of course the typing is kind of in the middle of both the very technical benefit and an ergonomic benefit as well. But these are kind of the two lenses with which we can think about the way GraphQL is kind of being adopted, used and loved people when they're, when they're using GraphQL right.
GraphQL clients and fragments
And so when we think about the challenges in the next few minutes let's keep these two kinds of use cases in mind. Alright. So the first is GraphQL clients and fragments, which is primarily a client centric use case like and here kind of the challenge is that when we think about going beyond the convenience of GraphQL and really kind of optimizing and automating high-performance data fetching it's really hard to do that without good fragment based student, right. Fragments are critical and tooling around fragments is critical to automate the heavy lifting and the grunt work of building a UI that kind of composes all of its requirements together into a single query and fetches that data.
[07:07] And here again, a slightly maybe a little bit controversial statement, fragments are, in my opinion, not very useful for reuse, right. It's not like I'm going to create I'm not particularly excited about creating a separate file where I store all my GraphQL queries and fragments. And then I refer to those fragments and use them in my competence. That's not a particularly exciting use case for fragments, for me, I'd rather just specify the query next to my component. Right. I'd rather co-locate my data fetched requirement with an UI component, right, as a developer, instead of touching 10 different files I'd rather touch my competence, right.
And this gets what fragments can really allow us to do is to as me as a developer, working on a particular UI component, I can work on a single component and I can specify my data requirements as a fragment, and multiple people can work on different competence, specifying their requirements as a fragment, which automatically get more out of those UI components come together in kind of a UI component tree. All of those fragments will also get composed into a single credit.
The beauty of this approach is that it has to happen automatically if this is happening manually in the sense that I write the fragment here, then I have to import the fragment somewhere else. And then I have to specify that area I'm using this fragment. I have to go to the top level component and specify in my top level query that I'm using a fragment somewhere. It's not a great experience. Right. And it's kind of the, the benefit of using GraphQL to automate this data query composition stuff, right, is lost.
Now Relay has done a fabulous job at kind of taking these several concepts that are required to compose data fetching logic automatically is and the tooling that is required to deal with fragments, right, without having to do the manual work of writing fragments, maybe in a separate file or importing into using them.
[09:03] But unfortunately this idea has not come out from the Relay plans because the compiler is also a little bit complicated. But taking that Relay compiler and using that to build other GraphQL clients is something that we need to do more of. I think there's some interesting work that's happening here with, with some of the clients, I think if I'm not wrong the Angular client but there's a lot of interesting ideas here that we need to take beyond just the React ecosystem into other UI ecosystems as well. Alternatively, you know, there's, there's a lot of love that we need to give to the Relay docs and to get that up to speed. So that client is kind of more usable and more accessible, right?
Interestingly, there are other approaches to that are emerging to solve a similar problem around data fetching and optimizing data fetching automatically. SWR, which is a statewide revalidator, or the name of a concept, but also the name of a small library or tool that the versatile folks built in Vulcain, which is another approach using HTTP 2 are very unique, distinct approaches that allow kind of the similar idea of letting UI developers build that UI competent specifying that API call, that fetches data, but then kind of having some of that data fetching logic get automated without developers having to do too much work to kind of compose that together to up stuff and to make it as efficient as possible.
[10:25] And so there's an interesting non-GraphQL approaches can have some overlap with GraphQL as well. And the interesting thing about these approaches is that because they're not relying on GraphQL, they don't have to add any of that GraphQL complexity. And so this is one area of work that I'm particularly excited about and hoping that, you know, there's more stuff that happens over the next few months. I did a talk recently at React Summit like a few months ago talking about kind of this idea of Relay fragments, which we, we just kind of my journey and understanding a fragmented Relay based approach and it completely blew my mind. And so that is that if you're interested in this topic, that is, that is worth a watch. Sean and Gabriel together put together a great blog post series an introduction Relay which is also worth reading through and understanding, and these ideas that make Relay especially some of the fragments amazing. And then of course the other libraries about Canaan SOP are also worth checking out next.
Native GraphQL clients beyond UI frameworks
The next problem I'd like to talk about is having native GraphQL clients beyond UI frameworks, right? And this is again, a slightly more platform centric approach that I'm talking about, where you, have this API and you're not necessarily going to use it in the UI you might use it in a UI, you might use it in a desktop app. You might use it in a service, right. I think that's one of the things that was great about jest, which was that there was no actual, like when people build a standpoint, right? There's not, it's not a very specific standard that everybody's following. And there is a very specific standard where people are very, fairly loose with it, right. And it's very flexible and people do a lot of things and that made it easy to kind of start integrating RESTs. There's a lot of optionality in being able to integrate the REST API with whatever you were building, whether it was a UI or a service or whatever, right. And GraphQL today is extremely optimized for the UI, but making a GraphQL API usable in non-UI frameworks also has a tremendous advantage because Adidas the people building these services, right. Some as a developer building a service. If I have to build a GraphQL service and REST service, not fun. Right. And that's kind of one of those big, risky things, which is that if I build an entirely GraphQL, if I build a full GraphQL API and tomorrow, some other clients need REST API, right. Other developers or other teams or other, other applications then we maintain both APIs. And so that's a lot of work, right? Because it does seem like in, in the GraphQL versus REST conversation is going to be more of a GraphQL and REST rather than a GraphQL versus REST.
[13:00] And so one of the critical things required for that to happen is some more work on the kind of GraphQL client tooling. Right. And I think one of the challenges here is that GraphQL APIs are not necessarily easy to kind of consume and integrate because they're too flexible. And this has this is, it's not a bad thing from, again developer point of view, but maybe from a integration and stack point of view, it's a little bit of a challenge. One place where it shows up is when you're trying to code genotypes, right. If you have a different query that fetches the same different slices of the same type. You might have a new type for every query, right. And then you have like an explosion of types on the application, which is not necessarily a problem, but could result in some problems, Rob Xu talked about you know, some advanced kind of GraphQL client magic that they had to do on the Java, Android app side of things so that they will not triggering excessive garbage collection.
[14:01] And still, when we kind of think about bringing these ideas of a better GraphQL client that kind of has lesser explosion of types of, for every single type of query that you make are more optimized, consumption experience. I think that's going to be critical in helping GraphQL adoption become more small for developers, you know, whatever they're building.
Two of the approaches that I'm excited about here are of course the great work that the GraphQL folks are doing in the community that is doing, but also approaches like jooq for, in the SQL world that provided native abstraction to SQL, as opposed to an object based abstraction to data entities. And I think GQL S Sam Denty is another very interesting idea and approach that I think Sam started that this year that makes the more native consumption tree and for GraphQL possible, of course, most of this is happening in the TypeScript and JavaScript community. It'd be interesting to see this kind of move to beyond that beyond just that JavaScript context with community.
Bridge the GraphQL to REST tooling gap
Alright, next up is this challenge of bridging the GraphQL to REST tooling gap. So the, the cool thing about REST API and the entire REST ecosystem is the immense amount of tooling, infrastructure tooling, vendor tooling that has been invested into helping people operate and build with REST API and production specifically health check and quality of service monitoring, right? So you can stick in a vendor tool without touching your stack. You can just integrate, drop in a vendor tool that will start giving you kind of, you know, a status page or a help page that tells you you know, what the quality of your APIs is right. You can set up alerting and monitoring fairly easily, again, without going too much work. By using this kind of, you know, using a vendor tool using an infrastructure tool without affecting your work or your application logic or your applications too much.
[16:08] And here is the problem with GraphQL and one of those things that, you know, we still don't, I think have a good solution for is that GraphQL returns errors inside the response body, not inside status codes, right. And in fact, it can be partial errors, right? And there's no notion of partial errors in a status code. So what this means is that the tool that we're using to do our quality of service monitoring or edit reporting or editing has to actually peak inside the response body to understand whether there's an error or not. And this is a challenge because the response body is very, kind of critical private data. You don't want to take that data and send that to a third party tool for analysis, right. Because that's essentially like very sensitive private API data.
[16:52] Of course server-side caching is a problem that, you know, we've been talking about from the dawn of GraphQL times in being able to leverage the various kind of network points that are between a silver and a client, right. Everything from a CBN to do the load balancers, to servers in the middle that will make sure that we're able to send do some element of server-side caching, right. And indicate to these various network points in the middle of what caching policy we want.
One interesting idea potentially could be to have some kind of automated human-readable mapping from GraphQL to REST, right. It has to be automated so that as developers building or using the GraphQL API we are almost kind of not worried about it. There has to be enough. It's kind of almost similar to assisted queries idea but taking a little bit further. And you know maybe it looks something like this, right? Where you say you have a query, you parametrize variables, and then you can put that into an idiomatic REST point. So that in, in production, you're actually just using these idiomatic REST endpoints and everything about it really works, but during development, you get to use all of the greatness of GraphQL.
GraphQL as an intermediate representation
Kind of similar to this idea is also this idea of using GraphQL as an intermediate representation and not final API. And this is really that kind of platform-centric appeal, which is saying that people really like browsing GraphQL APIs and graphs. Right. So if it comes to actually using those GraphQL aPIs in their applications, because of all of the challenges wwe talked about or, you know, if it's a service, they're not consuming it inside an application on a UI shrug emoji, right. Which is that basically people are not terribly excited about changing the way they think about their API clients in whatever they're building to use GraphQL.
Could there be ways for us to get the benefit of GraphQL from the exploration, tooling, documentation browsing getting that right slice of data, all of those benefits without having to change the way our API clients work. And kind of related to that previous idea is that if we could use GraphQL as an intermediate step in our API cycle. So we can say, you know, I want an API as a developer, I want to consume a particular API. So I go into graphical, I try out like, whatever GraphQL query I want. And then I submit my GraphQL query. And I say, this is the API point that I want.
[19:25] And then it goes through to view either automated or human or whatever, right. Maybe a performance check or whatever check that you want to do. And then in development or during development, I get a REST or a GRPC of whatever endpoint that we are actually, that we have all of the tooling set up for. Right. And here we can kind of get the metadata catalog, the data dictionary benefits and the API extradition benefit of GraphQL but without having to force our users to actually use GraphQL and production so that they have to be even that tooling. Right. It's kind of similar to the previous idea.
Semantic composition of independent GraphQL services
The next problem that I'd love to talk about here is that when we think about various different GraphQL services that we want to stitch together there are some interesting challenges, you know, it's for example, if you have multiple relay schemas and you want to kind of you have this GraphQL gateway or some kind of aggregator that is kind of delegating to the schemas, but the schemas are not just GraphQL schemas they are relay schemas, which means that all of them, for example, are going to have a node field, right. And they wind up in a node field.
[20:34] Now, when you try to aggregate them, you can't just clobber these schemas together and put them into a type, right. You can't prefixed them or namespace them because that doesn't make sense. Right. The note field has certain semantics associated to it. They ID a field that every type would have also has some certain semantics associated with it and namespacing it, or prefixing it, or just clobbering that together into one API is not helpful. And so here, what we really want to do is have these services kind of exchange more information. Let's say for example, in our organization, we've created certain kind of these common standards that these interfaces similar to the node interface that we want to use, how do we exchange this information with each other. And augment the kind of introspection result, maybe it's extra things on the SDL and stuff, extra directors on the SDL or separate API or whatever.
But this is kind of essentially the work that we have to do which is that you're basically delegating to these other services and you have and you're kind of using you, you have to reimplement the node field as a GraphQL resolver act that kind of GraphQL aggregation layer, right. And then that delegates to the node field in these upstream services. Right. And then you have to make sure that you can manipulate that data, the ID response, right. Each identify has to be changed at the aggregator level so that the identifier has the indication of which service it's coming from, so that then you can delegate it appropriately.
Role-based schemas
[22:10] I think the last two quick ideas that I'll cover, and these are two short ideas: the idea of a role-based schema which I think is particularly appealing, especially inside very large kind of enterprises. One of the problems here is that it's really kind of nice sounding to say, what if all of our API is our one gigantic centralized, universal GraphQL API? It sounds nice, but it might not actually be nice if you have 20,000 API endpoints resources, right. Because then it's just too much.
And what you really want to do is whenever I enter graphical, I don't want to see so many APIs, right? Let's say it's an e-commerce situation. I have a separate merchant API, consumer API, and an Ops API, obviously somebody internal to the org. In these cases, I don't want the merchant folks to even see the consumer API. I don't even want them to try querying for stuff, try bothering and putting a token and getting another result. I don't even want them to see that part of the schema. Right.
And so here is this idea of kind of linking that authorization or the identity of the consumer to the schema that you're getting right. Where it's kind of dynamic. It's not, it's not like a bill time schema that you've had at build time, but it's a dynamic schema that reflects the user that is actually using it. And makes it kind of platform style of consuming GraphQL. Very convenient.
GraphQL
&
WebSockets
&
HTTP/2
&
HTTP/3
The last thing that I want to touch upon, which is really kind of a set of things to be aware of is as WebSockets and HTTP/2 and HTTP/3 mature. There is some interesting work for us to do as a community, keep, keep kind of pushing GraphQL and making sure that the GraphQL specification or specifications for particular ways of using GraphQL right, not, maybe not the core specification is evolving continuously as well.
[23:49] And especially with add effort and that stream being added as experimental features to the, the GraphQL spec integrating that with WebSockets you know, today, for example, it works with multi-part former HTTP/1, but it agreement with WebSockets and HTTP/2, HTTP/3 is also going to be quite interesting and here that there will be some challenges in the way that we handle stateful workloads. Because essentially when we kind of doing more of these stream or push style things over anyone protocols that could be more efficient. These workloads, right, are stateful in the sense that you know, somebody subscribing to something, they can't be switch over to a different server that is serving the subscriptions. And, and so there is a little bit of work that needs to happen in the backend itself on how we are able to handle these things, particularly from a load balancing, scaling, and security point of view.
And so those are some interesting things that are happening. It should be clear, still, very experimental and very new but there's some interesting stuff that's happening there that is useful, and it should be really good for us to keep evolving GraphQL in that direction as well.
All right. So my apologies for being a little bit overtime and with that I shall actually close this out. Please feel free to reach out to me, talk a little more about this and I’ll be excited to kind of keep engaged with your folks, talking about these challenges, learning about other challenges that you're facing. I'm @tanmaigo on Twitter, please do feel free to reach out. And of course I'll make the slides and resources available so that you can check them out as well. Thanks for having me.
Questions
[25:42] Vishwa Mehta: Yes. That was an amazing talk, the way. So what do you think about the results from the poll? Was it expected?
[25:54] Tanmai Gopal: So that was my gut feel. My gut feel was that more people are going to vote for GraphQL for the API integration and onboarding and the community tooling experience and lesser for the, you know, the theoretical benefit of GraphQLthe kind of plus one performance difference and the dive safety which, which is a large part of the original kind of design of GraphQL. So it's very interesting to see that difference. And I think, and I think that's kind of that shift off of GraphQL being more important for API integration and onboarding is, was kind of, one of those was kind of one of the core ideas behind you know the set of problems that I highlighted over the talk because I think if you think of GraphQL for those aspects of the API onboarding and integration, there's still a tremendous amount of work that we still need to do to make GraphQL easy and more mainstream.
[26:54] Vishwa Mehta: Definitely. And I think that was a great question to sort of start the talk with. So that was really interesting to find out about.
[27:03] Tanmai Gopal: I was also very genuinely curious. I was like, wait, what is going to happen? Are more people going to be like, well, performance is important. There are more people going to be like you know, I love GraphQL. So it's interesting.
[27:15] Vishwa Mehta: Yeah, absolutely. We also have a question from Discord and a little birdie dropped it for me to ask you. So question from Bostian: when half the world is on GraphQL, what are the challenges that you predict, when will we be joining various graphs together?
[27:36] Tanmai Gopal: That's a good question. So I don't think there's ever going to be unfortunately, a world where everything is GraphQL, so there's going to be a percentage of things that move to GraphQL. I don't think that's going to happen but it'll be interesting to kind of see those use cases emerge. Right. I think there are two broad cases that I see for people wanting to join kind of giant quote-unquote grafts, right. One is this kind of the first level of problem that a lot of us are dealing with which is that which is that we have kind of many different API endpoints and we have frontends to build, and it's just a gigantic pain in the neck to be able to look at all of those different endpoints and combine them on the frontend or some backend frontend thing and come up with an API aspect for it and stuff like that. So that's kind of this one use case of maybe not even necessarily joining graphs, but maybe creating a common, a GraphQL model or a gateway or an aggregation layer or something, which is essentially a better API Batchelor API gateway, right? It's like a version two of that. It's a program I believe I gave you maybe of sorts. And that's kind of one use case that's emerging. Right. And the interesting thing there is there's lots of alternative approaches to that problem is where a lot of people are like, you know, what, let the microservice and API endpoint explosion happen. We'll figure out a different way to fix that problem. And Vulcain that I kind of talked about is a great way, a great approach that, but the other kind of approach for joining graphs and joining beta, I think is, is not necessarily just in the front end community, that, you know, that most of us are part of but also kind of just the API and the data community, right. Which is the people who are kind of, you know, maybe, maybe inside a large enterprise, you have several lines of business, right? You have or even in a startup, right. You have people doing all kinds of things, right. Not everybody is necessarily building the app. That's perhaps one big part of the business, but there's lots of other things happening as well. And for a lot of them, they kind of need disability to say, well, here's my code data. And then here's some additional data. Here's some data in my SaaS service here, some data here, and I want to have like a common Jason model across them. Right. And I think being able to deliver on that use case that's when we went to see a lot of interesting kind of, we're going to see another round of pool for GraphQL or for GraphQL like thing to say, let's join those graphs together. Right. So I think it will depend on the use case. I definitely do think that, like, we will have to, we have to kind of bridge that gap between GraphQL and existing API services and API tooling and API vendors to make that happen successfully though. So let's see, let's see how it works out.
[30:40] Vishwa Mehta: Yeah. Definitely. There is a lot of hype around unified GraphQL data access layer. So I think that something that everyone is looking forward to, and it's really exciting.
[30:50] Tanmai Gopal: Yeah. I mean, just to add a note of caution there, which is more I talked about at the panel discussion yesterday. The idea of a unified graphs sounds very appealing, but you have to make sure that you're unifying it for the right reason. Like, for example, in a large enterprise, you don't want to have a unified graph of your entire API ecosystem. Right. Because you'd go mad. Like you look at the 1 million APIs and you're like, I don't want this. I just want those three API endpoints. Right. I just need to do these three things. I don't want to see all these million interconnected things because these are the only three things I'm interested in. I think that the use case for unifying data. Right. Let's if you have structured level more is I think going to be very interesting to look at.
[31:37] Vishwa Mehta: Absolutely. Yeah. That makes a lot of sense. Also Tanmai you mentioned that you've learned a lot from GraphQL. I mean, a lot about GraphQL adoption from the Hasura user community and your enterprise customers. So in your opinion, what's the easiest and hardest part about, well, convincing is not the best point, but demonstrating the magic of GraphQL that gives the users more confidence in adopting it.
[32:03] Tanmai Gopal: So I think the initial adoption is really easy, right? Like you, you can talk about GraphQL, you can say this, you can say that then ultimately when you look at graphical and you look at being able to kind of that experience of putting things together, right, and what people voted for the 78% of the API or voting integration experience you know, that kind of wins hearts and minds very quickly, right? The challenging bits around GraphQL are basically the day two of GraphQL. Right. Which is that, oh my goodness. The rest of my stack doesn't work with GraphQL. Right. Nothing works. Security does work, monitoring doesn't work, right? Like all of these existing tooling, we have to rebuild it. We need a massive team to rebuild it. Right. And suddenly you're realizing that you're getting to start starting to solve a bunch of problems that are not even important to your business. And I think, and I think that's kind of this, that's kind of the part where a lot of like, especially enterprise users get very wedded and it's very risky because it is legitimately very risky. Right. I don't want to staff up this entire gigantic GraphQL export team and worry about GraphQL adoption. And what if in five years GraphQL changes or GraphQL is not around, or the new GraphQL comes around. Right. So it's very hard. And that's, I think one of those kinds of risky aspects, but I think the day zero problems we are doing very well on as a community. Right. And there's lots of great tools that are kind of emerging to help with the initial problems. And then I think the second day problems, right. That's kind of where some of the objections and very legitimate objections, right. It's not like people are stupid or something. It's just the very legitimate objections that people have. So that's what I'm hoping we get to fix a little bit in 2021 as a community.
[34:04] Vishwa Mehta: Absolutely. That was a wonderful answer. Thank you so much Tanmai for this really interesting and informative Q
&
A session. And you, again, you were really great with your talks, so thank you so much for giving us your time.
[34:17] Tanmai Gopal: Thanks Vishwa. And thanks for having me. Everybody, I'll hop onto the special chat. So see folks there and see folks at Discord. All right.
GraphQL Galaxy 2022
