graphql-go VS dgraph

I'm not sure if I'm going to stop supporting anything outside of int32 and float64 as that was one of my biggest frustrations when using graphql-go.

I have always preferred https://github.com/graph-gophers/graphql-go. I still write my definitions in .graphql files and pese them with the library. Then you can easily write resolvers or just return model objects if they match the definitions.

For my current project we use ent (https://entgo.it) + gqlgen and its a really nice combo. As well as the two other popular graphql libraries for go (https://github.com/graphql-go/graphql and https://github.com/graph-gophers/graphql-go), I’ve also kept my eyes on graphjin (https://github.com/dosco/graphjin) and thunder (https://github.com/samsarahq/thunder) but to me there is no reason to not use ent with gqlgen - it’s just so nice :)

Dgraph: A distributed and scalable graph database known for high performance. It's a good fit for large-scale graph processing, offering a GraphQL-like query language and gRPC API support.

Dgraph (GraphQL, DQL)

Have you tried dgraph.io?

DGraph – A distributed GraphQL database with a graph backend.

How does it compare to, say grakn (renamed https://vaticle.com/, I think?), or draph (https://dgraph.io/), or Ontotext's GraphDB (https://www.ontotext.com/products/graphdb/), or Datomic?

Consul Connect service mesh has a higher memory footprint, so on a small cluster with e5-medium nodes (2 vCPUs, 4 GB memory), you will only be able to support a maximum of 6 side-car proxies. In order to get an application like Dgraph working, which will have 6 nodes (3 Dgraph Alpha pods and 3 Dgraph Zero pods) for high availability along with at least one client, a larger footprint with more robust Kubernetes worker nodes were required.