5 ms·

I was very interested about build a fullstack GraphQL system, but early on, I've got the feeling that if you are using a strongly typed language, which has its

by isoos 8y ago

I was very interested about build a fullstack GraphQL system, but early on, I've got the feeling that if you are using a strongly typed language, which has its proper data binding layers (to the DB or to the UI components), then there are very little benefits of using GraphQL. Could somebody share their thought on that? I mean, I get that react(-like) UI frameworks or node.js servers are happy using it, as this is their version of creating a "narrow" interface. However most platforms do support powerful type-to-serialization mappings through either reflection or code generation. We can create "narrow" interfaces easily, and these can be used with much less hassle than GraphQL. Can somebody share their story if/when GraphQL were beneficial with a strongly typed language?

adamkl 8y ago
We've actually gone the opposite direction. We start with our GraphQL schema and then generate TypeScript types off of that schema. This is something that's often done on the client side, but we do it on the server side. With those, we get type safety on input arguments, and can make sure that our data access layer maps from back-end data sources to our output GraphQL types.
- ex3ndr 8y ago
  Can you share what exactly you are generating for server? Asking for a friend :)
  - adamkl 8y ago
    We actually built an internal tool (shamelessly called create-graphql-service) that scaffolds a new graphql service and includes generation of TypeScript types as part of the build process [1]. [1] https://gist.github.com/adamkl/27539b3a8129f23e3576bfc37b3ea235 https://gist.github.com/adamkl/27539b3a8129f23e3576bfc37b3ea...
waterfoul 8y ago
It's really helpful when you have many desperate systems which all hit the same API in different ways. We've built a more custom solution to hit some existing databases and this style of system will be reducing the need for as much custom c# code on each back end. It's also SUPER useful because it will auto-gen the types for our api calls and we no longer have to hand write them. I do see your point though, for existing apps which alreayd have the infrastructure in place this style of system is not as helpful, it's mostly geared at new development and common apis
- isoos 8y ago
  There are many ways that one can define a custom, narrow interface for a service, and automatically generate client code, server stub, and for many cases even database access codes. GraphQL is one of them, it may be one of the not-too-lame ones, but for most practical purposes, it doesn't seem to be clearly better than the average toolkit.

by isoos 8y ago

adamkl 8y ago

We've actually gone the opposite direction. We start with our GraphQL schema and then generate TypeScript types off of that schema. This is something that's often done on the client side, but we do it on the server side. With those, we get type safety on input arguments, and can make sure that our data access layer maps from back-end data sources to our output GraphQL types.

ex3ndr 8y ago
Can you share what exactly you are generating for server? Asking for a friend :)
- adamkl 8y ago
  We actually built an internal tool (shamelessly called create-graphql-service) that scaffolds a new graphql service and includes generation of TypeScript types as part of the build process [1]. [1] https://gist.github.com/adamkl/27539b3a8129f23e3576bfc37b3ea235 https://gist.github.com/adamkl/27539b3a8129f23e3576bfc37b3ea...

waterfoul 8y ago

It's really helpful when you have many desperate systems which all hit the same API in different ways. We've built a more custom solution to hit some existing databases and this style of system will be reducing the need for as much custom c# code on each back end. It's also SUPER useful because it will auto-gen the types for our api calls and we no longer have to hand write them. I do see your point though, for existing apps which alreayd have the infrastructure in place this style of system is not as helpful, it's mostly geared at new development and common apis

isoos 8y ago
There are many ways that one can define a custom, narrow interface for a service, and automatically generate client code, server stub, and for many cases even database access codes. GraphQL is one of them, it may be one of the not-too-lame ones, but for most practical purposes, it doesn't seem to be clearly better than the average toolkit.