> Are you using an actual GraphDB like Neo4J? Are you putting a graph frontend on Postgres like PostGraphQL? None of the post really makes any sense because GraphQL is a Query Language, not a data store. What are the CAP theorem tradeoffs in the new backend? What does more robust mean? What does more performant mean? This is a source control app. Those tradeoffs are meaningful.
GraphQL isn't particularly "graphy". Its name sucks. But don't worry, plenty of half-techy middle managers are out there making the same mistake and going "we do graph things, why don't you guys look into this GraphQL thing that's getting so much buzz?" It's not a great fit for graph operations, in fact. Not more than SQL, certainly.
As for N4J in particular, don't count on that to improve performance even if you're doing lots of graph stuff. Depends heavily on your usage patterns and it's very easy to modify a query in a way that seems like it'd be fine but in fact makes performance fall off a cliff. OTOH Cypher, unlike GraphQL, is a very nice language for querying graphs.
GraphQL isn't particularly "graphy". Its name sucks. But don't worry, plenty of half-techy middle managers are out there making the same mistake and going "we do graph things, why don't you guys look into this GraphQL thing that's getting so much buzz?" It's not a great fit for graph operations, in fact. Not more than SQL, certainly.
As for N4J in particular, don't count on that to improve performance even if you're doing lots of graph stuff. Depends heavily on your usage patterns and it's very easy to modify a query in a way that seems like it'd be fine but in fact makes performance fall off a cliff. OTOH Cypher, unlike GraphQL, is a very nice language for querying graphs.