REST будет достаточно быстрым.Используйте его до тех пор, пока не сможете измерить и получить реальные данные, свидетельствующие о том, что это проблема.
Но я бы не использовал REST API для непосредственного обращения с базой данных.
Я бы добавилуровни между ними, которые управляют безопасностью, проверкой и связыванием, случаями использования и обработкой ошибок, ведением журнала, транзакциями и т. д.
Если бы вы делали это в Spring, контроллеры могли бы беспокоиться о первых двух и службахэто будет иметь дело с двумя последними.
Да, клиент / сервер намного сложнее напрямую подключается к базе данных, но вы покупаете что-то, что вам нужно (безопасность и т. Д.), За счет большего количества слоев и большего количества кода.Решите, чего это стоит для вас.
Скорость, конечно, имеет значение, но предел, скорее всего, будет определен задержкой сети, чем что-либо еще.Если клиенты приходят через Интернет, это означает, что в среднем в вашем приложении должно быть 12 прыжков маршрутизатора.Я вижу задержку 70 мс в своей корпоративной интрасети.Пусть это будет показателем скорости.
Что касается того, что важно, я думаю, что сайт социальной сети должен беспокоиться о масштабировании для большого количества посетителей.Мне известны архитектуры, представляющие собой пулы потоков и очереди запросов, по одному потоку на каждый входящий запрос, или неблокирующие операции ввода-вывода, такие как Netty.Я думаю, что Python, эквивалентный Netty , является Twisted .