Where to keep the business logic for a data analysis web app with lot of user interaction

Question

I am trying to create a web app in which:

• The user is shown a table (call it table0) on the browser with rows (around 1000-1500 rows) and a few (5-6) columns.
• Depending on the data in the table0, 3-4 new tables are created based on some business logic.
• The user makes some changes (adding rows, deleting rows, changing existing row values for certain columns) on table0 only. Here the changes made by the user can be many in number and the corresponding changes must be reflected in all the subsequent (generated)tables dynamically (so as soon as he makes some changes in table0, he must immediately be able to see the updated version of new tables).

Previously I was thinking to keep the business logic (how the new tables are obtained from table0) in the backend and whenever the user changes anything in UI, an API call is made to the backend with all table0 data, and backend generates the new tables and returns them back to UI.

The main requirement is that after every change made by the user to table0, the user would like to see how the new (generated) tables look like, Thus (in the current approach) causing all of table0 data to be transferred to backend a lot of times over the network which I THINK will make it slow and not very dynamic. Also in the future, the number of rows may increase and alleviate this problem even more.

So, I was thinking of moving the business logic to the front end, but everywhere I read on the net I find people advising to keep business logic in the backend. So is there any better solution to this problem?

Answer 1

There are no silver bullets here. What you are dealing with is a trade-off between availability and consistency .

If consistency is more important:

• When a user finishes editing the main table, you do a request with the changes to the backend. The backend would then update the main table and the generated tables. The backend then return 200 Ok to the frontend client.
• The frontend waits, and after receiving 200 Ok from the previous request, it gets the updated generated tables from the backend via additional requests (this can be optimized based on your business logic).
• If your persistence requirements allow it, take a look at materialized views for creating and maintaining the generated tables.
• Main drawback is that this approach is slower.

If availability is more important:

• When a user finishes editing the main table, you do requests with the changes to the backend. The backend proceeds with the updating logic.
• You do not block on the fronted and wait for a 200 Ok from the backend, but manually update the generated tables in the frontend.
• This approach works fine as much as the first request to the backend does not fail. If that request fails, your frontend will display inconsistent data.
• Another drawback of this approach would be that business logic would lurk into the frontend, and most likely will end up duplicated on the backend as well.
• This approach would result in a better user experience.