Hacker News Reader

Comment by dmitriid | Hacker News Reader

> Stop Thinking In Endpoints > How To Start Thinking In Graphs

Ok. I've started to think in graphs. You know. Neo4J, Tinkerpop Gremlin, all that.

Oh, wait. How does that help me create that graph in a sane and meaningful way from a relational database and a number of microservices, especially if all the requests can be ad-hoc graph queries?

Ah, yes. The article (and all other articles on GraphQL) never answer that, do they?

View on HN

My company has built and open-sourced a tool that can turn your ad-hoc graph queries into database queries. We've completely abandoned GraphQL's resolver-based execution model, and we simply turn the GraphQL directly into a database query and run it on the database itself.

Check out our blog post: https://blog.kensho.com/compiled-graphql-as-a-database-query...

Open-sourced tool: https://github.com/kensho-technologies/graphql-compiler

    pip install graphql-compiler

Yeah, IMO GraphQL is not at all hard to grok, and its benefits to an API consumer are pretty obvious. But I have no idea, as a developer, how I'm supposed to implement a GraphQL interface to my non-graphical database(s) in a secure, performant, and repeatable way.

I propose that if you have tables and want graphs, you will have to consider the tradeoff in compute resources required to generate meaningful aggregate results (count all customers, etc). So the answer is usually keep your tables and use graphs when appropriate.

There are really elegant solutions coming out around this - I suggest watching some of the talks from this years GraphQL summit.

You build a "query language" that translates the GraphQL into a series of calls to your nanoservices ?

Why would I want to do that though? :)

It's quite an undertaking, increases the surface of bugs and attacks etc.

We refer to them as picoservices, but yes.

Reply on news.ycombinator.com