Какие технологии использовать для разработки встраиваемого live chat'a?
Планируется разработка встраиваемого live chat, по типу как это делается у https://www.tawk.to/ или https://crisp.chat/.
Идея такая, что на страницу вставляется script указывающий на источник, и после загрузки скрипта на странице появляется виджет с чатом.
Какие современные технологии можно использовать?
Пока что вижу такую реализацию:
Клиентская часть (виджет чата): React.
Серверная часть: Node.js с WebSocket.
Но не уверен что это правильно. Да и как быть с возможностью встраивания скрипта в страницу для загрузки виджета и подключения чата?
P.S. Предлагать использовать сторонние live chat не нужно. Требуется своя разработка.
простой лайвчат с сохранением минимального кол-ва сообщений, подойдёт просто сокеты и редис, а на счет встраиваемого, то там думать над
вариант его встраивания будет такой что пользователь на бэке должен иметь node + redis и импортировать пакет и запускать чат, + тоже самое на фронте, на фронте можно и через cdn
Everything_is_bad, возможно возможно, отрицать не буду, кстати на бэке можно тупо там sqlite прикрутить, тоже как вариант, это интеграция даже будет попроще чем с редисом
но на самом деле автор тут не уточнил, как бы он хотел встраивать этот чат на другие ресурсы, если через выдачу токенов, то все эти чаты должны работать получается через твою бд, то есть тебе надо написать апи, где ты будешь выдавать токены и написать sdk для серверной части node js, эту sdk будут устанавливать юзеры, внедрять в sdk токен выданный твоим сервисом и общаться через этот sdk с токеном с твоим апи ( это нужно если планируется этот чат делать в будущем платный к примеру ), то есть вариант только через своё апи, а на клиенте виджет через cdn так же можно
Сергей Горностаев, да, я изначально задание возможно не верно понял, поэтому изначально такую тупую интеграцию предложил, просто думал для личных нужды компании ( мини чатик )
szQocks, пока не очень понятна та самая "правильная" архитектура и стек технологий. Чат не совсем для личных нужд, а как продукт который потом можно будет предлагать другим веб сайтам.
В моем понимании стек технологий может быть такой:
Серверная часть
Node.js + Express.js: API, обслуживающий запросы и раздающий клиентский код.
Socket.io: обмен сообщениями в реальном времени между клиентом и сервером.
PostgreSQL: хранение истории сообщений, настроек и информации о сайтах.
Redis: кэширование данных и улучшение производительности при большом количестве одновременных подключений.
Клиентская часть:
Минимальный загрузочный скрипт: который вставляют на свои сайты. Он асинхронно будет загружать основной клиентский код с CDN.
Nuxt.js: для разработки клиентского интерфейса.
Возможно что-то лишнее. Я не сталкивался с разработкой такого рода ПО, по этому сложно понять как правильно, как должно быть
а как продукт который потом можно будет предлагать другим веб сайтам.
это надо посмотреть как сделано у других, понять принцип, и на основе их принципа пилить своё решение, разбить на мелкие детали и из них собрать план реализации и в путь
ну вот я щас попытался зарегаться, там просит ввести домен, получается они сохраняют домен в белых листах где-то, что бы потом через их api, мог работать сайт клиента, через сокеты или простые запросы там уж это не особо важно ( кто как делает, может кто-то поллинг вообще делает )
исходя из этой инфы получается что нужен какой-то способ динамически добавлять домен чужого сайта в белый лист, что бы он мог работать с твоим апи, вывод - гуглим что-то подобное и учимся "dynamic white list nginx" ( но предположу что белый лист сделан через redis и не через nginx а через миддлвар )
всё расписывать не буду, но то что я писал выше, про то что нужно писать API + выдачу токенов юзерам + писать возможно sdk ( но не факт ), всё это тоже может быть ( смотря как интегрировано ), прямо 100% пути решения не подскажу потому что подобным тоже не занимался
Серверная часть
Node.js + Express.js: API, обслуживающий запросы и раздающий клиентский код.
Socket.io: обмен сообщениями в реальном времени между клиентом и сервером.
PostgreSQL: хранение истории сообщений, настроек и информации о сайтах.
Redis: кэширование данных и улучшение производительности при большом количестве одновременных подключений.
Клиентская часть:
Минимальный загрузочный скрипт: который вставляют на свои сайты. Он асинхронно будет загружать основной клиентский код с CDN.
Nuxt.js: для разработки клиентского интерфейса.
да пиши на том, что знаешь, стек довольно неплохой, правда некст мне не нравиться но там уж сам решай
Если же проект предполагает хоть какую серьёзную нагрузку и несколько клиентов, то продумай несколько раз как ты будешь:
1) Масштабироваться горизонтально в части веб-сокетов
2) Перезагрузка системы. Тут скорее речь о том как правильно все построить так, чтобы перезагрузка минимально влияла на время простоя/возможную потерю соединений/сообщений в системе. Как правильно распределить нагрузку в момент переподключений десятков тысяч пользователей
исходя из этой инфы получается что нужен какой-то способ динамически добавлять домен чужого сайта в белый лист, что бы он мог работать с твоим апи, вывод - гуглим что-то подобное и учимся "dynamic white list nginx" ( но предположу что белый лист сделан через redis и не через nginx а через миддлвар )
Если рассматривать crisp, то я понял, что они не проверяют домен. Если ты знаешь токен чужого домена, а это можно увидеть просто просмотрев код страницы, то чат можно добавить и к себе на сайт. В данном случае токен просто ассоциируется с конкретным доменом, и как понимаю они не запрещают размещать чат с токеном на каком-то другом домене, он все равно будет работать, но в рамках того домена.
исходя из этой инфы получается что нужен какой-то способ динамически добавлять домен чужого сайта в белый лист, что бы он мог работать с твоим апи, вывод - гуглим что-то подобное и учимся "dynamic white list nginx" ( но предположу что белый лист сделан через redis и не через nginx а через миддлвар )
это было предположене
но основную суть я думаю донёс, что нужно изучить чужой продукт, понять его принцип, включить голову и на основе чужого продукта - продумать свой
Простой
