Про чаты
https://habr.com/ru/articles/933338/

Статья на мой вкус может быть полезна новичкам, чисто руку набивать в вызове сетевых методов. Кажется когда я начинал изучать сети первой задачей было как раз сделать чат. Но по теме можно поговорить в другом ключе.

Вообще в разработе сначала ты веселый, просто используешь технологии, не особо паришься по куче вопросов. Но когда пройдет 10 лет и тебя высушат по всем вопросам (А я в продакшене с 2014 по сути), то мыслить начинаешь немного иначе. Вот допустим нам реально нужно сделать чат в игре или продукте. Что нужно учитывать?

В первую очередь законодательства. ФЗ, GDPR и так далее. Допустим по законам в РФ нужно данные переписок 3 года. О чём нам это говорит? Мы уже не можем сделать чистый P2P чат, нам нужно место где всё это будет храниться. Плюс сервер по середине должен уметь хранить это всё и желательно в холодном хранилище, чтобы не разориться на дисках. Так как за 3 года может много инфы набежать.

Во вторую очередь стабильность. Когда-то я любил подход "сделай всё сам, ведь так гибче всего". И дейстивтельно, чем меньше готового мы используем, тем больше гибкость системы к изменениям. Но побыв пару лет техдиром, я с огромной неохотой буду запускать прямую разработку чего либо в принципе, что не требуется. Поэтому для того же чата я бы за основу взял бы Matrix, если у нас чат - это составная часть продукта, а не сам продукт. Мессенджер понятно лучше писать с нуля. Основной недостаток такого подхода это по сути эксплойты. У нас однажды какой-то белый хакер взломал наш гитлаб и указал через какое CVE публичной версии гитлаба. Второе, что по правке багов и остальному ты зависишь от вендора, но опенсорс можно редактировать самому, так что понятно что это путь компромисса. Но получаешь зато ключевое - общую стабильность за меньшую стоимость и большую скорость разработки. В не ключевых функциях это важно.

Собственно в третью очередь скорость разработки. Тут как бы есть два лагеря разработчики и бизнесмены. Разработчики любят разработку как процесс. Поэтому им нравится разрабатывать что-то крутое и долго. Особенно как пет проект, потому что своё же время бесплатновое (нет). Бизнес любит деньги. И задача бизнеса проверять гипотезы дешево и быстро. Базовый процесс работы в любом продукте и разработке любой функции в игре, которая должна поднять какие-то показатели. На коленке сделали чтобы проверить что "это работает", вливаем бюджет и делаем нормально до тех пор пока метрики растут. И это самый здравый подход. Поэтому если можно взять готовое - бизнес всегда возьмёт. А когда уже сама функция продуктовая докажет что она нужна, то может потребоваться кастом, гибкость и доработки.

Поэтому подобный класс туториалов - это так, разминка для мозгов не имеющая отношения к реальному продакшену. А вообще я просто заметку по теме хотел написать, а статья это так - повод 🙂

#новости #мысли