While this is cool, in theory, I haven't found it to be in practice. If it's an internal API, you can just provide a way for the client to get exactly what they need in a single query. If it's an external API, you have to deal with putting limits in place to keep users from burdening the system with complicated requests. Limits can become complex very quickly.
I am wondering why not build on top of their Http Api? You can send multiple Cypher statements over Http and correct me if I am totally wrong, but "stealing" the concept of graphql's persistent queries, you could make use of http caching also.
I would love read your thought's on that
Anyways... my basic POC was exposing endpoints so I can do things like.
/devices/list /network/shortestPath?node1=<>&node2=<>
to get a list of all devices but I'm basically just writing custom Cipher code to do that query and the benefits of Neo4J basically go out the door. It still has some interesting Graph features but if all i'm doing is writing a custom endpoint for every use case it's mainly pointless.
You can do a simple POST statement which takes a Neo4J query and execute it with some caching on top of it for sure.
Either ways in order to make Neo4J worth it I need a way to make the queries more dynamic. So right now I'm thinking of:
- restQL http://restql.b2w.io/ - GraphQL https://graphql.org/
Or just having a dumb POST /custom/query that maybe only supports read operations. You can add a layer of auth but I'm not a big fan of just having some endpoint that's basically a Pipe to Neo4j. It feels just as bad as saying, typing any SQL here and we'll execute it on the server. If people know what they're doing that's fine..but at that point just setup phpMyAdmin/ pgAdmin. At that point you're trusting folks to know what they're doing and if folks accidently drop Bobby Tables (https://xkcd.com/327/) then it's an accepted risk.
If you just have a proxy to run any Cipher query, you might as well just provide users on Neo4J web instance and let them play there.
Anyways, still in early stages trying to figure out how to best leverage Neo4J
I didn't know Restql. thanks for the link
Some flags for helpers that fetch additional data would be good.
(Aka. identified the foreign keys and primary keys linked them together and made all other fields options)
Things I don't like about GraphQL (In Java which was my experience)
1. Debugging it is annoying. There's no clear concise way to follow the code there seems to be some magic that happens where it isn't clear when certain parts of the code get invoked.
Things I like about it.
1. Lets you make multiple queries and reduce/extend the size of your payload as needed.
In my view graphQL is much better when you're not constrained by a SQL like backend. It's great at filtering the payloads which is great for mobile and such. It also allows you make multiple calls in one go which also means you can shoot yourself in the foot if you over do it.
I will call out that some of this is trauma based from my last experience. Having a more dynamic language that isn't Java may make the experience better but in general everytime we had to update the GraphQL code it was cringy.
Eventually started to gut the dynamic SQL and replacing it with a simple Query and then used GraphQL and trim the response which worked out much better.
Generally the question to ask is how many iterations of an endpoint do you need and is it worth introducing a new technology vs just having a few query parameters to do some filtering.
That being said, I'm now looking at some Query language to work with Neo4J so I'm back at looking at dynamic APIs. (: