Advice regarding data syncing between SPA frontend and backend API

Hello everyone,

I wanted advice for how to go about implementing syncing data between a single page application(SPA) frontend and a backend API, which would then query the Neo4j database as required (using Bolt API).

My question is about data syncing. When the client(SPA) requires information, it does an API call asking for the resources, and it gets a JSON as output. My question is this: When changes are made locally (in the client side; with changes made to the JSON), how to reflect the same in the database?
Is there a simple way to do this? The best I could think of is: recording the changes in a format (e.g. given an object with key 2e4r3f, changes would be like: "favourited 2e4r3f", "modified 2e4r3f 'text it is now' ") and send those to the backend. What would you guys do?

Another question I have is about offline-functionality. This is an optional requirement, but I would love advice about this as well. If a user has opened up some pages when they are connected to the internet, I would like for them to be able to work on the pages even when they are offline. When the user later connects to the internet, these changes would need to be synced with the database.
For this, I was thinking of storing and managing the pages in a state management store (like Vuex, Redux). I do not particularly like this approach as I would have to rewrite what essentially could be done as Cypher queries to javascript. Do you guys have any ideas?
While searching for sth like this, I came upon Datascript which does this for Datalog. Is there a similar community project for Neo4j I could look at?

If it helps, I'm looking into VueJS as frontend, and FastAPI for the API.


P.S. My earlier question with regards to general advice relating to this project: General Advice for building a SPA in Neo4j

On the graphing stuff; there are a few alternatives listed at

1 Like

Hello Sameer
Thank you for the reply. But I hadn't asked about graphs in this post. Maybe you meant to reply in my previous post?

@baibhavbista Another question I have is about offline-functionality.
I was trying point to various alternatives you can explore for that kind of functionality.

I’m developing a SPA in Elm with a Neo4j backend, which will also be talking to Elixir and various command line utilities. To keep Neo4j as the “single source of truth”, I’m using GraphQL as “middleware” with GRANDstack (without React). I’m strictly using queries and mutations to read and write to Neo4j so that the schema is strongly-typed.

I haven’t explored offline yet. Whatever route you take, you’re going have to deal with conflict resolution. (An approach I’m considering is CQRS/Event-Sourcing, to abstract the intent of the changes.) Any decision you make is going to depend a lot on your specific use case.

I’m not familiar with Datalog.


Hello Sameer,
That sounds interesting. Can you elaborate? I don't get the relation between graph visualization tools and offline functionality?

Thank you Stephen! I will look into that possibility as well.

Hello Stephen,
I had looked into GRANDstack before too, but had not thought of it as an option as my team is set on using Vue. However, your answer made me realize that I hadn't explored that option fully, and that it was a possibility that React may not be necessary. I am currently looking into this stack and will probably use it, replacing react with VueJS (Apollo solves 50% of the problems I was mulling over). Thank you for giving me that insight.
I would love if you could give me more details about the architecture of the system you're building, as well as any pain points you might have had while working with a non-React frontend.

If you treat your GraphQL schema as the source of truth for your data architecture then you’re free to choose any stack on the client side and any stack on the server side.

Its like building a bridge by starting at the middle, guaranteeing that the two ends will meet. And you may wish to have multiple clients (for mobile, web, etc), all agreeing on the same central schema document.

Your schema is acting as a guarantor, or contract, for your whole stack. It can be a gatekeeper for your data, ensuring that the schema-less Neo4j is “type-safe” if you only change data through GraphQL mutations.

I guess because Neo4j is a niche technology, GRANDstack chose to piggyback on React to make it seem more relevant. But that doesn’t mean there aren’t better suited (or equally good) frontend stacks you can replace it with. If you’re most comfortable with Vue, use it.

My stack is the GRANDEstack where the E stands for Elm. Each time I change the schema, I run a code generation tool that writes thousands of lines of Elm for me so that I can work in a type-safe environment.

One advantage of code generation (and there are options for Typescript, and perhaps others frontend languages and/or frameworks) is that it encourages you to use more explicit schema designs with enums and scalars.

For example, if I have a Movie type, then I define the custom scalar MovieId, which I can use throughout my Elm code. If I use it in place of ActorId, my code won’t compile. Similarly, I make extensive use of enum definitions in my schema to limit options.

For now, I’m in prototyping phase so I’m running the whole stack on my laptop. The GRANDstack sample code has good integration with Netlify so you can test it in production (with your data in a 72-hour Neo4j Sandbox and your GraphQL server deployed by Netlify as cloud-hosted lambdas).

I haven’t encountered any pain points by avoiding React, and likely avoided some. I’m thinking of rewriting the official GRANDstack starter projects in Elm so that one can draw pro and con comparisons with React.

Thanks for the help
I am looking into modifying GRAND stack as well. Thanks for your help!
Would appreciate if you could share any good resources about graphql-first development, particularly those using apollo and neo4j. I finished the completed chapters of GRANDstack book and am currently going through Will Lyon's twitch series.

1 Like

I think the book could be improved with a more opinionated style, or even with sidebars that go into more detail on best practices, but I’m still grateful that it exists. For now, the best documentation is the excellent website, the starter kit, and the first episode of that Twitch series.

In terms of schema-first advice, that’s means trusting in your schema. So using the full expressiveness of the schema language (and cypher statements), with enums custom scalars and perhaps unions. (I haven’t personally used unions yet.) Choose a frontend GraphQL library that has built in support for them.

And make the migration of your schema central to your development process. When you have custom queries and custom mutations in your schema, you’ll want to write tests that they are still correct after changing the schema. And even if just using using the autogenerated resolvers, you’ll want to write migrations for your data so that your Neo4j database reflects the new schema document.

1 Like