5 ms·

Show HN: Generating GraphQL servers for Go

172 points by vektah 9y ago

Blackstone4 9y ago
Background: I've been using Typescript + graphql-yoga/apollo-server/express + Prisma to create a GraphQL server. I'm not familiar with golang. I found this interesting. So just to check my understanding, does this auto generate the routing for the incoming GraphQL queries and mutations? Then you implement the resolvers / db components?
- Blackstone4 9y ago
  I'm also interested in hearing your thoughts on the maturity of the golang GraphQL ecosystem? I've mostly been looking at the JS space and there's a lot of tooling. Having said that my experience has been that it's easy to write a simple GraphQL server but it gets complicated fast. I've been using Prisma which does a lot of the heavy lifting for you. It's relatively new so does come with trade-offs.
  - sebastian 9y ago
    Check out https://dgraph.io/ https://dgraph.io/ . I haven't had the chance to use it yet, but I have been following its development for a while. Definitely worth looking into.
    - Blackstone4 9y ago
      Looks interesting. Shame the syntax is GraphQL-like but not pure GraphQL.
      - Blackstone4 9y ago
        Looks like GraphQL compatibility is on the roadmap for 2018 https://github.com/dgraph-io/dgraph/issues/1966 https://github.com/dgraph-io/dgraph/issues/1966
  - vektah 9y ago
    I think its still pretty early days, the easy stuff is fine. Once you throw in data loading or subscriptions you quickly run out of docs or find that its just flat out unsupported. I'm hoping to change that though :)
- thangngoc89 9y ago
  This only generates the server and you need to write your own resolvers, connect to database, ... Prisma on the other hand handle everything out of the box for you.
  - vektah 9y ago
    Yeah, would be more for existing apps that already have a bunch of domain logic.
  - Blackstone4 9y ago
    Thanks. Yeah that's what I thought. On Prisma, I have a graphql-yoga server which sits in front of Prisma. My server has its own schema and api and it handles auth, permissions and business logic
- vektah 9y ago
  Yeah, it takes your schema and your models and generates as much of the resolver graph as it can, then leaves you with an interface to implement for the bits it cant (usually trips back to the db).
sorenbs 9y ago
This is super cool. It looks very similar to graphql-binding https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding GraphQL Bindings are generated from a GraphQL schema and provides static typing in various languages. Right now code-gen for typescript is supported. Scroll down a bit on https://www.prismagraphql.com/ https://www.prismagraphql.com/ for a short video demonstrating how this works in practice. I'm very happy that more projects are exploring code-gen for GraphQL.
faizshah 9y ago
Not to derail the discussion, but I just got started using GraphQL myself. I've been using Apollo and just started looking at Graphcool. I was wondering if anyone knows of an offline first solution for GraphQL on mobile (ios and android, native or nativescript compatible)? I was hoping to use Apollo on all platforms but it seems I would need to use a custom solution for mobile while on web there's some choices (for offline first): https://github.com/apollographql/apollo-cache-asyncstorage/issues/6 https://github.com/apollographql/apollo-cache-asyncstorage/i... Currently I'm planning to go with couchdb/couchbase-lite for mobile but I would prefer a graphql solution. I'm also investigating AWS AppSync which appears to have offline support, but I haven't read that deeply into it yet: https://aws.amazon.com/appsync/ https://aws.amazon.com/appsync/
- sorenbs 9y ago
  It is my understanding that AppSync doesn't really support offline first yet. I would encourage you to keep an eye on efforts by the community such as Apollo repo you linked or the Khan Academy project mentioned in it. If you need something _now_ you are probably better of looking outisde the GraphQL ecosystem though. You should also consider what your need is. If you need true offline support (ie, you have an app that needs to fully function for days without internet) then that is a very different scenario from just needing to have a bit of data cached for the duration of a subway ride.
  - faizshah 9y ago
    Thanks for the info, I just need to allow the client to queue up mutations offline (duration of a subway ride) and then notify the user visually of merge conflicts when we are back online. I don't need true offline support or live collaboration, just a very soft eventual consistency. I just don't want to worry about this while I'm working on core features for launch so I would like a premade solution.
- realPubkey 9y ago
  Hi faizshah. I created RxDB ( https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb ), an offline-first-database (javascript) which works for your requirements, but only with the couchdb-stack. I did many attempts to create a graphQL-plugin which streams graphql-data into an the offline-first store. But this is not completely solvable because of the lacking graphQL-streaming-capabilities. The thing is, when the users goes offline for an hour an then online again, there is no way to get the changes of the last hour out of graphQL which means the user then would either have missing updates or has to redownload the full state again. The current streaming-api of graphQL requires a stable connection and is so not useable for offline-first.
013a 9y ago
I feel that, in typed languages, the only GraphQL oriented code you should be writing is the schemas and the resolvers. Manually implementing the models in your language's type system seems unnecessary and is a recipe for mistakes and drift between the schemas and those types.
- wyattjoh 9y ago
  How would you represent more complex types? It would work fine if your models are flat and containing only POD, but if it contains something like GeoJSON (from Postgres for example), it would be pretty difficult to ensure that the serialization works properly.
  - 013a 9y ago
    I'd imagine any decent library would provide an escape hatch around the codegen, so you can specify your own types if you'd like. The other option is to only write the Go types, then use codegen to generate the GraphQL schemas. In a way, I prefer this because it keeps everything in the same language, using all of the great tooling Go has. There is some prior art for this; the Juniper [1] Rust library. [1] https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper
    - sorenbs 9y ago
      It's worth keeping in mind that GraphQL often finds itself in organisations that use multiple languages. A trend we have seen starting to emerge over the last 6 months is that backend teams write core business logic in languages like Java or Python and want to expose this as GraphQL microservices. Then you either have a central team responsible for the public GraphQL API. They will typically write a server in Javascript that composes all the microservices. Or alternatively you have multiple product teams that all want separate GraphQL APIs tailored to their use case. They too typically use Javascript for the server. When multiple languages are involved it turns out to be really useful to be able to use GraphQL SDL as the canonical representation and use code-gen on each stack. This is the use case GraphQL binding is intended for: https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding
akmittal 9y ago
Is it production ready?

172 points by vektah 9y ago

Background: I've been using Typescript + graphql-yoga/apollo-server/express + Prisma to create a GraphQL server. I'm not familiar with golang. I found this interesting. So just to check my understanding, does this auto generate the routing for the incoming GraphQL queries and mutations? Then you implement the resolvers / db components?

Blackstone4 9y ago
I'm also interested in hearing your thoughts on the maturity of the golang GraphQL ecosystem? I've mostly been looking at the JS space and there's a lot of tooling. Having said that my experience has been that it's easy to write a simple GraphQL server but it gets complicated fast. I've been using Prisma which does a lot of the heavy lifting for you. It's relatively new so does come with trade-offs.
- sebastian 9y ago
  Check out https://dgraph.io/ https://dgraph.io/ . I haven't had the chance to use it yet, but I have been following its development for a while. Definitely worth looking into.
  - Blackstone4 9y ago
    Looks interesting. Shame the syntax is GraphQL-like but not pure GraphQL.
    - Blackstone4 9y ago
      Looks like GraphQL compatibility is on the roadmap for 2018 https://github.com/dgraph-io/dgraph/issues/1966 https://github.com/dgraph-io/dgraph/issues/1966
- vektah 9y ago
  I think its still pretty early days, the easy stuff is fine. Once you throw in data loading or subscriptions you quickly run out of docs or find that its just flat out unsupported. I'm hoping to change that though :)
thangngoc89 9y ago
This only generates the server and you need to write your own resolvers, connect to database, ... Prisma on the other hand handle everything out of the box for you.
- vektah 9y ago
  Yeah, would be more for existing apps that already have a bunch of domain logic.
- Blackstone4 9y ago
  Thanks. Yeah that's what I thought. On Prisma, I have a graphql-yoga server which sits in front of Prisma. My server has its own schema and api and it handles auth, permissions and business logic
vektah 9y ago
Yeah, it takes your schema and your models and generates as much of the resolver graph as it can, then leaves you with an interface to implement for the bits it cant (usually trips back to the db).

sorenbs 9y ago

This is super cool. It looks very similar to graphql-binding https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding GraphQL Bindings are generated from a GraphQL schema and provides static typing in various languages. Right now code-gen for typescript is supported. Scroll down a bit on https://www.prismagraphql.com/ https://www.prismagraphql.com/ for a short video demonstrating how this works in practice. I'm very happy that more projects are exploring code-gen for GraphQL.

faizshah 9y ago

Not to derail the discussion, but I just got started using GraphQL myself. I've been using Apollo and just started looking at Graphcool. I was wondering if anyone knows of an offline first solution for GraphQL on mobile (ios and android, native or nativescript compatible)? I was hoping to use Apollo on all platforms but it seems I would need to use a custom solution for mobile while on web there's some choices (for offline first): https://github.com/apollographql/apollo-cache-asyncstorage/issues/6 https://github.com/apollographql/apollo-cache-asyncstorage/i... Currently I'm planning to go with couchdb/couchbase-lite for mobile but I would prefer a graphql solution. I'm also investigating AWS AppSync which appears to have offline support, but I haven't read that deeply into it yet: https://aws.amazon.com/appsync/ https://aws.amazon.com/appsync/

sorenbs 9y ago
It is my understanding that AppSync doesn't really support offline first yet. I would encourage you to keep an eye on efforts by the community such as Apollo repo you linked or the Khan Academy project mentioned in it. If you need something _now_ you are probably better of looking outisde the GraphQL ecosystem though. You should also consider what your need is. If you need true offline support (ie, you have an app that needs to fully function for days without internet) then that is a very different scenario from just needing to have a bit of data cached for the duration of a subway ride.
- faizshah 9y ago
  Thanks for the info, I just need to allow the client to queue up mutations offline (duration of a subway ride) and then notify the user visually of merge conflicts when we are back online. I don't need true offline support or live collaboration, just a very soft eventual consistency. I just don't want to worry about this while I'm working on core features for launch so I would like a premade solution.
realPubkey 9y ago
Hi faizshah. I created RxDB ( https://github.com/pubkey/rxdb https://github.com/pubkey/rxdb ), an offline-first-database (javascript) which works for your requirements, but only with the couchdb-stack. I did many attempts to create a graphQL-plugin which streams graphql-data into an the offline-first store. But this is not completely solvable because of the lacking graphQL-streaming-capabilities. The thing is, when the users goes offline for an hour an then online again, there is no way to get the changes of the last hour out of graphQL which means the user then would either have missing updates or has to redownload the full state again. The current streaming-api of graphQL requires a stable connection and is so not useable for offline-first.

013a 9y ago

I feel that, in typed languages, the only GraphQL oriented code you should be writing is the schemas and the resolvers. Manually implementing the models in your language's type system seems unnecessary and is a recipe for mistakes and drift between the schemas and those types.

wyattjoh 9y ago
How would you represent more complex types? It would work fine if your models are flat and containing only POD, but if it contains something like GeoJSON (from Postgres for example), it would be pretty difficult to ensure that the serialization works properly.
- 013a 9y ago
  I'd imagine any decent library would provide an escape hatch around the codegen, so you can specify your own types if you'd like. The other option is to only write the Go types, then use codegen to generate the GraphQL schemas. In a way, I prefer this because it keeps everything in the same language, using all of the great tooling Go has. There is some prior art for this; the Juniper [1] Rust library. [1] https://github.com/graphql-rust/juniper https://github.com/graphql-rust/juniper
  - sorenbs 9y ago
    It's worth keeping in mind that GraphQL often finds itself in organisations that use multiple languages. A trend we have seen starting to emerge over the last 6 months is that backend teams write core business logic in languages like Java or Python and want to expose this as GraphQL microservices. Then you either have a central team responsible for the public GraphQL API. They will typically write a server in Javascript that composes all the microservices. Or alternatively you have multiple product teams that all want separate GraphQL APIs tailored to their use case. They too typically use Javascript for the server. When multiple languages are involved it turns out to be really useful to be able to use GraphQL SDL as the canonical representation and use code-gen on each stack. This is the use case GraphQL binding is intended for: https://github.com/graphql-binding/graphql-binding https://github.com/graphql-binding/graphql-binding

akmittal 9y ago

Is it production ready?