Multiple clients of the same server - how to refactor while keeping the benefits of current architecture?

Question

Background

I have a system that comprises of 3 components:

• a web application that displays data and allows data manipulation by users (React)

• a server application which serves the data to the web application and handles the manipulation requests (Node)

• a command line application which builds said data (it takes input from the user, builds the data structures and sends them to the backend to be saved) (Python)

The e2e flow typically looks like this:

1. I start the command line application and it uses the input I give (may be a file) to construct the data structure and send it to the server application

2. The server then saves it into a database

3. I then open up the web app to visualise the data, it fetches it from the server

4. I may want to modify some parts of the data using the web app, if I do a modification the web app will update its own version of the data structure locally (in memory)

5.a. If I want to save the edits I press on a Save button and the changes are sent to the server

5.b. In some other cases the changes are sent automatically (they are also applied locally, in memory)

Problem

There is a lot of commonality between the way the data structure is firstly built and the way it can be modified by the user. These common operations range from simple to very complex so there is severe code duplication between the command line app and the web app. I'm worried that I won't be able to keep them fully in sync (and I had issues caused by this before).

Solution

The obvious solution seems to me to move all the common functionality inside the server application.

Problems with this solution

I am worried about the case when a user tries to do a modification via the web app.

Currently what we do is we apply that modification in the web app itself first then we subsequently send the updated data structure to the server to be saved. The benefit with that is the user instantly sees the updates being applied. The drawback is if the update cannot be persisted for some reason, the user either still sees the updates being applied (before they refresh) or they see the update being rolled back. In my case, the benefit outweighs the drawback so I'd like to keep it this way.

But if we move the code that actually does the update to the server app, the web app will have to wait until the request is completed before it can display the update to the user (correct me if I'm wrong). Since that update can be a very complex one (and the data itself is very complex, we have graph and tree structures), it can potentially take a long time.

Questions

1. Is the obvious solution the most appropriate one? Are there other ways to avoid that kind of duplication?
2. If this is the solution, is there any way I can improve upon this solution or will I just have to live with it?

Answer 1

Here is a different idea which might work for you. Instead of moving the code to the server,

• isolate the code in the web app you want to reuse from the command line application and put it into a Javascript module

• make that module callable from your command line app and reuse it there directly.

The second step is probably the hard part. You could either do this by rewriting the command line app completely in Javascript / node.js, or by using something like python-bond or PyV8.

(Disclaimer: I haven't tried this by myself).

See also: Executing Javascript from Python (on Stackoverflow)