Математические расчеты - бэкенд или фронтенд

Лучше, если вы перенесете давление вычислений с сервера на клиента. Если вы хотите делать вычисления, вам следует сделать ajax сервис и делать внутренние вычисления, которые используются только для одного клиента. Но если вы делаете это на стороне клиента, то использование CPU и ram для вычислений переносится на сторону клиента и это не очень тяжело для него.

За исключением случаев, когда вычисления тяжелы для вашего клиентского браузера или вы хотите защитить методы вычислений!

Это всегда компромисс. Я работаю именно на этой архитектуре уже несколько лет (Django + Angular), создавая olap-приложения с потенциально тяжелыми манипуляциями с данными и вычислениями. Я использовал заднюю или переднюю часть, или обе. Обратите внимание, что в моем случае потенциальная нагрузка на сервер не была действительно большой, поскольку это были профессиональные приложения, используемые 5 людьми одновременно в час пик.

В любом случае, для меня плюсы/минусы каждого решения следующие:

Для вычислений на стороне сервера:

• Pro: Вы получаете всю мощь библиотек python, что очень удобно, когда вы занимаетесь математикой. Есть несколько хороших js-библиотек, но ничто не сравнится с numpy, sklearn или pandas.
• Про: Вы прекрасно контролируете среду, в которой выполняется работа. Поэтому, если вы близки к пределам, вы можете создавать гораздо более безопасные архитектуры. Например, если вам нужен огромный объем памяти, вы можете быть уверены, что она у вас есть. Вам придется создать приложение celery и изолировать задачу, чтобы избежать проблем с параллелизмом, но это можно сделать, в то время как вы можете обрушить клиента, если у вас очень легко закончится память. И это приводит к краху всего приложения chorme без каких-либо объяснений для пользователя.
• Против: Приложение будет казаться гораздо менее "реактивным". Это потому, что вам потребуется не менее 300 мс для завершения вызова api, особенно если вы работаете в защищенной среде с oauth или open id auth. Учитывайте, по крайней мере, 100 мс для вашего интерфейса, чтобы отобразить содержимое, и вы получите, по крайней мере, 400 мс, более реалистично - 1 с, если у вас есть какие-то более тяжелые вычисления или доступ к базе данных. Хорошо, но не идеально.
• Против: нагрузка приходится на сервер, а не на клиента. Если у вас много пользователей, это может стать проблемой.
.

С другой стороны, для клиентских вычислений:

• Pro: Если вы все сделали правильно, то можете получить супербыстрое время отклика. Добавьте оптимистичную логику для операций записи/обновления/удаления и управление состоянием, и у ваших пользователей будет ощущение, что все происходит почти мгновенно.
.
• Про: Вы получите гораздо меньше конечных точек api, потому что вы можете в основном предоставлять клиенту представление сырых объектов данных (= как в базе данных) с CRUD логикой поверх этого и позволить фронтальному приложению делать все слияние/группировку/математику. Ваш проект будет намного легче поддерживать в долгосрочной перспективе.
• Против: Если вы не знакомы с логикой map/reduce/filter + управление состоянием + реактивное программирование, кривая обучения будет довольно сложной.
• Против: Вы напишете гораздо больше кода для выполнения вычислений в Typescript, чем в Python. Даже в типизированном Python. Меня это не беспокоит, но большинству людей это не нравится.
.

В конечном итоге, в моем случае, мне нравятся очень быстрые приложения. Поэтому я стараюсь использовать переднюю часть как можно больше и резервирую заднюю часть для хранения, управления пользователями и разрешениями. Однако это не всегда лучший способ. И одна библиотека может изменить ход игры. Представьте, что вам нужно реализовать алгоритм типа dbscan в typescript, сравните это с простой загрузкой sklearn...