Math calculations - backend or frontend-CodePudding

I am creating a web application(Django Angular) whose main purpose is to draw shapes. I calculate and draw all the shapes myself. Where is it better to do the calculations (calculating line equations, finding common points)- on the backend and ask the server or on the frontend?

Thanks

CodePudding user response：

It's better that you move calculation pressure from server to client. If you want to do calculations, you should make an ajax service and do inside calculations that are just used for only one client. But if you do it on the client-side the CPU usage and ram usage of the calculations is moved to the client-side and it's not very heavy for it.

Except if the calculation is heavy for your client browser or you want to protect calculation methods!

CodePudding user response：

It's always a trade off. I've been working on this exact architecture for years now (Django Angular) building olap applications with potentially heavy data manipulations and computing. I've used the back or the front or both. Note that in my case, the potential workload for the server wasn't really heave as it was professional applications used by 5 people at the same time at peek hour.

Anyway for me the pro/con of each solution are:

For the server-side computation:

Pro: You get all the power of the python libraries which is quite handy when you do any kind of math. There are some nice js libs too but nothing compares to numpy, sklearn or pandas.
Pro: You perfectly control the environment where the work is done. So if you're close to the limits, you can build much safer architectures. For example if you need a huge amount of memory, you can be sure to have it. You'll have to build a celery app and isolate the task to avoid concurrency problems but that can be done while you can crash a client if you run out of memory super easily. And it crashes the whole chorme app without any explanation for the user.
Con: The application will feel far less "reactive". That's because you'll need at least 300ms for the api call to complete, especially if you're on a secured env with oauth or open id auth. Count at least 100ms for your interface to render the content, you're at least at 400ms, more realistically at 1s if you have some kind of heaver computation or database access. Good but not perfect.
Con: The workload is on the server side, not on client side. If you have a lot of multiple users, that can be a problem.

On the other hand for client computation:

Pro: If you did it right you can have super fast response times. Add an optimistic logic for write/update/delete operation and a state-management and your users will get the feeling that everything is nearly instant.
Pro: You'll get far less api endpoints because you can basically give to the client a view of the raw data objects (= like in the database) with CRUD logic on top of it and let the front app do all the merging/grouping/math. Your project will be way easier to maintain in the long run.
Con: If you aren't familiar with the map/reduce/filter logic state management reactive programming, the learning curve is kind of tough.
Con: You'll write much more code to do the computation in Typescript than in Python. Even in typed Python. That doesn't bother me, but most people don't like it.

In the end, in my case, I like very fast applications. So I tend to use the front as much as I can and reserve the back for storage/users management/permissions. However it's not always the best way to do it. And a single library can be a game changer. Imagine having to implement an algorithm like dbscan in typescript, compare it to simply load sklearn...