Restagraph - yes, another HTTP API framework for Neo4j

Projects & Collaboration
1

So, I built a thing... actually a couple of things.

Restagraph is an engine that puts an HTTP API in front of Neo4j, and enforces a user-defined schema on the incoming data. The schema is stored in the database and loaded by the appserver on startup, there's an API for uploading a schema, and the whole thing's designed to be deployed via Docker.

Why release this now that there's a GraphQL equivalent? Because GraphQL carries legacy relational thinking, and this one thinks in property-graphs. The key difference, which prevented me abandoning this work, is that GraphQL only allows one type of target resource for a given relationship. In Restagraph, you can define a LOCATION relationship to a city, a building or a conference room in a hotel.

It's currently at alpha-level maturity: most of the functionality is there and working, but I have a lot of work to do around hardening it and expanding the test suites, and then fixing the bugs that the expanded test-suites reveal.

The name came from me aiming to put a REST interface on a graph database. The API is now somewhere between that and GraphQL, so the name is just as apt but for different reasons. It's also a dorky name, but naming things just isn't one of my strong points.

I said "a couple of things." Syscat is the original project; Restagraph just naturally emerged as an engine with its own separate existence, and now Syscat's just Restagraph plus a custom schema. It's yet another IT environment database, but this one captures everything- from spare parts to org-charts. It's also designed explicitly to be multi-organisation, so you can track this virtual circuit through those ISPs to that data centre (which is operated within Company X's infrastructure) with whatever level of detail you have on hand.

I'm a former sysadmin and network engineer, and Syscat benefits from many lessons learned from the various products I've used over the years. One of those lessons was to separate what is from what should be, and another is to make sure user extensions to the schema and API are first-class, not gaffer-taped onto the side.

Its documentation is way behind at the moment. It has a big and complicated schema, which requires a gentle introduction. However, it seemed foolish to introduce Restagraph without mentioning its raison d'etre.

If anybody's interested in taking either of them for a spin, you can find Docker images for Restagraph as well as images for Syscat. I'd be delighted to get constructive feedback about either project, whether here or via issues on Github.

1 Like
2

Seems like a cool project - I think the readme could benefit with an example or a gif of usage for the movies db that everyone starts with. I know there's a demo section on there, but I think most people want to see something before they start spinning up containers and doing requests, etc. I think that could help people get a better idea of what they're getting out of it and if it's something that could be helpful on their projects.

3

Thanks!
It's kinda hard to get visual with an API, but that's a good point; I'll try to lead with a more illustrative example.

4

I've updated the README and a few other things*, and the docs are now a little more readable at Github pages. It's now at version 0.7.0, and more of a beta than an alpha.

The docs are a little more fleshed out in general, and follow the standard Neo4j Movies dataset, to make it easier to follow along for people already familiar with demos based on that.

For anybody wondering where this is going in future, the next major feature on the roadmap is adding authentication and authorisation. It's going to take a while to implement that in a way that I'd trust to be exposed to the internet.

*A few other things like re-architecting the engine to put the schema back inside the database, making the whole thing more robust against unexpected requests, minor tweaks like that.