@@evandroprogram @mattpocockuk can this work with its own ad hoc tagged template literal? like use the graphql import as a tagged template literal insetad of a type, i had in my head that tagged template literals were just functions... yeeees????
@@seannewell397 I think from what Phil has said elsewhere in this comments section, it's a TS limitation that you can't do smart inference from a tagged template literal.
Looks interesting just wondering how I could get this working in a monorepo I guess you could set the output file location to where you use your UI ? So if I had a graphql package I could output the file to where my project/s live.
Type magic like this used to feel so crazy to me until I learned the basics of Haskell. Turns out that there are a ton of similarities there. Typescript types are to a certain extent just less powerful Haskell-like functions.
Just generate once all your queries and pick fields with boolean to infer fields. There is no need to infer via string interpolation, its such a performace hit for being lazy. It doesn't scale!
it's not lazy if you are rapidly developing the queries and UI together off of a schema. And the author would beg to differ on the scale, they already put out huge perf improvements. Go back to your hidey hole troll! Begone with ye! Use your primitive sticks and cli tools to ahead-of-time parse your documents and queries for strong typing! We shall have our cake and eat it too! muwahahah!
We're working hard on making sure this is as performant as it can (and has to) be, and we're aware that gql.tada will require ongoing performance work to keep it fast. Its last few releases even mostly revolved around more performance work. In general, JS DSLs (i.e. mapping the GraphQL query language to a JS object/array/misc syntax) is a nice workaround, but replicating the expressiveness of GraphQL queries is hard and introduces yet another learning curve. The goal of gql.tada however is to remove the hurdle of codegen and to remove more learning curves and large toolchains (e.g. for codegen) Furthermore, the usage that GraphQL promotes is a heavy use of fragments & fragment composition, directives (like include & skip, and in the future: defer & stream), field arguments alongside selections, etc. All this mapped over to JS usually results in an experience that either compromises on healthy GraphQL query patterns, or productivity/DX imho In short, we want to provide an easier alternative
Is there any way to block when it happens? any lint rule or something like that? I added this library in my project and I receive the "You're trying to access email on an object that doesn't contain it." error, but it doesn't block. I can run "yarn dev or yarn lint" without errors.
What if I want to write in Graphql files? I mean what different that having codegen in watch mode? Not everything needs to be in a .ts file with special encapsulation methods
I used apollo client with codegen for typescript, back in the day. I still don't know how I feel about graphql in general, compared to rest or rpc it just seems bloated.
We have an open RFC for this, but one of our goals is to provide a (t)RPC-like experience too, so GraphQL feels less of a burden for quick/small projects
Genuine question: Does GraphQL make sense in a SvelteKit/Next/Nuxt framework if you're actually using SSR and not exposing an API to the outside world?
@@mattpocockuk I would like to understand your answer better. Why not? After all, front-end developers who use SSR frameworks will still benefit from typing. Even more so, of course, if the API is used by more clients.
@@m_filho If your backend only has one client, and that client is deployed alongside it via a fullstack framework, then using a strongly typed layer between them feels like massive overkill. I have made this mistake before. An RPC is just better in that situation.
yes! 🎉this should be as close to a drop-in replacement as possible. If you haven't used typegen for GraphQL before (i.e. graphql-code-generator; unless you've used their client-preset) it should hopefully be a smooth experience to switch over by following the setup steps and swapping out graphql-tag gradually
I was having a look into this today as I'm looking to implement this at work. Looks like there is a preset in codegen to generate the graphql schema files for the client. I was really hoping to use this without writing out the schema by hand. Thank you for this really excited for the type safety and DX 😊
@@mattpocockuk woah 😳, that's bold and awesome 😎. Thank you, I'll dive a bit deep into it. Kindly lemme know if you recommend any resources, TIA. Also I bought your Core Volume + React Bundle, it's going very well, can't wait to complete and be confident with TS codebases 🙌
We've been lucky to have gotten a lot of feedback already, including the 7MB auto-generatedHasura schema (which is bigger than GitHub's by a large margin) that have prompted us to investigate bottle-necks, and we're both aware that TS inference performance will always have to be an ongoing focus for gql.tada and we're willing to react quickly to reports and feedback on performance 💜
I'm not a fan of their tweet stating "oh it went from 8 seconds to 40ms", that should raise a red flag as a dev. What's the context? was it always 8 seconds? was it a bug? The way they formulate it implies that the bug was always there, they just only now found it. How does that happen? This is definitely not hate towards the project, I'm still impressed by the amount of effort and dedication that's being put into this, and I'm sure it'll get used by projects using graphql.
They gave an enormous amount of context and showed how other people could fix similar bugs. I don't think you're seeing the wood for the trees here. Fixing these things in public and admitting your mistakes is brave and encouraging.
It was caused by a mistake and there's a small tweet thread of mine on it in the tweet Matt showed in the video. The context here is that we tested against the GitHub schema (one of the largest “human-written” schemas we know of) and that performed well enough that it didn't raise any concerns, so we went ahead and released & announced v1. A user then tried it out with their schema which wasn't “human-written” but a Hasura-generated schema, which was an order of magnitude larger than the GitHub schema (!) and caused massive slowdowns. This prompted me to look into why the size of the schema suddenly caused the type checker to spend exponentially more time rather than linearly more time coupled to the size of schemas, and the mistake came down to a generic constraint (which are eagerly checked by TS) traversing the whole schema on each file change in the tsserver. Removing the redundant generic constraint (or rather shortening it to not traverse the whole schema) got rid of that slowdown entirely. We still encountered some more issues with that Hasura-sized schema, but I'm thankful to the issue reporters (who also got their hands dirty and helped out) to spot this. Totally understand this isn't hate, and I'm happy to actually chat and learn about this openly! ❤ We won't get all of this right immediately, but it's a lot of fun to discover and talk through the problems of this approach, since it requires a lot of dev time compared to the “simple” experience at the end of it as shown in the video 😄
I have been working with prisma with next js and the same thing which you mentioned like the other tools have is they generate index.d.ts from them inside node modules, but in this case how crazy is that, can you in your in your next video could explain how this thing has been implemented, maybe a basic understanding
I think this library has its use cases, particularly for quick prototyping and small builds. I don’t know any large scale apps that inline all their queries.
Not sure what you mean by inline? These queries can be saved as separate variables, combined with fragments, and generally treated how you'd normally treat graphql queries/mutations.
There's plenty, and to be fair, a common solution to “public” schemas and queries are persisted queries, which we'd have to support eventually. Optimising for this is imho best done in a build/compilation step, not in how we author (or codegen) code. I'm thinking we could provide Vite/Webpack/etc plugins in the future, but that's quite a big investment in dev time. However, for the common case, having GraphQL queries rather than pre-parsed ASTs in your JS source (i.e. ignoring the use of persisted queries for a moment) is not as expensive or cumbersome as it may at first appear
10000% agree with this. The more magic that happens behind the scenes with crazy typescript inference, the more likely you'll encounter a very niche bug that has no solution
We unfortunately can't make this work with tagged template literals, since TypeScript chose not to infer exact string literal types for them. It's a bit of a bummer, but I'm hoping that after some time to get used to it string literals will feel just as natural
Built/consumed REST APIs for 4 years, never any problem. Was forced by my boss to use graphql for next 4 years, hated it, was never nearly as productive. Convinced my boss that we ought to go back to REST APIs for the last 6 months, never been happier and more productive. GraphQL takes the http protocol, ignores 75% of it, and is all around awful. Good bye.
Disagree, using the actual GraphQL language always feels better than using GenQL's weird object syntax. I found GenQL a joy to use myself but a pain to teach to others.
I get your point@@mattpocockuk but I love not having to remember a graphql api. GenQL gives me this possibility as all my queries/mutations are typed. When working with different projects at the same time it became essential to me.
This is too complicated of a solution for something you can write with 3-4 functions to get the same effect. In my personal opinion. And string parsing in typescript looks too complicated in comparison with working with objects. 4/10 library :D
I like to think gql.tada is part of our admission that there's more work to be done (we're also the core team for urql, a GraphQL client) While there's a lot of ways to write GraphQL, both on the client-side and server-side, even just looking at the TS ecosystem, there's a lot of problems, from marketing, learning and producitivity curves, differences in user-bases and their expectations, to a heap of tooling to learn. While, even as a library author, I have to admit, throwing another tool onto this pile isn't the be-all and end-all solution to every problem, coming at this from an angle of “fixing” part of this experience for more people is how I think we can start to address GraphQL’s flaws and the bad rep it now has in some circles
It depends on how we look at it. Will people who don't choose it be definitively worse off? No. Will people be better of if they choose it? It depends. In many smaller projects it can be a value-add, specifically in team communication and structuring data. But I'd be the first to say, not everyone should use GraphQL. However, if we look at *the* most popular alternative of today, tRPC, it becomes clear to me that GraphQL has not only a marketing problem, but also a producitvity and learning curve problem, and we build tools like gql.tada to improve this, making GraphQL an option with few or no drawbacks for more people. So, that's what it's about for me fewer drawbacks for a larger group of people 💜
For context, what I'd say is a 7MB schema is a borderline case and you won't find it outside of Hasura's generated schemas in larger projects. To compare this, GitHub's schema, which is what we tested against as a larger schema at release time, doesn't come close to this size. The tweet and comparison was more to demonstrate that we made mistakes and there are performance pitfalls in the library code itself, but we're willing to improve even for extreme cases
Is this video sponsor by gql.tada? This solution is super. fancy❤ But I asking me if this solution is superior to typegraphql? If you want to do a refactoring in the schema, the schema still a string. What is your opinion about it?
Nope, I don't do sponsored content. Using the string means you're actually using the DSL of GraphQL, which is bound to be easier than a DSL on top of a DSL.
the web dev community really pushes the boundaries of what could DX feels like
yes by making everything slower
They come up with their own problems then spend the rest of their time coming up with the solutions to those 😂problems
If they add some syntax highlighter in that string then it would be absolutely craziest thing
Yep, available in a VSCode extension - wasn't working for me for some reason.
@@mattpocockuk I guess to the syntax highlight extension to work, you have to use tagged template literal for querying. (gql`...`)
@@evandroprogram @mattpocockuk can this work with its own ad hoc tagged template literal? like use the graphql import as a tagged template literal insetad of a type, i had in my head that tagged template literals were just functions... yeeees????
@@seannewell397 I think from what Phil has said elsewhere in this comments section, it's a TS limitation that you can't do smart inference from a tagged template literal.
It should be quite simple with treesitter language injection queries.
The quality of your videos really stands out!
WHAT IS THIS BLACK MAGIC??
Absolutely amazing!! I didn't even know this is possible in typescript.
Okay now that’s insane. I’m sold
This is next level. Really cool work.
Holy S**t! I will not sleep tonight! Thank you for sharing this 😊
Looks interesting just wondering how I could get this working in a monorepo
I guess you could set the output file location to where you use your UI ? So if I had a graphql package I could output the file to where my project/s live.
Nice find! Keep us updated :)
Type magic like this used to feel so crazy to me until I learned the basics of Haskell.
Turns out that there are a ton of similarities there.
Typescript types are to a certain extent just less powerful Haskell-like functions.
Awesome tool, I'm gonna start using it, thank you for sharing.
That’s amazing. I didn’t even know it was possible to provide autocomplete within a template string.
That's more to do with the language server than anything happening in typescript
I need to learn more about parenting strings in ts
Woah, that's frikkin amazing
This is really amazing
« Tada » is used a lot for day to day communication for french people
Just generate once all your queries and pick fields with boolean to infer fields. There is no need to infer via string interpolation, its such a performace hit for being lazy. It doesn't scale!
it's not lazy if you are rapidly developing the queries and UI together off of a schema. And the author would beg to differ on the scale, they already put out huge perf improvements. Go back to your hidey hole troll! Begone with ye! Use your primitive sticks and cli tools to ahead-of-time parse your documents and queries for strong typing! We shall have our cake and eat it too! muwahahah!
We're working hard on making sure this is as performant as it can (and has to) be, and we're aware that gql.tada will require ongoing performance work to keep it fast. Its last few releases even mostly revolved around more performance work.
In general, JS DSLs (i.e. mapping the GraphQL query language to a JS object/array/misc syntax) is a nice workaround, but replicating the expressiveness of GraphQL queries is hard and introduces yet another learning curve.
The goal of gql.tada however is to remove the hurdle of codegen and to remove more learning curves and large toolchains (e.g. for codegen)
Furthermore, the usage that GraphQL promotes is a heavy use of fragments & fragment composition, directives (like include & skip, and in the future: defer & stream), field arguments alongside selections, etc. All this mapped over to JS usually results in an experience that either compromises on healthy GraphQL query patterns, or productivity/DX imho
In short, we want to provide an easier alternative
Is there any way to block when it happens? any lint rule or something like that? I added this library in my project and I receive the "You're trying to access email on an object that doesn't contain it." error, but it doesn't block. I can run "yarn dev or yarn lint" without errors.
Raise an issue!
Maybe we could see an `sql.tada` at some point too then?
This would be interesting
really nice library! I wonder if it works to integrate it into AWS DynamoDB/Amplify graphql. If this library can read Amplify graphql schema.
I'm sure it can - it can work with remote schemas.
What if I want to write in Graphql files? I mean what different that having codegen in watch mode? Not everything needs to be in a .ts file with special encapsulation methods
Having my queries in .gql files always felt extremely indirect. Having them in TS, by comparison, is much nicer.
This makes me reconsider gql
Yeah me too a bit, but only for certain use cases.
Is it parsing the string with TS types alone? If so that's wild.
Yes, it's nuts
@@mattpocockuk and here I am, still having to look up generics every time I have to use them 😂
@@wlockuz4467 Yeah this is absolutely nutty
Does this plugin work with remote schemas?
Yep
Wow pretty nice!!
0:56 It'd be nice if you'd mention the problems these libraries have.
ruclips.net/video/5weFyMoBGN4/видео.html
@@mattpocockuk thanks!
This does assume that your graphql.schema file lives in the same project. Any ideas what to do when your schema's are defined in a different project?
It can target a remote schema
That's pretty cool indeed
Reminds me of F# type providers!
can we use this without client to fetch data? Due to I am making my own client to cache fetch results via nextjs fetch api
Absolutely, it's just for creating the queries. What you do with them is up to you
I used apollo client with codegen for typescript, back in the day. I still don't know how I feel about graphql in general, compared to rest or rpc it just seems bloated.
If you can do an rpc, you probably should. But if you can't, GraphQL is a pretty good option.
We have an open RFC for this, but one of our goals is to provide a (t)RPC-like experience too, so GraphQL feels less of a burden for quick/small projects
What if your schema file isn’t co-located with your front end code?
It works with remote schemas
Genuine question: Does GraphQL make sense in a SvelteKit/Next/Nuxt framework if you're actually using SSR and not exposing an API to the outside world?
It absolutely does not
@@mattpocockuk I would like to understand your answer better. Why not? After all, front-end developers who use SSR frameworks will still benefit from typing. Even more so, of course, if the API is used by more clients.
@@m_filho If your backend only has one client, and that client is deployed alongside it via a fullstack framework, then using a strongly typed layer between them feels like massive overkill. I have made this mistake before. An RPC is just better in that situation.
And I though I was good at TS when created a zod clone, this is wizardy
Will it work if my schema is defined in Apollo federation? Can it perform the introspection by itself?
Yep it can target remote schemas
@@mattpocockuk What is difference between this and what codegen can provide
@@nikolakikanovic9740 This is a faster DX with less indirection
How well does it work when the schema has syntax errors?
I ran into this myself and raised an issue. They are planning to build a CLI which will be much better at sourcing errors than a TS plugin can be.
They are?
haha
BEST LIB EVER!
hmm how to use this with apollo hooks, I have bunch of .graphql files instead. Btw does it generate the schema file as well?
No, it infers from a schema.
Does this replace graphql-tag in the stack?
yes! 🎉this should be as close to a drop-in replacement as possible. If you haven't used typegen for GraphQL before (i.e. graphql-code-generator; unless you've used their client-preset) it should hopefully be a smooth experience to switch over by following the setup steps and swapping out graphql-tag gradually
@@philpl thank you! I’ve been using code generator for many years. Excited to give this a try!
This looks interesting but if im writting the graphql files already os this not just duplication or can the gql files be generated ?
You write one schema, then each query (inside TS files) is inferred.
I was having a look into this today as I'm looking to implement this at work. Looks like there is a preset in codegen to generate the graphql schema files for the client.
I was really hoping to use this without writing out the schema by hand.
Thank you for this really excited for the type safety and DX 😊
Does it work with Code-gen?? If yes, I'd love a video on that 🙌.
It replaces codegen!
@@mattpocockuk woah 😳, that's bold and awesome 😎. Thank you, I'll dive a bit deep into it. Kindly lemme know if you recommend any resources, TIA.
Also I bought your Core Volume + React Bundle, it's going very well, can't wait to complete and be confident with TS codebases 🙌
this sounds like a recipe for causing the TypeScript compiler to lock up once you get a sufficiently complex schema-hope I'm wrong!
We've been lucky to have gotten a lot of feedback already, including the 7MB auto-generatedHasura schema (which is bigger than GitHub's by a large margin) that have prompted us to investigate bottle-necks, and we're both aware that TS inference performance will always have to be an ongoing focus for gql.tada and we're willing to react quickly to reports and feedback on performance
💜
I do too!
whats the diff between using this and graphql code generator via vscode graphql extension?
The DX of this is much faster. No need to do codegen on the queries.
@@mattpocockuk searched in their docs, is there a way to use env vars inside lsp config?
@@mattpocockuk teeeechnically codegen is happening at author time during IDE LSP compilations, as there are artifacts on disk from this plugin.
@@seannewell397 Not when you're writing the queries, only when editing the source schema.
This will make your lsp die, it is slower and more complicated and you get the same experience that i had years ago
awesome
That's impressive what you can do at the type level! Are there TS librairies specifically made to build type-level parsers?
No, this is all custom code I think
Johnson Jose Perez Barbara Jones Patricia
I'm not a fan of their tweet stating "oh it went from 8 seconds to 40ms", that should raise a red flag as a dev.
What's the context? was it always 8 seconds? was it a bug?
The way they formulate it implies that the bug was always there, they just only now found it. How does that happen?
This is definitely not hate towards the project, I'm still impressed by the amount of effort and dedication that's being put into this, and I'm sure it'll get used by projects using graphql.
They gave an enormous amount of context and showed how other people could fix similar bugs. I don't think you're seeing the wood for the trees here. Fixing these things in public and admitting your mistakes is brave and encouraging.
It was caused by a mistake and there's a small tweet thread of mine on it in the tweet Matt showed in the video. The context here is that we tested against the GitHub schema (one of the largest “human-written” schemas we know of) and that performed well enough that it didn't raise any concerns, so we went ahead and released & announced v1.
A user then tried it out with their schema which wasn't “human-written” but a Hasura-generated schema, which was an order of magnitude larger than the GitHub schema (!) and caused massive slowdowns. This prompted me to look into why the size of the schema suddenly caused the type checker to spend exponentially more time rather than linearly more time coupled to the size of schemas, and the mistake came down to a generic constraint (which are eagerly checked by TS) traversing the whole schema on each file change in the tsserver.
Removing the redundant generic constraint (or rather shortening it to not traverse the whole schema) got rid of that slowdown entirely.
We still encountered some more issues with that Hasura-sized schema, but I'm thankful to the issue reporters (who also got their hands dirty and helped out) to spot this.
Totally understand this isn't hate, and I'm happy to actually chat and learn about this openly! ❤ We won't get all of this right immediately, but it's a lot of fun to discover and talk through the problems of this approach, since it requires a lot of dev time compared to the “simple” experience at the end of it as shown in the video 😄
Not a fan of GQL, but this is indeed very, very cool.
I have been working with prisma with next js and the same thing which you mentioned like the other tools have is they generate index.d.ts from them inside node modules, but in this case how crazy is that, can you in your in your next video could explain how this thing has been implemented, maybe a basic understanding
I think this library has its use cases, particularly for quick prototyping and small builds. I don’t know any large scale apps that inline all their queries.
Not sure what you mean by inline? These queries can be saved as separate variables, combined with fragments, and generally treated how you'd normally treat graphql queries/mutations.
SQL will always dominate these type of solutions, but I definitely understand the enthusiasm for this project!
@@NetherFX Are you mad? Why the hell you compare graphql (which is basically an abstraction over http protocol) with database query language???
@@andriikliuiko4233 It's the Dunning-Kruger effect
There's plenty, and to be fair, a common solution to “public” schemas and queries are persisted queries, which we'd have to support eventually. Optimising for this is imho best done in a build/compilation step, not in how we author (or codegen) code.
I'm thinking we could provide Vite/Webpack/etc plugins in the future, but that's quite a big investment in dev time.
However, for the common case, having GraphQL queries rather than pre-parsed ASTs in your JS source (i.e. ignoring the use of persisted queries for a moment) is not as expensive or cumbersome as it may at first appear
that's wild
Oh, no. This is a no-go 🙅🏻♂
Black magic of this sort is still hunted down where I live.
Haha
Well its not really black magic :)
It just generates the d.ts file based on a graphql spec so you get type safety.
Really cool though!
10000% agree with this. The more magic that happens behind the scenes with crazy typescript inference, the more likely you'll encounter a very niche bug that has no solution
@@flexdash Then just delete all cache (generated files) and re-build.
Then you should be back to ready :)
If only this worked with relay
Would it not?
template literal would cool also
We unfortunately can't make this work with tagged template literals, since TypeScript chose not to infer exact string literal types for them. It's a bit of a bummer, but I'm hoping that after some time to get used to it string literals will feel just as natural
That's a shame! I didn't know that limitation.
@@philpl right, i had to exact problem trying to do something similar with html as an alternative to tsx. :/
good to know!@@philpl
My god this is so cool
what the f, this is nuts
who talks about it xD
Bro!
😮😮😮😮
Taylor Michelle Taylor Christopher Lee Matthew
Wilson Brian Harris Jeffrey Miller Richard
OH HELL YEAH
infers 😮
Built/consumed REST APIs for 4 years, never any problem. Was forced by my boss to use graphql for next 4 years, hated it, was never nearly as productive. Convinced my boss that we ought to go back to REST APIs for the last 6 months, never been happier and more productive.
GraphQL takes the http protocol, ignores 75% of it, and is all around awful. Good bye.
Genql is superior
Disagree, using the actual GraphQL language always feels better than using GenQL's weird object syntax. I found GenQL a joy to use myself but a pain to teach to others.
I get your point@@mattpocockuk but I love not having to remember a graphql api. GenQL gives me this possibility as all my queries/mutations are typed. When working with different projects at the same time it became essential to me.
This feels like it would be giga slow on a decent sized project.
Don’t think you watched the twitter thread part
@@danielarrizza4985 it is , i'm facing the problem right now.
This is too complicated of a solution for something you can write with 3-4 functions to get the same effect. In my personal opinion. And string parsing in typescript looks too complicated in comparison with working with objects. 4/10 library :D
I think we all need to admit GraphQL has some major flaws
Absolutely, it's basically a niche use case. But it does solve that use case very well, and having better TS support is VERY useful.
@@mattpocockuk without GraphQL, how would you create a generic API that could both be used by third parties as well as being dogfed by your own app?
@@davidsyengo1893 Don't agree with your weirdly high levels of vitriol here.
I like to think gql.tada is part of our admission that there's more work to be done (we're also the core team for urql, a GraphQL client)
While there's a lot of ways to write GraphQL, both on the client-side and server-side, even just looking at the TS ecosystem, there's a lot of problems, from marketing, learning and producitivity curves, differences in user-bases and their expectations, to a heap of tooling to learn.
While, even as a library author, I have to admit, throwing another tool onto this pile isn't the be-all and end-all solution to every problem, coming at this from an angle of “fixing” part of this experience for more people is how I think we can start to address GraphQL’s flaws and the bad rep it now has in some circles
90% should not use gql im the first place. Change my mind.
It depends on how we look at it.
Will people who don't choose it be definitively worse off? No.
Will people be better of if they choose it? It depends.
In many smaller projects it can be a value-add, specifically in team communication and structuring data. But I'd be the first to say, not everyone should use GraphQL.
However, if we look at *the* most popular alternative of today, tRPC, it becomes clear to me that GraphQL has not only a marketing problem, but also a producitvity and learning curve problem, and we build tools like gql.tada to improve this, making GraphQL an option with few or no drawbacks for more people.
So, that's what it's about for me fewer drawbacks for a larger group of people 💜
40ms to parse and typecheck a 7MB schema is slow af. not sure in what delima web devs are living in. :(
For context, what I'd say is a 7MB schema is a borderline case and you won't find it outside of Hasura's generated schemas in larger projects. To compare this, GitHub's schema, which is what we tested against as a larger schema at release time, doesn't come close to this size.
The tweet and comparison was more to demonstrate that we made mistakes and there are performance pitfalls in the library code itself, but we're willing to improve even for extreme cases
Why is this interesting?
TypeScript plus GraphQL is a fucking hard problem to solve, and I think this solves it.
Is this video sponsor by gql.tada? This solution is super. fancy❤ But I asking me if this solution is superior to typegraphql? If you want to do a refactoring in the schema, the schema still a string. What is your opinion about it?
Nope, I don't do sponsored content.
Using the string means you're actually using the DSL of GraphQL, which is bound to be easier than a DSL on top of a DSL.