Show HN: Generating GraphQL servers for Go

[faizshah]

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/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/

[realPubkey]

Hi faizshah. I created 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.

[sorenbs]

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.

[orbitur]

When you say "offline first" do you just mean "local db"? You'd rather use GQL over SQL or some other query lang?

[013a]

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.

[theswan]

At Samsara our golang graphql implementation (https://github.com/samsarahq/thunder) works this way. We write out resolver functions using plain old go types and use some reflection magic at startup to compute the graphql type information.

Our docs are a bit spare at the moment, but this means with code like:

  type User struct {
    Id int64
    Name string
  }

  func rootUser(ctx context.Context, args struct { id int64 }) (*User, error) {
    // ...
  }

  schemaRoot.FieldFunc("user", rootUser);

We can derive the graphql SDL types automatically (looking at the arguments and return values) and use them with other graphql tooling, but it saves folks time from writing out a separate schema and keeping it in sync.

[a-saleh]

I think I would rather write types and derive schemas. Not sure if it were possible to derive resolvers?

[wyattjoh]

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.

[vektah]

graphql is just one representation of your applications data, it shouldn't dictate your models.

I'm thinking about adding something that generates a model if it doesn't exist, but after its generated it becomes the users problem to keep it in sync.

> recipe for mistakes and drift between the schemas and those types.

The type system enforces there is no drift, it won't compile if its not perfect.

[sorenbs]

This is super cool. It looks very similar to 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/ for a short video demonstrating how this works in practice.

I'm very happy that more projects are exploring code-gen for GraphQL.

[Blackstone4]

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]

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.

[vektah]

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).

[thangngoc89]

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.

[akmittal]

Is it production ready?