Все привет
Хочу найти что-то вменяемое для реалтайм приложения(что-то типа соц сети с сообщениями, друзьями и благородными девицами).
ПЫСЫ всё в учебных целях, просто хочу войти и начать шарить в реал тайм приложениях, как и с чем их готовят
Что хотелось бы:
Базу данных с change feed'ом(как rethinkdb) или что-то подобное, что позволит удобно организовать этот самый реалтайм
Чтобы можно было относительно легко маштабировать приложение, предполагаются пользователи по всему миру, и из-за этого нужно минимизировать задержки и нужно быть готовым к большому количеству юзеров.
Что пробовал:
.NET + signalR + MySQL - Есть сложность с маштабированием на несколько серверов, если равзертывать несколько экземпляров серверов с приложением, то нужно как-то синкать данные между ними.
Следующим эксперементом был
nodeJs + socket.io + rethinkdb - бд умеет в кластер, можно равернуть несколько экземпляров с приложением, подписки на изменения и всё такое и это круто, но rethinkdb стала опенсорсным проектом - и это как-то не пошло на пользу, есть проблемы с самой базой, она плохо выдерживает много конектов, и начинает тормозить, когда данных много(это из статей в инете).
Потом я попробовал Firebase(cloud firestore + cloud functions) - и вот тут уже всё вообще хорошо с маштабированием, но эти фичи в бете и и очень многого не хватает firestore(например нормального апи для работы с массивами) и решается это всё очень костыльно. Пробовал и realtime database, но там есть свои проблемы, типа индексов
Ещё посмотрел на AWS(AppSync), но не успел потыкать и буду рад, если кто-то что-то расскажет и поделиться опытом использования.
И подумывал об чём-то типа локальной организации данных, синхронизации нужных данных между серверами и синхронизации их с какой-то базой
Griboks, ну я понимаю, что оно отмаштабирует, но я так же понимаю, что мою задачу не возьмет на себя например какой-то Azure, потому у меня есть два пользователя и два сервера, один подключается к одному через signalR, а второй ко втором, и вот нужно чтобы оба сервера знали, что есть оба пользователя, вот это и нужно синкунуть.
Серверу все равно где географически находятся его клиенты. Он всех обслуживает одинаково. Чтобы не было задержек сети, серверу нужно быть близко к клиентам.
Александр Симонов, выбираемый стек не сможет решить проблемы с географическим расположением. Сервера должны быть на разных континентах. Стек может лишь помочь минимизировать задержку самой выдачи после получения запроса.
Роман Мирр, Вот в этом вопрос и заключается, с помощью чего организовать распределенную реалтайм систему. Я понимаю, что сервера должны быть и там, и там, и там - это и имело ввиду под "маштабировать приложение". Просто сейчас есть что-то покруче, чем просто звонок на сервер, сервер на бд; бд отвечет серверу, сервер клиенту. Вот я точно не знаю об всех этих "покруче"(как пример firebase) и хочу собрать как можно больше информации, чтобы было больше вариантов из чего выбирать.
Александр Симонов, ну, соцсеток для пользователей со всего мира не писал :) Самая главная проблема с этим сочетанием - это найти заказчика, готового навсегда остаться со мной один на один, без возможности найти другого разработчика.
Простой
Средний
Простой
Средний
