Panel Discussion: GraphQL Client-Side Libraries

I will do a quick round of introductions for all of you before we jump right into the discussion and start taking questions. Today we have here to join us is Joe. Joe is a software engineer at MetaFacebook, working on the React Relay and GraphQL. We also have Phil. He's a engineer at GraphCDN, formerly at Formidable, working on the core team of Urql. Great tool. Urql is a GraphQL client that was started there and of styled components as well. Dominik is a front end engineer from Vienna, Austria. He works as a front end tech lead at AdWordy and maintains the library React Query. And last but not the least, Ellen. We have Ellen here with us who is a mobile developer advocate at Apollo GraphQL focusing on iOS and Android SDKs. She lives in Madison, Wisconsin and enjoys all things outdoors as well as carving weird nonsense with lasers. Wow, that is super cool, I'd say. Super fascinating. Awesome. That's definitely also a pandemic hobby. Absolutely. I was about to say that. And like just talking about like weird things that helps us destress. I also have like a bunch of things like that, just you know, huge part of my expression and how I am able to express myself as a creative person. So, definitely super interesting.

I will do a quick round of introductions for all of you before we jump right into the discussion and start taking questions. So, today we have here to join us is Joe. Joe is a software engineer at MetaFacebook, working in the React org on React, Relay. We also have Phil. Phil is an engineer at Graph CDN, formerly at Formidable working on the core team of Urql. You might have heard about it. Great tool. Urql is a GraphQL client that was started there. And components as well. We also have Dominique with us. Dominique is a frontend engineer from Vienna, Austria. He works as a frontend tech lead at Edwardity and maintains the library React Query. And last but not least, Ellen. We have Ellen here with us, who is a mobile developer advocate at Apollo GraphQL, focusing on iOS and Android SDKs. She lives in Madison, Wisconsin and enjoys all things outdoors as well as carving weird nonsense with lasers. Wow, that is super cool. I'd say super fascinating. Awesome. Definitely also a pandemic hobby. Absolutely. I was about to say that. And like just talking about like weird things that helps us de-stress. I also have like a bunch of things like that. Just, you know, huge part of my expression and how I am able to express myself as a creative person. So definitely super interesting.

All right. So I think it's good to start off with like a simple question, like a basic question around what problems or use cases you folks think that GraphQL or GraphQL clients have been most effective at addressing? And how they've improved the state of the art for application development. And we'd love to hear your thoughts. And this could just be that one question where it could like set the primer for the entire discussion. And we can just take it from there.

All right. So, I think it is good to start off with like a simple question, like a basic question around what problems or use cases you folks think that GraphQL or GraphQL clients have been most effective at addressing? And how they have like improved the state of the art for application development, and we'd love to hear your thoughts. And this could just be that one question where it could like set the primer for the entire discussion and we can just take it from there. How about we start from you, Joe? Yeah, sure. That's a great question. Yeah, I guess most of all, GraphQL clients have kind of, I think, started to help... have really helped applications scale. That's probably the number one thing. We're all familiar with the kind of REST approach, right? Of having these kind of custom endpoints, versioned endpoints. And they just don't really match up with rich applications that have a lot of reusable components, whether it be web applications or mobile applications, you have these reusable UI components. This has become kind of standard in the industry, thanks to React in large part. But now that that kind of component-based development has become standard, we've really began to see the way that REST just didn't scale. And so GraphQL most fundamentally, I think, has helped to address that. I think it's also helped to kind of formalize the way we think about data management in client-side applications. So a lot of concerns that people kind of maybe had to deal with, but didn't have a name for, GraphQL clients have helped us to understand what those concerns even are. So data consistency being a very fundamental thing, but we didn't really think about it as much until GraphQL came along. And so GraphQL clients have kind of helped with those types of things, like data races, even. People thought about them before, but we think about them, I think, more formally now.

How about we start from you, Joe? Yeah, sure. That's a great question. Yeah, I guess most of all GraphQL clients have kind of, I think, started to help. It really helped application scale. That's probably the number one thing. You know, we're all familiar with the kind of REST approach, right? Of having these kind of custom endpoints, versioned endpoints, and they just don't really match up with rich applications that have a lot of reusable components, whether it be web applications or mobile applications. You know, you have these reusable UI components. This has become kind of standard in the industry, thanks to React in large part. But now that that kind of component-based development has become standard, we've really began to see the way that REST just didn't scale.

And so GraphQL, most fundamentally, I think, has helped to address that. I think it's also helped to kind of formalize the way we think about data management in client-side applications. So a lot of concerns that people maybe had to deal with but didn't have a name for, GraphQL clients have helped us to understand what those concerns even are. So data consistency being a very fundamental thing, but we didn't really think about it as much until GraphQL came along. And so GraphQL clients have kind of helped with those types of things like a race, like data races, even. People thought about them before, but we think about them I think more formally now. That's really interesting, definitely a lot of things that I really agree with you, definitely a lot of things that we didn't notice, we wanted to optimize for or be better at with our app development until GraphQL came along.

And then like all of these GraphQL clients as they've evolved, they have been addressing these kind of pain points for a lot of our developers. So it's kind of that combination of GraphQL evolving, but also like all of these great, great front-end clients, like GraphQL clients that have been really helping out with it. What do you think Dominic? Yeah, I think GraphQL itself had a huge impact on how we think about managing data in general that we are fetching from the server. So GraphQL I think gave a lot of power to the front and back and a lot of control when you can, what you couldn't do with REST to just specify the fields that you want to query and just get it at the right level of granularity. Of granularity that you wanted for your specific few. And that was the first when I heard about GraphQL where I thought, yeah, this is really cool. But what I really didn't realize at the beginning was that actually all those graphical clients come with a separate cache for managing that data.

Yeah, that's really interesting. Definitely a lot of things that I really agree with you. Definitely a lot of things that we didn't notice we wanted to optimize for or be better at with our app development until GraphQL came along. And then all of these GraphQL clients, as they've evolved, they have been addressing these kinds of pain points for a lot of app developers. So it's kind of that combination of GraphQL evolving, but also all of these great, great front-end clients, GraphQL clients that have been really helping out with it.

What do you think, Dominik?

Yeah, I think GraphQL itself had a huge impact on how we think about managing data in general that we are fetching from the server. So GraphQL, I think, gave a lot of power to the front-end backend, a lot of control when you can, what you couldn't do with REST to just specify the fields that you want to query and just get it at the right level of granularity that you wanted for your specific view. And that was the first one I heard about GraphQL, where I thought, yeah, this is really cool. But what I really didn't realize at the beginning was that actually all those GraphQL clients come with a separate cache for managing that data, because when I first heard about it, I really thought, okay, this is cool. I can fetch some data, but then I would still need some means to distribute this data throughout my application. I don't know what one has to do with the other. But the caches that come with it are also the actual power of the GraphQL clients and the front end libraries. And that has also been inspired, obviously, React Query to go that way, to provide a library that manages this server state, this agent run state, not only for GraphQL, but also for REST in the end.

Absolutely. I would also love to hear your thoughts, Phil, on this.

Yeah. It's hard to add a lot more information to this than Joe already has. I mean, Urql as a client has come so late to this entire game. It really has been so early. But GraphQL as a whole, mapping this unidirectional data flow that we already have in apps, in componentized apps specifically, has just benefited everyone so much. And it allowed us to play around a lot more with what clients can do automatically. And what kind of experiences we can craft in apps without going to great lengths as individuals who just want to build an app. And I think recently, especially with the spec working on a lot more changes, I'm personally very excited about the nullability RFC that allows us to control what kind of data flows into our applications as nullable or required. It's going to further push this.

Absolutely, sounds good. Ellen, do you have any other thoughts that you'd like to add to this?

Yeah, I do. I think for me, the biggest thing that working with GraphQL has really opened up for me is communication between the front end and the back end. And I don't mean actual data going back and forth. I mean people talking to each other. One of the things that I constantly ran into at a previous job that was using a REST client was something would be on one REST endpoint and we would be using a different REST endpoint for a different screen.

Because when I first heard about it, I really thought, okay, this is cool. I can fetch some data, but then I would still need some means to distribute this data throughout my application. I don't know what one has to do with the other, but the caches that come with it are also the actual power of the GraphQL clients and the front end libraries. And that has also been inspired, obviously, React query to go that way, to provide a library that manages this service state, this agent from the state, not only for GraphQL, but also for REST in the end. Thank you.

Absolutely. I would also love to hear your thoughts, Phil, on this. It's hard to add a lot more information to this than Joe already has. I mean, Oracle as a client has come so late to this current entire game. It really has been so early. For GraphQL as a whole, kind of mapping this unidirectional data flow that we already have in apps, in componentized apps specifically, has just benefited everyone so much and it allowed us to play around a lot more with what clients can do automatically and what kind of experiences we can craft in apps without going to great lengths as individuals who just want to build an app. And I think recently, especially with the spec, working on a lot more changes, I'm personally very excited about the nullability RFC that allows us to control what kind of data flows into our applications as nullable or required. It's going to further push this.

So, we would need to go and be like, hey guys, can you add this one field to this other endpoint? And it would take a month because you'd have to get prioritized. And then it would do the thing and then the site would go down and something else would happen. And just being able to say here is a contract that tells you what is going to be where, what values are available to you, and also what type they are is really critical. And it really is something where I went from whenever I had a REST API, particularly one that I didn't control, I would always write two sets of tests, one that hit mock data and one that hit the live staging server. Because I would be able to much more quickly tell whether I messed up or whether somebody changed something on the server. And with GraphQL, as long as people are actually sticking to the schema, that becomes unnecessary. If you're properly evolving the schema, if you're actually making sure that you're not removing stuff without properly deprecating at first, if you're actually making sure that you're evolving things, the need for that becomes completely gone. And it's huge for mobile, just because, like, one of the biggest things that we run into with REST endpoints is just, like, people change something and an older version of the app just breaks completely. And the way that GraphQL is at least supposed to work is that things are continued to be supported as long as they're actually being used. And that prevents a level of breakage that is so common in other applications that I think is just absolutely critical to mobile.

No, I totally agree. And I love how you mentioned or, like, highlighted the way that GraphQL brings out the benefits of the people side of things, like teams communicating. Because it's such an underrated thing, like, GraphQL is empowering actual developers, not just in terms of the features that we're able to ship now or the tactical benefits of it, but also the people side of it and how much it has been empowering us to better communicate with our team members. So definitely agree with that, and I just absolutely love that point. Then also, some of the points that you folks have mentioned, that also brings me to this follow-up question about, in our app development, as Joe said, that there were so many things that we didn't really notice was going wrong until GraphQL came along. Do you think because of that aspect, do you think having clients that have GraphQL support baked in would be, just a crafted experience for GraphQL on the client side, would be really helpful? Or is it on the alternate side, is it better to have clients that are not GraphQL specific, I'd say, but serve as a utility for it. What are your thoughts about that? We can just go with you, Ellen.

Yeah, I mean I think, I'm coming from the place of supporting two SDKs that are in very strongly typed languages. And I think what we've definitely found is that at least in Swift and Kotlin, I know that there are other mobile experiences that sometimes have a different approach but I know that in Swift and Kotlin, one of the big things that we've found is being able to compile everything down to a type safe query has been huge for a lot of people in terms of both being able to partner certain things with individually designed views and stuff like that, but also just in terms of being able to process data that they're getting from the GraphQL, and even if it needs to be at some point transformed into a view model or something like that, it's still much, much easier to at least have an idea of where you're starting for a lot of this stuff. And I think it's not something where I know that on web, there's a lot of stuff where it's like the relay stuff is very, very tightly tied to relay UI principles, and that isn't as much of the case on mobile. I know that somebody was saying, I think it was Joe was saying that there's some stuff that is a little bit differently handled at meta, but I think in the wider iOS and Android world, I think it is something where people are trying really hard to get this integrated with Swift UI and Jetpack Compose, which are more Reactive frameworks that are inspired by React, but it's something where there's not quite as much of a tight binding as there is between GraphQL and React and particularly GraphQL and relay.

It depends, I guess. There's a degree of how much we depend on GraphQL, depending on which GraphQL client here we are talking about. I think it's particularly interesting, and I'm actually looking forward to what Dobrydek has to say about this, about differentiating between GraphQL as a UI pattern and as a guiding principle of how we build our apps and a client as a fetching library. I think there's an interesting balance that can go either way, depending on the use case and depending on the users. And Oqware decided to actually not add any shims, so to speak, to execute GraphQL on the client side and instead only rely on APIs. And specifically, I think a couple of years ago, that was more of a controversial decision, as people weren't quite ready yet to ship GraphQL APIs to production and accept requests then build them. But I think there have been so many more cases and so many more advantages of GraphQL that have come around more recently and have surfaced over time that kind of show that when you're building with GraphQL, when you're building a GraphQL schema, it's pretty important to design that schema. And I think the same benefits apply to why it's a bit different speaking about a GraphQL client and speaking about fetching in general, because it depends on how you're building your app and whether you go all in, so to speak or not.

Absolutely, sounds good. Ellen, do you have any other thoughts that you'd like to add to this? Yeah, I do. I think for me, the biggest thing that working with GraphQL has really opened up for me is communication between the front end and the back end. And I don't mean actual data going back and forth, I mean people talking to each other. One of the things that I constantly ran into at a previous job that was using a REST client was something would be on one REST endpoint, and we would be using a different REST endpoint for a different screen. Just being able to say, here is a contract that tells you what values are available to you, and also what type they are is really, really, really critical.

With GraphQL, as long as people are actually sticking to the schema, the need for writing two sets of tests, one hitting mock data and one hitting the live staging server, becomes unnecessary. The way GraphQL works ensures things continue to be supported as long as they're being used, preventing common breakages in older versions of apps. This level of stability is crucial for mobile applications, where changes can lead to disruptions and failures.

Phil highlights the importance of balancing the reliance on GraphQL based on the specific GraphQL client being used. The differentiation between GraphQL as a UI pattern and its role as a guiding principle in app development and a client as a fetching library is an intriguing aspect to explore. The dynamic nature of GraphQL usage depends on the use case and the users involved, presenting an interesting perspective on the versatility of GraphQL in different contexts.

And I think the same benefits apply to why it's a bit different speaking about a GraphQL client and speaking about fetching in general, because it depends on how you're building your app and whether you go all in, so to speak or not. Yeah, yeah. That totally makes a lot of sense. And I agree. I would also like, I'd love to hear what Dominik has to say about this. I would love to hear from you Dominik.

So I wouldn't even say that React Query is a fetching library. I wouldn't even go one step further and say React Query is just an Async state manager, and this is always confusing to some people when I say React Query is not tied to data fetching at all. It doesn't really care how you produce the result. It actually only needs either a resolve or a rejected promise, and how you build that is entirely up to you. And I think this is a completely different approach than other libraries have. So it's not tied to GraphQL at all, it's not tied to REST at all, this gives you a bit of flexibility when you have to work with multiple back ends where you sometimes have GraphQL, you sometimes have REST, different endpoints that you have to hit. I've even seen some users read data from the Ethereum API or something, web3 related, to get data via ReactQuery, so just to manage the state that you have that is asynchronous. But of course ReactQuery is used most prominently with data fetching, and yes it's not tied to GraphQL, so that is a trade-off that you are doing, I think it's all trade-offs. The cache that ReactQuery has is a very minimalistic document cache, and you don't have all the capabilities that you might have with a very specific GraphQL cache, but you also have other benefits, like being able to use multiple sources or having a very predictable and reliable cache container that will also give you the power that you need to do the refetching that you want in the times that you want it. Absolutely, and I think just to like, reiterate on what some of you have said about tying your clients to GraphQL or not, I think it totally depends on whether or not you're completely invested in building out your app using GraphQL entirely or a lot of companies, a lot of products are they have like C code and they don't entirely like migrate to GraphQL right away. They kind of have to go through like building progressive layers on top of their existing REST APIs and I think, and kind of makes sense to have some sort of a utility-driven framework like a client that could be well suited if you want to work with GraphQL, could be well suited if you want to work with REST APIs, but then also is not entirely tied to the patterns and driven by GraphQL itself. So that totally makes a lot of sense. Joe, do you have any other thoughts on this?

Yeah. Yeah, so I think there's kind of, we've kind of touched on two pieces. One is the extent to which your client is coupled to GraphQL and then that Ellen kind of talked a bit about was how much you're kind of coupled to the given UI library, right? And so for the first kind of coupling to GraphQL, yeah, there's real trade-offs there. As you've all talked about, not everyone has their data their backend data and GraphQL. Even at Meta, there's still some apps that have their data that's kind of not exposed via GraphQL for various reasons. But I think there's kind of real trade-offs with that. So the GraphQL, the fact that it gives you a typed schema, the schema can express a lot of information that clients can take advantage of. And so the reason that we have these powerful clients is the GraphQL schema. There's just simply capabilities that we can do with a GraphQL client that are just not easily done with arbitrary rest endpoints. Even if they're fully typed, even if you've got a full TypeScript or whatever definition for your types that is providing a lot of rich type information, there's actually more information that a GraphQL schema can provide. For example, indicating via directives, what is the primary key, is this entity cashable, those types of information. And then also just knowledge about enums and things like that, interfaces, the ability to introspect dynamically to actually get the type, being able to rely on that, like what is the actual concrete type of value at runtime? You can't do that in general with a rest endpoint.

And all those things are really fundamental to building a very powerful client, to get data consistency. What we tend to see is basically clients that are, like as you said Dominik, with React Query where it's really document caching focused. But even then, you don't know enough about what's in that document to do things like invalidating automatically based on changes, because you don't know, you can't do the Urkel approach of just using type names, right? Which is one approach that is probably going to over-invalidate quite a bit. But at least it gives you automatic invalidation. And so there's just a real trade-off. And so, I think, I guess my kind of hope for the ecosystem is that we work to make it easier to build GraphQL servers so that people can then just take advantage of the GraphQL client capabilities, as opposed to saying like, well, let's just kind of go to the lowest common denominator and build clients that can only do what we could do with rest, because we just want to make it easy to adopt. And so I think the clients kind of make different trade-offs along there. There's, I guess, a whole nother question of integrating the view layer, but that's almost a separate question.

Absolutely, no, that makes a lot of sense. And it's good to learn about what kind of trade-offs would there be if, like, depending on your approach, that kind of also calls for a question that I really wanted to hear all of your thoughts upon. But Ellen partly answered that already, but would still like to go into more of it and hear from all of you about, you know, like one of GraphQL's innovations is introducing the strongly typed schema that exposes rich information about server capabilities. But then I think that most clients do not, or like do not choose to, or cannot use much of this schema information by default. So, how much do you think for your scenario or for the space that you're working in, how much do you think this still holds true, and what are your thoughts on it? Ellen, I'd love to start with you about this question actually. Yeah, I think that's basically not true on mobile. I think particularly because, again, like I said, one of the things that you can do when you have both the schema which sort of outlines what is possible and then the query that you're going to be making, which says, okay, what am I actually asking for? You can do a lot of validation on that, and then you can also generate type-safe code that is really helpful. And I know that there's some stuff, like I know GraphQL CodeGen is huge in this space, in TypeScript in particular. But another method that I've seen on iOS, which is sort of basically not how we're doing it at Apollo but is something else that I've seen, is essentially being able to use the schema to create type-safe queries when you're creating those queries at runtime. So there's a lot of stuff that you can do that can really take advantage of that. And honestly, I think that's a huge piece of the value proposition for mobile, just because there's just so much stuff we have to do to take stuff from JSON and turn it into something that is usable in a type-safe language and having that level of validation even at compile time, it's super, super helpful. So that definitely sounds helpful and really convenient. But I actually started off with you just to see that kind of contrast between the case in mobile development and then how it is for the web. So Joe, do you have any comments on this from your side? Yeah. It's been really interesting to see how this is going to play out in the ecosystem. I mean, definitely for mobile where we're working with very strongly typed languages, I think everyone's kind of... basically your hand is forced. You're going to use this schema information. Although how we use it there is still interesting. But on the web, I think the ecosystem on the web tends to focus ease of getting started and simplicity. You see a lot of... There's this kind of cyclic nature where you have a library come along, it solves more and more problems. Inevitably, that means it has more features. It's kind of, you look at it and you're like, oh, that gives me a lot. I don't need all that. Apps start off. Other libraries come along and say, oh, we're easier to use. Then they get more adoption. They add more features. Now, they've just fallen into the same pattern.

You just see this endlessly happening in the JavaScript ecosystem. Circle of life. Yeah. Honestly, as a library developer, it's pretty frustrating to watch. Y'all are just going to run into this problem next and then this problem next and this problem next.

What that means, though, is that, well, obviously, one of the easiest ways to get started is to just not use the schema. What that means is that you're offering a much worse experience to the developer by taking advantage of the schema, you can actually implement the GraphQL spec correctly. You can't implement the GraphQL spec correctly if you don't know the schema, if you don't know the types of objects, if you don't know which types implement which interfaces.

We see this where there are multiple clients on the web where if you don't go through extra work, you will actually not get correct behavior. You'll be wondering, wait, why is this basically every client other than Relay. By default you will get incorrect behavior on certain parts of the spec because they don't use the full schema information by default. I think it's just a really interesting way that the ecosystem has gone. There's definitely tradeoffs. It makes it easier to get started. This is not to criticize. We're making different tradeoffs, but it's very interesting how the schema provides such rich information and yet we don't all take advantage of it on the web. I think that just a real tradeoff of it's not as easy to build some of these features into JavaScript as we'd like. I think in the native platforms, we just have people are used to a build step. It's kind of sure, of course you're going to have a build step. Let's add more there to give even more value to the developer. Whereas on the web, it's like, oh, another build step. There's kind of more like, okay, well, let's maybe not have a build step and make some tradeoffs to kind of get that ease of use and fit into the JS ecosystem.

No, that definitely makes a lot of sense. Like, it's like understanding the value that GraphQL brings and then wanting to use it, but then also not being able to somehow leverage the full power then you could with your app, like building it out with GraphQL. So Phil, what do you think about this? It's definitely trade-offs, yeah, but I think to a certain extent, it's not always, as library office, our trade-off to make. At least that's the opinion we have in terms of Urql, where we provide two different default caches. When you just install it, you have a document cache, which is very primitive, and you can switch to a normalized cache. At which point we then actually recommend people to use something we call schema awareness, which is literally just using introspective schema data for more correct behavior. But the reason why I'm saying it's not our decision to make on the web is because there are so many different ways to use the web, so to speak, to create web apps and pages. That's the distinction, I think, that's worth highlighting.

Sometimes, when a developer is just creating a very content-based page, for instance, some kind of news page, let's say, the data is very static, and it's not highly interactive. They might not even be interested in some of the more dynamic features they're getting from normalized caching. And there are different trade-offs they want to make. And it's more of a case of they don't need to bother setting up normalized caching, and hence, they don't. So, forcing them to go through that setup flow is a bit of an odd trade-off they'd have to make because they're not actually interested in that. But for us, what it means is if someone's actually building an app, if someone opts into normalized caching, we're much more aggressive about warning people if they run into issues. And I think that's the only thing right now that we can make. Apart from maybe recommending GraphQL code generator, which is actually more on the side of integrating with types, integrating your queries with your language and your app more closely and avoiding mistakes. But I think, at least from our end, there's a bit of nuance to that discussion on when the user's ready to upgrade, so to speak. When a user's ready to take on that added complexity. And I think we've come to terms with letting the user decide when that time comes.

That's definitely a really interesting take. Like more user-focused, I guess. And it's still like, as I said earlier, it's still like you're using GraphQL, but then it's kind of a journey rather than just a step. So it's more progressive and knowing what you're ready for and comfortable with and then slowly getting there to the full potential. So that makes a lot of sense.

Dominik, do you have any comments to add to this? Yeah, well, not a lot. I agree with Joao, I've also seen the struggle of life where people want smaller libraries with more features. And then you add more features, and then library is too big. And then someone says, let's use the smaller one. And then it starts all over again. And at the same time, faster builds, but more stuff happening at the build steps that we get more correctness and more safety. And it's also trade-offs. Again, because React Query is a very unopinionated library, when it comes to how you produce that from this, we also can't leverage that much of the information that you could possibly have. A GraphQL code, again, as was mentioned, is a very good way to find the middle ground between it. You can also create your useQuery hooks from React Query with that, to get at least some of the safety bag. The normalized cache is also a topic that always comes up a lot. It is something that people are asking, why doesn't React Query have a normalized cache? The answer is, it's manifold. In one instance, it's a very hard problem to solve, I think, and it's especially very hard to solve if you don't have GraphQL. If you are not into that specific tying, then it will get even harder. Just to say, not a big company behind React Query, we haven't really gotten around to thinking about this a lot. But also, one of the things that people are wanting more frequently, even if they don't want a normalized cache, is this automatic revalidation that you also get from the schema. And this is something we have actually been thinking about also adding just to give this experience to the developers and also to the users.

That sounds great, Dominique. That's really great insight. So, love that. That also kind of brings me to this question about type safety. And there are like two different sides to it. The first is like graph QL introduces a strongly typed schema, so it only makes sense to use a strongly typed language to sort of unlock the full potential of the superpower of GraphQL. But I also want to hear from you, Dominique, about your side of, since you said that a React query is a very unopinionated client, so I'd love to hear about, just from the perspective of a client, not a GraphQL specific client, but like, does it make sense or like what are the benefits and drawbacks of building a client using like strongly typed language versus loosely typed versus an untyped language, and then we can just sort of see the contrast with the GraphQL specific clients. Yeah, so I'm a fan of strongly typed languages, and also I mean if you talk about TypeScript being very strongly typed language, I still think it's one of the best things that could have happened to the JavaScript ecosystem.

And React Query initially was also written in JavaScript and just provided the types, but then very fast way in version 2 rewritten it in TypeScript. And for us as the library authors, I think it just brings a ease of maintainability and type safety that we have within, if the library is also written in TypeScript. And then it also projects that on the consumers, because they get the types that we have to use. Of course, there's a curve involved in it. I mean, this is also where you hear about people getting started with TypeScript that they would rather just do in JavaScript, but I think it pays off really very fast if you just go that way. I wouldn't do it any other way.

That's awesome. It's exactly what I was expecting, so it's really good to hear that. Joe, do you have any thoughts on like your side of this topic about like what do you think about pairing GraphQL with a strongly typed language, or like was this that loosely typed or an untyped and the potential benefits and drawbacks of that? I mean, I think we were using Relay way back, before Flow, I guess like around the same time as Flow was getting started internally, where a lot of the code that was consuming Relay queries was not written in a typed language, and it provided a lot of value all the way back then. So I think a GraphQL client gives you a lot of capabilities, like the ability to coalesce all your data dependencies up into a single request, the data consistency, a lot of this stuff we've talked about is actually not really specific to typed languages. It's just kind of these fundamental capabilities that GraphQL gives you. Obviously, because you have this schema, you also then can produce strong types. And, yes, I'm a huge fan of strong typing. So, certainly, I think it's even better to – you're going to get a better, more reliable application in general, I think, if you build with a strongly typed language. It's definitely tricky to build the client itself in a strongly typed language, because ultimately, if you're working with a normalized cache, you kind of have to have a lot of mixed data. And so, basically, you have this strongly typed schema where the fragment, let's say, says it needs to read the name field, and that's supposed to be a string. But what you've got in the store is, even if you're representation – even if you're using a strongly typed language where you have a proper enum or union expressing the fact that the field data could be a string or a bool, or whatever, you still at some point have to say, okay, I'm gonna expect it to be a string now. I'm gonna expect this field value to be a string. And this is the fundamental thing where ultimately when you go from a database, which is what the normalized cache is up to an application, you have the boundary that you're crossing from a dynamic untyped world, right? So, you can get a lot of type safety within the code of the client, but there's – there is a limit of that boundary. But thankfully, again, we have a schema. But you just kind of have to be careful in how you design the client to prevent data from getting written into the cache that violates the schema. And so, that's kind of something to be aware of as you're building a client like this.

Sounds good. And I think that also could have been like a deeper discussion, but maybe we could save it for a special chat. We – so, we would love to hear more thoughts there. But Phil, do you have any other thoughts on this? I mean, on the end of the users, it's unthinkable these days, I believe, at least on the web, to not use TypeScript with GraphQL because of the safety it gives you. I guess to go back to I think what Dominic more reflected on building clients or GraphQL clients with a typed language, and in this case, not even a strongly typed language, I think when you're building something like a cache, and what Joe is alluding to is without these type guarantees, finding out all the bugs would have been impossible for us. In fact, we had so many requirements for ourselves in terms of how Oracle should perform, or specifically GraphQL or normalized cache, that a lot of parts that we had initially were even written in Rescript formally reasoned. I guess that's kind of the Facebook slash Mata-approved way, ironically. But over time, this fell away because we replaced them with TypeScript rewritten parts. That said, yeah, I mean, for us and for users, the benefits of using TypeScript over nothing at all are pretty clear. And I mean, the drawbacks have disappeared over time. So I think there's nothing really to add to that.

Interesting. Yeah, definitely. Ellen, what's your perspective on this? Yeah. I mean, so I'll just admit, like personally, I'm wildly biased in favor of strongly typed languages. Like, they're basically what I've used my entire coding career. But I think one of the things that can be a drawback is that if you are working with a strongly typed language, you have to fit something that is built for a language that isn't strongly typed into whatever your strongly typed language is paradigm is. One place that we ran into problems with this with the iOS client at Apollo is that I had this grand idea of trying to turn basically fragments into protocols for Swift. And and an extremely long story made short is Swift doesn't quite support the way I wanted that to work because it doesn't really have full support for covariance. And it was interesting our Android and Kotlin client was able to like run with that idea because Kotlin does have support for covariance and contravariance that's pretty pretty thorough. And they were able to actually make significantly more progress on that. Then I wound up throwing away like a year of work. So it is something where, you know, taking something that's built for sort of a weekly type language and trying to put it into a strongly typed language does have sometimes its disadvantages, but I agree very much with everyone here, like taking advantage of this information that you get for free from the schema is so, so, so helpful in writing a correct application that it is something that I very strongly recommend to do if you are at all able to. Absolutely. Yeah, no, that definitely makes a lot of sense and what I really took away from this last question and all of your responses is that everyone is like on board under the benefits of TypeScript or like strongly typed languages and then sort of the drawbacks are kind of fading away with time and like the way clients are evolving. So thank you so much, folks. That was a great discussion. Learned a lot from this. I think we're running out of time. So and if anyone has no comments, I would love to wrap this up and maybe we can like take it forward later in the spacial chat. Maybe our audience has a few questions. So thank you so much. This was, had a great time having this discussion with you all.

And that prevents a level of breakage that is so common in other applications that I think is just absolutely critical to mobile. No, I totally agree. And I love how you mentioned or, like, highlighted the way that GraphQL brings out the benefits of the people side of things, like teams communicating, right? Because it's such an underrated thing, right? Like, GraphQL is empowering actual developers and not just in terms of, like, the features that we're able to ship now or, like, the tactical benefits of it, but also, like, the people side of it and how much it has been, like, empowering us to, like, better communicate with our team members. Yeah, so definitely agree with that. And I just absolutely love that point.

Then also, some of the points that you folks have mentioned, that also brings me to this follow up question about, like, in our app development, as Joe said, that there were so many things that we didn't really notice is going wrong until GraphQL came along. Do you think, because of that aspect, do you think, like, having clients that have GraphQL support baked in would be, like, just a crafted experience for GraphQL on the client side would be really helpful, or is it, on the alternate side, is it better to have, like, clients that are not GraphQL-specific, I'd say, but so as a utility for it? What are your thoughts about that? We can just go with you, Ellen.

Yeah, I mean, I think I'm coming from the place of supporting two SDKs that are in very strongly-typed languages, and I think, you know, what we've definitely found is that, at least in Swift and Kotlin, I know that there are other mobile experiences that sometimes have a different approach, but I know that in Swift and Kotlin, one of the big things that we've found is being able to compile everything down to a type-safe, a type-safe query has been huge for a lot of people in terms of both being able to partner certain things with individually-designed views and stuff like that, but also just in terms of being able to process data that they're getting from the GraphQL, and even if it needs to be, at some point, transformed into a view model or something like that, it's still much, much easier to at least have an idea of where you're starting for a lot of this stuff.

And I think it's not something where... I know that on... On web, there's a lot of stuff where it's like, the relay stuff is very, very tightly tied to relay UI principles, and that isn't as much of the case on mobile. I know that somebody was saying, I think it was Joe, was saying that there's some stuff that is a little bit differently handled at Meta, but I think in the wider iOS and Android world, I think it is something where people are trying really hard to get this integrated with SwiftUI and Jetpack Compose, which are more reactive frameworks that are inspired by React. But it's something where there's not quite as much of a tight binding as there is, I think, between GraphQL and React, and particularly GraphQL and relay. That sounds great. Phil, do you have any thoughts around this?

It depends, I guess. There's a degree of how much we depend on GraphQL depending on which GraphQL client here we're talking about. I think it's particularly interesting, and I'm actually looking forward to what Dominik has to say about this, about differentiating between GraphQL as a UI pattern and as kind of a guiding principle of how we build our apps and a client as a fetching library. And I think there's an interesting balance that can go either way, depending on the use case and depending on the users. And now we decided to actually not add any shims, so to speak, to execute GraphQL on the client side and instead only rely on APIs.

And specifically, I think, a couple of years ago, that was more of a controversial decision as people weren't quite ready yet to ship GraphQL APIs to production and accept requests and build them. But I think there have been so many more cases and so many more advantages of GraphQL have come around more recently and have surfaced over time that kind of show that when you're building with GraphQL, when you're building a GraphQL schema, it's pretty important to design that schema. And I think the same benefits apply to why it's a bit different speaking about a GraphQL client and speaking about fetching in general, because it depends on how you're building your app and whether you go all-in, so to speak, or not.

Yeah. Yeah, that totally makes a lot of sense. And I agree. I would also like, I'd love to hear what Dominik has to say about this. Would love to hear from you, Dominik. So I wouldn't even say that that ReactQuery is a fetching library, but I would even go one step further and say ReactQuery is just an Azure state manager. And this is always confusing to some people when I say ReactQuery is not tied to data fetching at all. It doesn't really care how you produce the results. It actually only needs either a resolve or a rejected promise. And how you build that is entirely up to you. And I think this is a completely different approach than other libraries have. So it's not tied to GraphQL at all. It's not tied to rest at all. And this gives you a bit of flexibility when you have to work with multiple backends where you sometimes have GraphQL, you sometimes have rest different endpoints that you have to hit. I've even seen some users read data from the Ethereum API or something Web3-related to get data via ReactQuery. So just to manage the states that you have that is asynchronous. But of course ReactQuery is used most prominently with data fetching. And yes, it's not tied to GraphQL so that is a trade-off that you are undoing. I think it's all trade-offs. The cache that ReactQuery has is a very minimalistic document cache and you don't have all the capabilities that you might have with a very specific GraphQL cache. But you also have other benefits like being able to use multiple sources or having a very predictable and reliable cache container that will just also give you the power that you need to do the refetching that you want in the times that you want it. Absolutely.

And I think just to like reiterate on what some of you have said about like tying your clients to GraphQL or not. I think it totally depends on whether or not you're completely invested in building out your app using GraphQL entirely or a lot of companies, a lot of products are, they have like C code and they don't entirely like migrate to GraphQL right away. They kind of have to go through like go through building progressive layers on top of that existing REST APIs. And I think it kind of makes sense to have some sort of a utility-driven framework like a client that could be well suited if you want to work with GraphQL it could be well suited if you want to work with REST APIs but then also is not entirely tied to the patterns driven by GraphQL itself. So that totally makes a lot of sense.

Joe, do you have any other thoughts on this? Yeah, yes I think there's kind of, we've kind of touched on two pieces. One is the extent to which your client is coupled to GraphQL. And then the that Ellen kind of talked a bit about was how much you're kind of coupled to the given UI library, right.

And so for the first kind of coupling to GraphQL. Yeah, there's real trade-offs there as you've all talked about, right. Not everyone has their data their backend data in GraphQL. Even at meta there's still some apps that have their data that's kind of not exposed via GraphQL for various reasons. But I think there's kind of real trade-offs with that. So the GraphQL, the fact that it gives you a typed schema the schema can express a lot of information that clients can take advantage of. And so the reason that we have these powerful clients is the GraphQL schema. There's just simply capabilities that we can do with a GraphQL client that are just not easily done with arbitrary rest end points, even if they're fully typed, even if you've got a full TypeScript or whatever definition for your types that is providing a lot of rich type information. There's actually more information that a GraphQL schema can provide. For example, indicating via directives what is the primary key, is this entity cacheable, those types of information. And then also just knowledge about enums and things like that, interfaces, the ability to introspect dynamically to actually get the type, being able to rely on that. What is the actual concrete type of value at runtime? You can't do that in general with a REST endpoint. And all those things are really fundamental to building a very powerful client to get data consistency. So what we tend to see is basically clients that are like, as you said, Dominic, with React Query, where it's really document caching focused. But even then, you don't know enough about what's in that document to do things like invalidating automatically based on changes because you can't do the Oracle approach of just using type names, which is one approach that is probably going to over-invalidate quite a bit, but at least it gives you automatic invalidation.

And so I think, I guess my kind of hope for the ecosystem is that we work to make it easier to build GraphQL servers so that people can then just take advantage of the GraphQL client capabilities, as opposed to saying, well, let's just kind of go to the lowest common denominator and build clients that can only do what we could do with REST because we just want to make it easy to adopt. And so I think the clients kind of make different trade-offs along there. There's, I guess, a whole nother question of integrating at the view layer, which is, that's like almost a separate question. Absolutely, no, that makes a lot of sense. And just, it's good to learn about what kind of trade-offs would there be if, like depending on your approach, that kind of also calls for a question that I really wanted to hear all of your thoughts upon, but Ellen partly answered that already but would still like to go into more of it and hear from all of you about, you know, like one of GraphQL's innovations is introducing a strongly typed schema that exposes rich information about server capabilities, but then I think that most clients do not or like do not choose to, or cannot use much of this schema information by default. So how much do you think for your scenario or for the space that you're working in, how much do you think this still holds true? And what are your thoughts on it? Ellen, I'd love to start with you about this question, actually. Yeah, I think that's basically not true on mobile. I think particularly because, again, like I said, the one of the things that you can do when you have both the schema which sort of outlines what is possible and then the query that you're gonna be making which says, okay, what am I actually asking for? You can do a lot of validation on that and then you can also generate type safe code that is really helpful. And I know that there's some stuff like I know GraphQL code gen is huge in this space, in TypeScript in particular, but another method that I've seen on iOS, which is sort of basically not how we're doing it, at Apollo but is something else that I've seen is essentially being able to use the schema to create sort of type safe queries when you're creating those queries at runtime. So there's a lot of stuff that you can do that can really take advantage of that. And I think honestly, I think that's a huge piece of the value proposition for mobile just because there's just so much stuff we have to do to take stuff from JSON and turn it into something that is usable in a type safe language. And having that level of validation even at compile time, it's super, super helpful.

And having that level of validation even at compile time, it's super, super helpful. That definitely sounds helpful and really convenient but I actually started off with you just to see that kind of contrast between the case in mobile development and then how it is for the web.

So, Joe, do you have any comments on this from your side? It's been really interesting to see how this has kind of played out in the ecosystem. I mean, definitely for mobile where we're working with very strongly typed languages I think everyone's kind of, basically your hand is forced, right? You're gonna use this schema information although how we use it there is still interesting.

But on the web, I think the ecosystem tends to focus on ease of getting started and simplicity. You see a lot of, there's this kind of cyclic nature where a library comes along, it solves more problems, adds more features which can lead to complexity that many developers may not need. It's a continuous cycle in the JavaScript ecosystem where easier-to-use libraries gain adoption but subsequently fall into the same pattern of feature bloat.

And so in other libraries come along and say like, Oh, we're easier to use. Then they get more adoption, they add more features. And then some, like, now they've just fallen into the same pattern. And then so, and you just see this like endlessly happening in the JavaScript ecosystem. Circle of life.

Yeah, it's honestly as a library developer, it's pretty frustrating to watch. Cause it's like, y'all are just going to run into this problem next, and then this problem next and this problem next. And so, and what that means though, is that, well obviously one of the easiest ways to get started is to just not use the schema.

By taking advantage of the schema, you can actually implement the graphical spec correctly. You can't implement the graphical spec correctly if you don't know the schema, if you don't know the types of objects, if you don't know which types implement which interfaces. And so we see this where there are multiple clients on the web where if you don't go through extra work, you will actually not get correct behavior.

And so we see this where there are multiple clients on the web where if you don't go through extra work, you will actually not get correct behavior. And you'll be wondering, wait, why is this, and basically every client other than Relay, by default, you will get incorrect behavior on certain parts of the spec because they don't use the full schema information by default. And so I think it's just a really interesting way that the ecosystem has gone. There's definitely trade-offs, right? It does make it easier to get started. And so I think that's not to criticize, that we're making different trade-offs, but it's just very interesting how the schema provides such rich information and yet we don't all take advantage of it on the web.

And I think that's just a real trade-off of, it's not as easy to build some of these features into JavaScript as we'd like. I think in the native platforms, we just have, people are used to, you know, a build step. So that's kind of like, sure, of course you're gonna have a build step, so let's have more extra, you know, let's add more there to give even more value to the developer, whereas on the web, it's like, oh, another build step. And so there's kind of more of a, like, okay, well, let's maybe not have a build step and make some trade-offs to kind of get that ease of use and then fit into the JS ecosystem.

No, that definitely makes a lot of sense. Like, it's like understanding the value that GraphQL brings and then wanting to use it, but then also not being able to somehow leverage the full power that you could with your apps, like building it out with GraphQL. So Phil, do you like, what do you think about this? It's definitely trade-offs, yeah. By I think to a certain extent, it's not always as library offers our trade-off to make, at least not in the opinion we have in terms of Urql where we provide two different default caches. When you just install it, you have a document cache which is very primitive and you can switch to a normalized cache, at which point we then actually recommend people to use something we call schema awareness, which is literally just using introspective schema data for both correct behavior.

But the reason why I'm saying it's not our decision to make on the web is because there are so many different ways to use the web so to speak, to create web apps and pages. Sometimes when a developer is just creating a very content-based page, the data is very static and not highly interactive. Hence, they might not be interested in some of the dynamic features from normalized caching and the trade-offs they want to make. Forcing them to go through that setup flow is an odd trade-off if they're not interested in it.

On the other hand, for those building an app, opting into normalized caching means a more aggressive approach to issue warnings. The discussion extends to when the user is ready to upgrade and take on added complexity. Letting the user decide when that time comes is a nuanced approach. It's about a progressive journey with GraphQL, knowing what one is ready for and comfortable with.

The struggle between smaller libraries with more features and the trade-offs involved are evident in the challenges faced. React query's unopinionated nature limits leveraging information available. Finding a middle ground with GraphQL code and creating use query hooks from React query for some safety back is crucial. The normalized cache topic is frequently raised, highlighting the complexity of solving it without GraphQL.

That's definitely a really interesting take, like more user focused, I guess. And it's still like, as I said earlier, it's still like you're using GraphQL, but then it's kind of a journey rather than just a step. So it's more progressive and knowing what you're ready for and comfortable with, and then slowly getting there to the full potential. So that makes a lot of sense.

Dominic, do you have any comments to add to this? Yeah, well, not a lot. So I agree with Joe. I've also seen the struggle of life where people want smaller libraries with more features. And then you add more features and then the library is too big. And then someone says, let's use the smaller one and then it starts all over again. And at the same time, faster builds, but more stuff happening at the build steps that we get more correctness and more safety. And yeah, it's also trade-offs again, of course, because React query is a very unopinionated library when it comes to how you produce that promise.

We also can't leverage that much of the information that you could possibly have. A GraphQL code, again, as was mentioned, is a very good way to kind of find the middle ground between it. You can also create your use query hooks from React query with that to get at least some of the safety back. And yeah, the normalized cache is also a topic that always comes up a lot. It is something that people are asking, why doesn't React query have a normalized cache? And the answer is, yeah, it's manifold. So in one instance, it's a very hard problem to solve, I think.

And it's especially very hard to solve if you don't have GraphQL. So if you are not into that specific tying, then it will get even harder. So we haven't really, yeah, just to say not a big company behind React query, we haven't really gotten around to thinking about this a lot. But also one of the things that people are wanting more frequently, even if they don't want a normalized cache, is this automatic revalidation that you also get from the schema. And this is something we have actually been thinking about in also adding just to give this experience to developers and also to the users.

That sounds great, Dominik. That's really great insight. So love that. That also kind of brings me to this question about type safety. And there are like two different sides to it. The first is like GraphQL introduces a strongly typed schema, so it only makes sense to use strongly typed language to sort of unlock the full potential of the superpower of GraphQL. But I also want to hear from you, Dominik, about your side of, since you said that React query is a very unopinionated client, so I'd love to hear about just from the perspective of a client, not a GraphQL specific client, does it make sense or what are the benefits and drawbacks of building a client using strongly typed language versus loosely typed versus an untyped language? And then we can just sort of see the contrast with the GraphQL specific clients.

Yeah, so I'm a fan of strongly typed languages and also, I mean, if we talk about TypeScript being a very strongly typed language, I still think it's one of the best things that could have happened to the JavaScript ecosystem, and React query initially was also written in JavaScript and just provided the types, but then very fast way in version two, we've written it in TypeScript. And for us as the library authors, I think it just brings a ease of maintainability and type safety that we have within if the library is also written in TypeScript. And then it also projects that on the consumers because they get the types that we have to use. Of course, there's a curve involved in it. I mean, this is also where you heard about people getting started with TypeScript that they would rather just do in JavaScript. But I think it pays off very fast if you just go that way. I wouldn't do it any other way.

Sounds awesome. Exactly what I was expecting. So it's really good to hear that. Joe, do you have any thoughts on your side of this topic about like, what do you think about pairing GraphQL with a strongly typed language or like versus that loosely typed or untyped language and the potential benefits or the drawbacks of that? Yeah, I mean, I think the, we were using relay way back before Flow, I guess like around the same time as Flow was getting started internally, right? Where a lot of the code that was consuming relay queries was not written in a typed language and it provided a lot of value all the way back then. So I think a GraphQL client gives you a lot of capabilities, right? Like the ability to coalesce you all your data dependencies up into a single request, right? The data consistency, all the stuff that we, a lot of the stuff we've talked about is actually not really specific to type languages. It's just kind of these fundamental capabilities that GraphQL gives you. Obviously, because you have the schema, you also then can produce strong types. And yeah, I'm a huge fan of strong typing. So, certainly, like, I think it's even better to, you're gonna get a better, more reliable application in general. I think if you build with a strongly type language, it's definitely tricky to build the client itself in a strongly typed language, because ultimately as if you're working with a normalized cache, you kind of have to have a lot of like mixed data. And so basically you have this strongly typed schema where the fragment, let's say, says it needs to read the name field and that's supposed to be a string. But what you've got in the store is, even if your representation, even if you're using a strongly typed language where you have a proper enum or union expressing the fact that the field data could be a string or a bool or whatever, you still at some point have to say, okay, well, I'm gonna expect it to be a string now. I'm gonna expect this field value to be a string and this is like the fundamental thing where ultimately when you go from a database, which is what the normalized cache is up to an application, you have this... The boundary that you're crossing from a dynamic on-type world, right? So you can get a lot of type safety within the code of the client, but there is a limit at that boundary. But thankfully, again, we have a schema. But you just kind of have to be careful in how you design the client to prevent data from getting written into the cache that violates the schema. And so that's kind of something to be aware of as you're building a client like this.

Sounds good and I think that also could have been like a deeper discussion but maybe we could save it for a special chat. So we would love to hear more thoughts there. But Phil, do you have any other thoughts on this? I mean, on the end of the users, it's unthinkable these days, I believe, at least on the web to not use TypeScript with GraphQL because of the safety it gives you. I guess to go back to, I think what Dominic more reflected on building clients or GraphQL clients with a type language and in this case, not even the strongly typed language. I think when you're building something like a cache and what Joe is alluding to, is without these type guarantees, finding out all the bugs would have been impossible for us. In fact, we had so many requirements for ourselves in terms of how a code should perform or specifically Graph cache or normalized cache that a lot of parts that we had initially were even written in a rescript, formerly Reason. I guess that's kind of the Facebook slash Meta approved way ironically. But over time this fell away because we replaced them with TypeScript rewritten parts. That said, yeah, I mean, for us and for users, the benefits of using TypeScript over nothing at all pretty clear. And I mean, the drawbacks have disappeared over time. So I think there's nothing really to add to that. Interesting. Yeah, definitely.

Ellen, what's your perspective on this? Yeah, I mean, so I'll just admit like personally, I'm wildly biased in favor of strongly typed languages. Like they're basically what I've used my entire coding career. But I think one of the things that can be a drawback is that if you are working with a strongly typed language, you have to fit something that is built for a language that isn't strongly typed into whatever your strongly typed language paradigm is. One place that we ran into problems with this with the iOS client at Apollo is that I had this grand idea of trying to turn basically fragments into protocols for Swift. And an extremely long story made short is Swift doesn't quite support the way I wanted that to work because it doesn't really have full support for covariance. And it was interesting, our Android and Kotlin client was able to like run with that idea because Kotlin does have support for covariance and contravariance it's pretty thorough. And they were able to actually make significantly more progress on that than I wound up throwing away like a year of work. So it is something where taking something that's built for sort of a weekly type language and trying to put it into a strongly type language does have sometimes its disadvantages. But I agree very much with everyone here like taking advantage of this information that you get for free from the schema is so, so, so helpful in writing a correct application that it is something that I very strongly recommend to do if you are at all able to.

Absolutely, yeah, no, that definitely makes a lot of sense. And what I really took away from this last question and all of your responses is that everyone is like on board onto the benefits of TypeScript or like strongly type languages and then sort of the drawbacks are kind of fading away with time and the way clients are evolving. So thank you so much, folks. That was a great discussion. Learned a lot from this. I think we're running out of time. So if anyone has no comments, I would love to wrap this up and maybe we can take it forward later in the special chat. Maybe our audience has a few questions.

So thank you so much. This was, had a great time. Having this discussion with you all. Bye. Thank you. Thank you. Thank you so much. Thank you. Thank you so much for joining us today. Thank you for coming and I hope we can have a lot more of this discussion in the future. Thank you so much for having this discussion with you all. Bye. Thank you so much for having this discussion with you all. Bye. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all. Thank you so much for having this discussion with you all.