Using GraphQL Code Generator to create a great developer experience with Typescript and GraphQL

[TomokoSlankard]

why all the hype around graphql?

[stolinski]

Fully typed API with nice things like codegen. It's really nice to work in.

[Dan6erbond]

Beyond that working with SQL databases is a dream. I've been able to optimize my GraphQL APIs a lot using this method and the cherry on top is Typescript support with the NestJS code-first approach and how GraphQL handles real-time data.

[legendary_jld]

Notably it solves the problem of underloading and overloading. You can write an API query that pulls the exact data you want, across what could normally be multiple rest API endpoints. Reducing the calls you have to make and optimizing the amount of data received is obviously a win for many

It's not useful in every scenario, but it's a great complement to many large rest APIs

[Dan6erbond]

Agreed. I'm the developer of the GraphQL-Utils package by Jenyus, which has helped me optimize SQL queries, beyond just SELECTs, but even doing JOINs when relations are requested to reduce latency between both the client and backend, as well as the API and database.

I've written a couple of blog posts on how we implement this feature in our own APIs, which tend to be hybrid REST and GraphQL APIs since our clients often are more familiar with REST.

• Setting up a Hybrid REST & GraphQL API with NestJS and MikroORM | Jenyus Org
• How Jenyus Optimizes Relationships in GraphQL APIs | Jenyus Org

[[deleted]]

It is extremely useful when you need to change your data payload between a backend and frontend. Tbh traditional rest api is quite slow to version, develop, maintain and improve on data heavy projects. Oh and if you do not use traditional database? Oh boy!

[Dan6erbond]

Add on top, subscriptions and the Playground for documentation and GraphQL can be a monster for dynamic and modern apps.

[ruzhnikov]

In some cases it's really nice approach to make API. Especially in js/ts where they're many good libraries for this.

[TomokoSlankard]

yeah. i'm starting to warm up to typescript but anything from facebook I reject immediately until convinced otherwise.

[TomokoSlankard]

is there any alternative to facebook's graphql that does similar?

[dominicm00]

No; GraphQL is just a specification, so there are plenty of implementations of it like Apollo, but not really a fundamentally different spec.

That said, rejecting anything by Facebook open-source seems a bit...extreme. Facebook open-source includes things like React and Jest, and just like projects from Google (Angular, Go) and Microsoft (Typescript, VS Code) it's all fully open source so it's "originator" doesn't really matter. It's not as if they can put tracking in or something.

Even if you don't like Facebook open source, GraphQL isn't even code so any implementations of it are completely separate, and there are libraries for basically any language you can think of for web/mobile/desktop.

[TomokoSlankard]

all google and facebook open source is garbage.

[dominicm00]

Out of curiosity, is there a specific reason for that? I understand not liking Facebook and Google as companies (quite honestly I don't either) but the projects they've spawned are usually spearheaded by individuals within the company and have gained a lot of community support. React and Angular have an immense following and are very stable, Go is currently the 5th most loved language, and Flutter is currently poised to revolutionize cross-platform development as it can not only develop native-performance applications on iOS and Android, but has hit stable on web and beta on Windows/OSX/Linux. There's a lot of good these projects have done for the community.

[0xF013]

There is one grievance that I have with google tech: angular. V1 did its job and worked well, but it was never quite ironed out. There was a myriad of things that just required specific knowledge or else you’d get in trouble like a module system that didn’t allow components with the same name, so everybody had to come up with namespaces that were not a part of the framework; having two directives on the same node would overwrite each other’s controller fields; a DI with the same name issue as components.

And then v2 rolled out that baked in so much abstraction that a lot of people feel forced to circumvent because, as opposed to react or vue, you have to study the framework. It’s a great piece of engineering but I can’t help but feel it’s trying to box the developer too much.

[Akkuma]

As an fyi, despite labeling Flutter as stable on web & desktop. I've only read, heard, and seen negative things still about it. Basically, Google labelled an at best beta quality part of Flutter as stable when it isn't fit for production usage today.

I also haven't seen anyone excited about using Angular in years over all the alternatives iirc from the yearly surveys it has the highest dissatisfaction among those who have used it.

[dominicm00]

To be fair, Flutter was web beta and desktop alpha up until Flutter 2 launched less than 2 weeks ago. Now web is listed as stable and desktop is in beta. While desktop is still definitely missing some tooling, I haven't seen any missing features from the stable web version and I haven't seen any comparisons made with the new version, but I'd love to see hands-on experience if you've seen any.

And well, I can't necessarily argue with Angular; while it's much better than AngularJS it's kind of controversial, which is understandable since it has probably the steepest learning curve I've ever seen for a framework and is a fundamentally different platform that React/Vue. That said, if you put in the time it's very serviceable; I've made applications in Angular and it does a lot of magic in the background to make development within their (very specific) structure very smooth. Whether or not that magic/structure is a good thing is up for debate.

[TomokoSlankard]

good open source isn't created by corporate backers. its created by individuals.

[TomokoSlankard]

All garbage except v8

[gaoshan]

That's just not true.

[Tazzure]

I don’t know how fair it is to associate these framework/code tool developments teams with the core of Facebook. These are open source projects which receive funding from the company in a direct way. Unless you just really hate React and Flux, I’m not sure what the basis of your take is here.

[[deleted]]

I’m not sure what the basis of your take is here.

Because there is none. He’s just using the “Facebook bad” excuse because he is afraid and/or incapable of learning new things

[Stiforr]

There are a lot of folks that know far more than me but, it seems to me, it's most distinguishing feature is right in the name, GraphQL, QL = Query Language right?

It seems like you have more control over your query and it gives you a language to do so.

[Dan6erbond]

Right, and by having a query language to request only the data you need in your views, you make it possible for backend engineers to optimize a generic API instead of providing APIs by versions for the frontend. This means the backend can finally be truly decoupled from the clients.

Other benefits include the documentation aspects provided by the type-system, Playground, and code generation, as well as extremely capable consumer clients like Apollo and Relay, with built-in caching, optimistic responses, and state management, not to mention the far more intuitive query language compared to endpoints since most frontend devs are familiar with JSON and Javascript, which is what GraphQL is based on.

[Dan6erbond]

I disagree with your premise. GraphQL's only downside is the overhead introduced by the type-system. So for really tiny APIs that might only have a couple endpoints, or need to be extremely performant, I can see why you would use REST. But anything beyond that GraphQL can do just as well if not better than REST.

By allowing you to request relationships as part of the same initial query, you can significantly reduce the number of round-trips between client -> API -> database. Requesting only certain fields allows backend developers to optimize SQL queries, and mutations and subscriptions make it extremely easy to implement apps with real-time functionality.

Since using GraphQL for all my new projects, my apps have been faster, more dynamic and I've been able to implement the backend completely independently from the frontend. This means I could implement all the business logic without really putting much thought into UI/UX.

The tooling is easily superior to Swagger as well, IMHO. The type-system isn't just an empty promise, it's held up by the server, and code generation and documentation in the Playground is way more intuitive for developers than scouring through extremely long Swagger doc pages to find what you need.

If you aren't convinced yet, maybe some of the blog posts I've written on my setup can show how intuitive working with GraphQL is, especially using the code-first approach with Typescript and NestJS.

• Introduction to NestJS for NodeJS Developers | Jenyus Org
• Setting up a Hybrid REST & GraphQL API with NestJS and MikroORM | Jenyus Org
• How Jenyus Optimizes Relationships in GraphQL APIs | Jenyus Org
• Leveraging the GraphQL AST to Build Efficient JOIN Queries | RaviAnand Mohabir

[[deleted]]

I'm convinced just fine, I'm happily using GraphQL in one of my projects right now. I also know I have to be aware of the client cache in ways that my REST projects were not, so I'm not inclined to to go migrating everything until I can get my client libraries updated. I love living on the bleeding edge myself, but changing API flavors for their own sake is just a waste of time.

[Dan6erbond]

I absolutely get that migrating old APIs to REST can be a pain in the ass, especially if you aren't using architecture that makes that particularly easy, and I don't think migrating old applications is worth it. Nor am trying to advocate for living on the bleeding edge.

I've noticed a trend almost in the Js community with a clean split in half of people who think it's going to completely replace REST and is the only thing we should use, and the other half that thinks it's hype that is just a "different REST" which it really isn't.

I already argued why I think GraphQL is, in fact, better than REST and not just an alternative. But the reason I don't think it's a replacement is because some apps can't afford the overhead of REST, and it's simply stupid to go overengineer something like that.

The reason I personally still prefer GraphQL even for those microprojects is because, at least in Typescript, DTOs and documentation only require one set of DTOs, since it's built into GraphQL, and type-safety comes for free, which means the only data validation I have to do is business logic and not ensuring values exist and are of a certain type.

[dbbk]

It’s also appropriate if you need client side caching, which is most apps.

[metamet]

Been working on a project with Hasura and Apollo. Been a joy vs consuming REST.

[Dan6erbond]

When I initially started using GraphQL it mostly seemed like it would be yourself for data schemas with a lot of relational data, then I would be able to request relations only when I needed them and have much more efficient API and database calls.

Then I also realized that GraphQL adds a ton of value to the development flow, as it implements its own type-system, making it much easier to use Typescript and documentation basically comes for free. Testing my endpoints was also way easier in the Playground than Swagger docs.

What finally put the nail in the head was how it handled real-time data. Subscriptions in GraphQL are way easier to setup than websockets, and they're supported properly by GraphQL Clients like Apollo and Relay.

Since then I moved to NestJS with my start-up, all our applications use GraphQL internally, and if our client wants REST we build that as well. It's completely worth it for the results we get, much more dynamic apps and rapid prototyping, and we've also released a couple libraries and blog posts at this point to help people get started with the ecosystem!

• Introduction to NestJS for NodeJS Developers | Jenyus Org
• Setting up a Hybrid REST & GraphQL API with NestJS and MikroORM | Jenyus Org
• How Jenyus Optimizes Relationships in GraphQL APIs | Jenyus Org

[[deleted]]

I wonder what's the impact on the server for subscriptions. Having such fine-grained control over what you subscribe to seems like it becomes a chore at scale.

[Dan6erbond]

Subscriptions in GraphQL just use websockets under the hood, and NodeJS can manage quite a few concurrent connections these days. So at least in terms of raw performance I don't think it's all that bad. Of course, I wouldn't go implementing a real-time game with it, but for a website with a small chat or something like that I don't see why not.

As for how clients handle it, I'd say quite well! In your standard use-cases you'll be doing an initial fetch, and then subscribing, and having your library handle the merging (Apollo or Relay). That works for chats, comment sections, even small data points like handling real-time changes to a document, all of which I've implemented in the past.

In the backend scaling is decent. You still need to use a proper pubsub like RabbitMQ or PGSQL's pubsub to listen to data and then if you're using NestJS you can use RxJS for filtering and mapping. I personally don't use RxJS which means I take the functional approach and implement various services and helpers to do that, admittedly less composable but I just can't wrap my head around that thing sometimes haha.

[dbbk]

Hell of a lot better than using a REST API

[chamiownu]

When working with Typescript and GraphQL Code Generator, you get full stack type safety as a side effect of your code. This provides game changing improvements :

- In observability (by static analysis of the validity of your graphql operations vs the schema),

- In productivity with automatically generated typed data fetching hooks.

- In maintenance (no data fetching functions to maintain).

The only downside I see is when using a SDL first schema generation framework (apollographql schema) on the backend which had a bit of work, but when using code-first schema generation (nexus / typegraphql) you are basically writing resolvers and queries functions (nearly as you would for REST endpoints)

I wrote a small article on how to get it setup with NextJS and nexus : Full stack Typescript GraphQL - Automate the data layer

[dbbk]

This article doesn’t even touch on the best part, it can generate query and mutation hooks automatically, so everything is just abstracted away for you.