×Закрыть

Нужна помощь: Перевод бэкенда проекта с Erlang на Node.js

Всем привет!

Меня зовут Иван и я основатель проекта pibox.com (это решение для совместной работы музыкальных продюсеров). В данный момент мы предоставляем сервис продюсерам из Западной Европы, США, Англии. Есть также именитые продюсеры, которые работали например с Beyonce, Jay-Z, Son Lux и др.

В чем у нас сейчас проблема. Давно, когда мы только начинали у нас был концепт «Мессенджер + Облако для обмена большими файлами» и так как все крутые мессенджеры делались на Erlang, для супер-пупер нагрузок мы выбрали этот язык (конечно мы думали захватить миллионы пользователей и что будем выдерживать нереальные нагрузки).

Но не сраслось. Исходя из аналитики нами пользовались сугубо профессионалы (большие файлы и чат, карл) и мы ушли в нишу музыкального продакшена.

Короче говоря, сейчас мы понимаем, что используя Erlang потеряли гибкость/скорость в разработке и поиске сотрудников. (кстати ищем соучредителя СТО, доля в компании тоже кофаундерская). Очень долго пилим функции, медленно проводим эксперименты по продукту + найти заветного соучредителя СТО практически невозможно.

Так вот собственно вопрос(ы) века, тысячелетия и вообще вселенной:

1. Стоит ли нам с нуля переписывать бэкенд на Node.js?
2. Подходит ли Node.js для проекта где есть чат, комментарии аля SoundCloud, обмен и менеджмент файлов, мультиплатформенные приложения (если не сложно посмотрите наш сайт pibox.com, пожалуйста).
3. Как правильно все спланировать чтоб не запороть архитектуру? (может есть методики планирования архитектуры и тд., консалтинг, гуру node.js)
4. Ну и конечно же «плюсы, минусы, подводные камни»?

У меня еще миллион вопросов, но попробую ограничиться этими.

Спасибо всем за помощь, это очень важный и переломный шаг для нашего проекта!

(p.s.) Кстати, Erlang крутой по-своему, но у нас в коде/архитектуре есть проблемы и все равно надо многое переписывать, так что если с нуля то переходить на что-то менее хардкорное.

LinkedIn

Лучшие комментарии пропустить

Нода, эрланг — искать то людей надо. Лично я вотпрямщаз могу найти контакты нескольких человек с не хилыми знаниями эрланга, но

1. Стоят дороже, чем средний Java — разработчик раза в два-три
2. Очень свободолюбивые. Сидеть в офисе потому что «так положено» не будут, а могут и нахуй послать.
3. Работать в стартапе у которого сейчас денег нет, но когда нибудь потом будут не станут.
Интересно — пишите в личку, научу где такие водятся

Як на мене, то перехід на nodejs це кілька кроків назад.
Ви хочете вкластись в короткострокову перспективу. Проекти на erlang порівняно легше дебажити.
Спробуйте Elixir (запіліть якийсь блог, туторіал пройдіть). Сьогодні людей зацікавлених в ньому більше. Вони на одній віртуальній машині крутяться, можна без проблем існуючі модулі erlang використовувати і навпаки.

Почему не на Go или там Java?

1. не знаю какая у вас финансовая ситуация, но имхо для стартапа переписывание всего бекенда не супер идея. лучше переходить на микросервисы и понемногу куски переписывать. к тому же нода все таки сомнительный выбор по сравнению с эликсиром например. он простой, удобный и тоже на beam работает
еще сильно зависит от того, что у вас там, например если вы мнезию используете как бд, то еще геморней может быть переход
2. подходит, во всяком случае на ноде это можно сделать, хотя возможно это и не самое эффективное решение. главное при работе с большими файлами не забывать, что нода однопоточная и если функцию требующую много времени на выполнение не разбивать с помощью nextTick и не использовать кластер, то можно сильно всё подвесить. и стоит не забывать пользоваться стримами по возможности для работы с файлами. в остальном масштабируется может и не так просто как BEAM, но ± можно.
3. имхо никакой архитектурной специфики для ноды нет, можно обычные микросервисы делать со всякими grpc
4. минус это js — постоянные (undefined is not a function и Cannot read property ’*’ of null) поэтому возможно стоит подумать о typescript или flow, но хотя бы колбеков можно избежать благодаря async/await

«Хорошая» история о том, как выбирая технологию для стартапа нужно руководствоваться не хипстерским хайпом, а количеством доступных кодерков на рынке.

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Кстати, крайне рекомендуется к прочтению и размышлению до принятия решения

1. Почему никто из комментаторов не вспоминает про Elixir? (хотя не — один человек таки вспомнил)
2. Смысла переписывать весь бэкэнд с эрланга на ноду только потому, что так захотел фронтэндщик — ИМХО ноль. Ну разве что, если он реально знает, как это все правильно переписать.
3.

у нас в коде/архитектуре есть проблемы и все равно надо многое переписывать, так что если с нуля то переходить на что-то менее хардкорное.

При переписывании с нуля есть риск, что в архитектуре тоже появятся проблемы. Поэтому либо искать чела, который реально хорошо перепишет на «что-то менее хардкорное» (иначе смысл менять шило на мыло эрланг на что-то другое), либо искать чела, который исправит косяки текущего кода/архитектуры.

Читал по диагонали, сорри, но объясните мне непонятливому зачем все эти гамноязыки, если можно использовать asp.net, java, php?

Наверное потому что нынче много народу для которых уже и asp.net, java, php — гамноязыки. Тут проблема в том что есть контингент, который действительно что-то понимает, и есть контингент который «ниасилил» и решил попробовать что-то хайповое.

«Хорошая» история о том, как выбирая технологию для стартапа нужно руководствоваться не хипстерским хайпом, а количеством доступных кодерков на рынке.

количество которых прямо пропорционально хайпу

Вы хотели сказать «обратно пропорциональна»?

как раз прямо. чем больше хайпа, тем больше кодерков

Ну я просто думал что доступные !== валидные.
Не люблю тратить время на Hello World’щиков.

Я вижу тренд кружки, собрания, хеллоу-ворлдщики разводят хайп. Но реального опыта — 0. Продолжают програмировать на пхп или джаве. Через год, все эти хайпщики переключаются на след технологию.

там где хайп, туда с непосредственностью стада баранов тянется бизнес, бормоча мантру «нулевой порог..быстрый старт..(далее неразборчиво)». там, где бизнес, там деньги...на деньги слетаются кодерки-однодневки. через месяц-два, когда становиться очевидно, что очередной фреймворк-спаситель фуфло, вся эта коричневая масса перетекает к следующему фреймворку

А шо не так? Все логично, можно сидеть педалить на том, что бабок не приносит и заливать какой ты окуенный спец, а остальные — стадо баранов, или разобраться с новой трендовой технологией, которая приносит лаве.

или разобраться с новой трендовой технологией, которая приносит лаве.
и заливать какой ты окуенный спец

Добрый день,
Зашёл на проект, посмотрел, очень классно. Я думаю, что мы бы пользовались им, когда у меня была группа. Особенно порадовала возможность прям на ходу выделить и сделать питч. :)
На мой взгляд, вам надо определиться, рассматриваете ли вы только вариант оффлайн-сотрудничества (т.е., только все в одном офисе) или вы готовы сотрудничать с людьми из других стран. Моё мнение — этот проект не настолько масштабен и технически сложен, чтобы для него нужна была команда из 20 человек, сидящих в одном офисе. Почему это важно? Во-первых, потому, что кадровые ресурсы Украины ограничены (в том смысле что в одной стране меньше людей, чем во всём мире). Во-вторых, и это даже важнее — люди здесь привыкли работать больше в аутсорсе, чем в продукте, а это немножко разные подходы к делу, и кроме того это накладывает некоторую специфику на представленность людей по тем или иным технологиям.
По техническим моментам. Эрланг конечно на сегодняшний день в определённой степени экзотический язык (недавно видел рейтинг, где он был одним из не рекомендуемых к изучению в 2018 году), и действительно найти на нём разработчика на long term будет непросто, притом вы говорите, что так и так многие части надо переписывать. Я понимаю, что по факту у вас не то чтобы супер высокие нагрузки, и скорее всего они не будут резко расти, даже если у вас будет 100000 пользователей, это всё равно на сегодняшний день не очень много. При этом у вас продвинутый фронтенд и приложение. Я думаю, что для бекенда в данном случае подошло бы практически всё что угодно. В том числе и Node.js, Java, .NET, PHP, Go, Python. На любом популярном на сегодня языке этот функционал можно написать. Как уже правильно отметили в предыдущих комментариях, надо смотреть в сторону микросервисной архитектуры. Т.е., это означает, что вы ваш бекенд разбиваете на несколько небольших независимых сервисов, взаимодействующих с фронтендом, и они пишутся и поддерживаются отдельно, вплоть до того, что они могут быть написаны хоть на разных языках. Таким образом, вы сможете постепенно переписывать только нужные (с фрагментацией в разумных пределах, конечно) части, не вдаваясь сходу в дорогостоящий стек работ, среди которых в итоге какой-то функционал может не понадобиться или сильно видоизмениться, как это часто бывает в стартапах. Здесь, я думаю, вопрос сводится не столько к выбору технологии, сколько правильного человека, который захочет вникать в ваш бизнес, быстро добавлять функционал и проводить эксперименты.
«Не запороть архитектуру» — это тоже вопрос опыта и планирования. По сути, если человек хоть раз (а лучше не раз и не два) писал проект, которым реально пользовались, получал входящие заявки на изменение / добавление функционала и всё такое, то он понимает, как её сделать, чтобы всё не взорвалось.
Мне действительно очень понравился ваш проект, так что если что — пишите в личку, постараюсь помочь с чем-то более детально.

Спасибо большое! Хорошо подвели итог, все по делу:)

Прочитал заголовок, и поржал чего-то.

Дополнение! Забыл указать что бэк на Эрланге из-за пивота с «Облачного Мессенджера» в «Платформу для коллаборации продюсеров» уперся в то что его нужно много где переписывать. И если уже переписывать то на что-то более гибкое.

И если уже переписывать то на что-то более гибкое.

Я категорически не согласен с претензиями к гибкости Erlang.

Я категорически не согласен с претензиями к гибкости Erlang.
используя Erlang потеряли гибкость/скорость в разработке и поиске сотрудников.

Перевожу «притензии к гибкости Erlang»:
Не могут найти не инфантильных (1) кодерков готовых работать за еду (2).

Нода, эрланг — искать то людей надо. Лично я вотпрямщаз могу найти контакты нескольких человек с не хилыми знаниями эрланга, но

1. Стоят дороже, чем средний Java — разработчик раза в два-три
2. Очень свободолюбивые. Сидеть в офисе потому что «так положено» не будут, а могут и нахуй послать.
3. Работать в стартапе у которого сейчас денег нет, но когда нибудь потом будут не станут.
Интересно — пишите в личку, научу где такие водятся

Сама по себе смена Erlang на Node.JS ничего не решит, так как оба — птички одного полета. Да, умеющих Node.JS сильно больше, но в среднем их качество — никакое. Я бы на вашем месте подумал на тему сменить фреймворк.

Сейчас есть человек который хорошо знает JavaScript, React, React native. Будем пробовать как получится с написанием бэка.

Якщо ви хочете змінити бекенд на JavaScript тільки через те, що у вас є хороший фронтендщик, то ви на хибному шляху. Буде на багато більше толку, якщо бекенд розробник змінить мову програмування на потрібну вам.

Согласен, гавнокодить можно на чём угодно... от языка/фреймворка не зависит. Конечно у всех решений есть свои ограничения и особенности, но желательно что бы у человека был не только опыт работы с актуальной версией решения в продакшене, но и опыт поддержки. Вообще идеально если в состоянии контрибьютить в целевые решения, что бы по необходимости что-то быстро форкнуть и пофиксить... в случае с тем же react-native так часто бывает.

А почему талантливый фронтендщик не сможет стать бэкендщиком (фул-стек разработчиком)? Возможно кто-то может помочь в архитектуре для node.js?

не сможет стать бэкендщиком (фул-стек разработчиком)?

Будет использовать «псевдо-оптимальные» решения что бы «быстро выкатить», из-за нехватки опыта. Это как шутка про MEAN Stack: вроде хайп, вроде можно быстро переквалифицироваться, но вещи сложнее hello world’a работают как-то никак.

Потом опять придётся переписывать... может даже и несколько раз подряд.

Возможно кто-то может помочь в архитектуре для node.js?

Тут дело не в node.js — он не ставит каких-либо ограничений, а в опыте конкретного разработчика.

Как показала моя практика — что бы быть полноценным Fullstack’ом, надо, как минимум, перепробовать 2-3 языка и 4-5 фреймворков и СУБД, ещё и окунуться в DevOps.

На это нужно минимум 3 года, это не то что «Вот Вася у нас хороший фронтендер, но это не точно, — давайте притворимся что он ещё может быть и Fullstack из-за нехватки кадров» «Что об этом подумал Вася так никто и не узнал».

Есть такое распространённое когнитивное искажение как Ореол.
Возможно Вам стоит пересмотреть свои взгляды.

Тем не менее есть много успешных примеров перехода фронтендеров на ноду.

удет использовать «псевдо-оптимальные» решения что бы «быстро выкатить»

это основная фишка, котору рекламируют во всех новомодных языках: «низкий порог входа..блабла...выкатим быстре...блабла...бизнес требования...блабла»
потом бегают с выпучеными глазами, пытаясь все это наговногоденое смаштабировать

Фронт и бек — это немножко разный образ мышления нужен. На фронте больше работаешь с DOM и визуальной частью, и красивый внешний вид важнее всего. На бекенде же нужно:
— Больше внимания безопасности, чтобы не было например так что пользователь может посмотреть чужие данные просто подставив id. На фронтенде как правило об этом не задумываешься — запрос с токеном бекенду отослал и потом показал то что пришло в ответе.
— Больше внимания оптимизации, особенно если система высоконагружена.
— Больше внимания обработке ошибок, чтобы не получилось что весь бекенд падает раз в несколько минут. Бекенд на ноде это ведь долгоживущий процесс, в отличии от того же пхп например.

Фуллстеком-то стать конечно можно, но ваш фронтенд будет ним становиться за счет качества бекенда и через год-два сам же предложит его переписать заново. И это нормально, но нужно учитывать.

C react-native есть много проблем касательно производительности — некоторые компоненты возможно придётся реализовать нативно. Анимации там работают никак... единственным преимуществом я выделил возможность верстать на css-in-js’e сразу под react и react-native, правда там есть свои проблемы — много чего надо polyfill’ить под RN.

В общем если у вас «чувствительная» к производительности целевая аудитория и простое приложение — лучше не рисковать.

Почему не на Go или там Java?

Из этих двух я бы выбирал только java.

Товарищ, а у вас никогда typechecker в свифте не сегфолтил ?
Я понимаю что конторы типа IBM сумонят толпу индусов и делают всякое. Vapor ещё более-менее, но он не отличается производительностью. К сожалению, опыт разработки на Swift’e оставляет желать лучшего.

У rust’a довольно высокий порог входа и он не очень хорошо подходит для прикладных задач — у разработчиков уходит много времени на «преодоление предупреждений компилятора», нежели непосредственно на разработку и тестирование решений. Про FP/FRP на Rust’e история умалчивает.

Есть пару интересных подходов с мутационным тестированием на макросах в Rust’e, но пока что это «только планы»...

Мне особенно понравился совет про Rust. А почему не С?

У Rust’a есть вэб-фреймворки, и он вполне юзабелен для разработки что под Android с NDK, что под iOS...

У Rust’a есть вэб-фреймворки

www.cppwebframework.com

Haskell или Scala?

Тгда уже Erlang.

Точно, почемубы с Erlangа не переписать обратно на Erlang ?

Короче говоря, сейчас мы понимаем, что используя Erlang потеряли гибкость/скорость в разработке и поиске сотрудников. (кстати ищем соучредителя СТО, доля в компании тоже кофаундерская). Очень долго пилим функции, медленно проводим эксперименты по продукту + найти заветного соучредителя СТО практически невозможно.

Интересно, а вы ищите СТО с привязкой к языку? А зачем? Найдите сначала человека вообще способного и готового работать с вами а потом уже предоставьте ему выбирать техническую часть. Разве не так эти СТО работают?
Ну и да. Нода это класно, все на нём можно, но если все таки стоит вопрос о найме людей с рынка может стоит посмотреть на что-нибудь более мейнстримное?

может стоит посмотреть на что-нибудь более мейнстримное?

99% галерных гребцов не знают что такое REST и плодят копи-пасту с CRUD контроллеров.

«Мейнстримное невежество» — это конечно весело.

Есть какие-то конструктивные предложения ?

Ok, хорошим примером является паджинация в REST’e — что offset что keyset имеют свои особенности. Сам по себе http уже имеет все средства для этого.

1. Для проверки возможности offset паджинации ресурса сначала отправляется HEAD запрос, если сервер возвращает заголовок Accept-Ranges: pages, значит можно использовать offset паджинацию, иначе используется непрерывная keyset паджинация посредством Link заголовка.
2. В GET запросе с паджинацией используется Range: pages=1-2 загловок, ответы имеют статусы 206 Partial Content и 416 Requested Range Not Satisfiable соответственно и заголовок Content-Range: 1-2/100.

Особенно весело с Patch запросом, для которого отдельно есть json-patch спецификация.

Как много Вы встречали разработчиков, которые вообще используют статусы 201 / 206 / 416 в своих REST эндпоинтах ?

Собственно у нас гребцы не то что RFC не читают, даже понимания почему offset паджинация говно — напрочь отсутствует. Об этом довольно неплохо написано, например, вот здесь Маркусом.

столько умных слов! слушал бы и слушал

Просто «наболевшее», даже не представляете сколько я уже повидал проектов с кривыми REST API... где-то больше пяти десятков точно. Не зря в анлийском «Ignorance» имеет корень «Ignore» ...

Сдаётся, тут спутаны знания спецификации HTTP и REST. rel="first", rel="prev", rel="next" и rel="last" про пагинацию. Но да, не все гребцы обладают энциклопедическими знаниями спецификации.

REST подразумевает использование всех средств HTTP для реализации API эндпоинтов, то что люди HTTP спеки не знают/не читают — это уже дело вторичное.

Это, скорее, будет оверкилл для большинства проектов. Задача, ведь, не создать эндпоинт по всем канонам. Во многих случаях клиент всего один — веб. Так что даже в REST необходимость сомнительная. Поэтому просто HTTP API. И то, что вы видели, тоже, скорее всего, было HTTP API. Странно, что вас так это задевает.

Да эт не только меня задевает, тут ещё есть пару десятков «около-фейсбучных» адептов «повидавших всякое»...

Уже повидал как экспоненциальненько растут накладные расходы на поддержку в подобных проектах с кривыми моделями... которые, как правило, приводят к довольно кривым дизайнам API.

REST подразумевает использование всех средств HTTP для реализации API эндпоинтов
REST does not restrict communication to a particular protocol, but it does constrain the interface between components

5.3.2 Connector View
www.ics.uci.edu/...​ation/rest_arch_style.htm

У всех в голове «свой REST», спецификации нет, каждый кто что хочет — то и воротит...
У GraphQL тоже хватает недостатков, доходит до того что в Relay1 FB полифилит всякое уже непосредственно в компиляторе запросов.

весь REST — это попытка формализировать некую идею про способ упорядочить апи, которое чаще всего реализуется на http. Не более того.

Так получается, что не все видят смысл в full compliance с RESTfull статьями, которые, кстати, тоже не носят характер спецификаций как таковых. И ничего в этом плохого нету. Кому-то достаточно сделать пагинацию в виде customer/1/products/from/20/to/30 и не устраивать себе головную боль.

Та... тут можно целую серию статей написать про REST...
Сам факт «непонимания» стал причиной почему фейсбук в своё время «скатился» в GraphQL.
Сам по себе GraphQL не то что бы был прям «серебряной пулей», но по крайней мере он не привязан к протоколам, и у него хотя бы есть спецификация... а не набор разбросанных RFC разбавленных BNF-водой и официальщиной W3C.

тут можно целую серию статей написать про REST...

Я бы, кстати, почитал.

Пишу GraphQL маппер для PostgreSQL’я с поддержкой лямбды и ААА ... так что и статьи про него куда-то буду писать. Хочу заюзать Flow, но он пока не отличается стабильностью — вот переписываю на JS. Благо уже скопилось «стадо желающих и заинтересованных» в подобных затеях.

так что и статьи про него куда-то буду писать

А есть твиттер/телега/фб? где следить за апдейтами?

Да буду отписывать где-то в dev-ua / beerjs / frontend ua etc

но он пока не отличается стабильностью — вот переписываю на JS.

не стабильный или читабельность ошибок не такая как хотелось бы?)

Именно нестабильный, так как у FB может 5-6 тегированных релизов вподряд отваливаться. Типа 0.52 работает, а 0.53-0.62 как-то неочень, сейчас вот виндовые билды отваливались нон-стоп.

Я бы, кстати, почитал.

www.ics.uci.edu/...​ation/rest_arch_style.htm

Это будет плезнее чем бредни очередного «Егора Бугаенко».

99% галерных гребцов не знают что такое REST и плодят копи-пасту с CRUD контроллеров.

Меня как-то коллеги чуть не съели за то, что я PUT для создания сущности использовал))

Вот как раз человек который знает Джаваскрипт есть как часть команды, но пока не фултайм. Будем пробовать частично переписывать бэк (это предварительное решение пока). Нужно сначала обо всем договориться.

Соглашусь с тем, что переписывать бэк на JS только лишь потому, что есть парт-тайм фронтендер знающий JS немного опрометчиво.

М... Фронтендер на парт-тайм? Я не совсем понял это что единственный программист-сотрудник? Эрлангер куда-то делся?

В данный момент есть часть аутсорса для ерланг и как раз фронтендщик запилил почти всю платформу и работал фул-тайм. У него есть все шансы стать full-stack кофаундером. Для продуктового стартующего проекта нужно быстро проверять гипотезы и расти, а не основательно запилить что-то одно ненужное и упасть в пропасть. Бизнес-эксперименты это ядро всех успешных проектов и скорее всего на node.js и с этим человеком это будет быстрее.

Опять же, это я и спрашиваю. И то что я описываю это эксперимент, который мы тут обсуждаем. Гипотеза в том что перевод проекта на Node.js и развитие активного разработчика в full-stack дасть гибкость и увеличит скорость проведения экспериментов. Плюс сейчас бэк эрланга уперся в то что его нужно много где переписывать.

и скорее всего на node.js и с этим человеком это будет быстрее.

Ну тогда вроде бы ответ очевиден?
Единственное но — возможно не кидайтесь переписывать все и сразу а идите вперед маленькими шагами.

Мне показалось что автор решил перейти от хипстерских ФП, к чему то более годному в реальной жизни.

А в комментах предлагают ещё кучу всего навалить.

Я не бекегд, фронт. Работаю с фаирьейсом. Бекегд вообще не нужен, работает все плюс минус хорошо. Если нагрузок нет то проблем возникнуть не должно.

Из моего опыта есть много интеграций с рест АПИ. И хочу сказать что фаирбейс превзошел это удобство на порядок.

Я хочу изменить структуру данных? Нет проблем, я просто сохраняю новый ключ значение. Изменения в коде одна строка.

А был бы рест, пришлось дергать бекендщика.

Также в фаирбейсу из коробки подписывание на данные через вебсокеты, при обновлении в БД автоматом обновляется на сайте.

П.С. из минус, фаирбейс лёгкий по началу, но там ещё есть такие штуки как query, security, firebase cloud

А вы в совершенстве знаете firebase?

Нет — Я фронтенд разработчик — но разобраться с ним смог и успешно работаю (По сути на проекте только несколько фронтенд разработчиков — обходимся без БЕКа

Я не бекегд, фронт. Работаю с фаирьейсом. Бекегд вообще не нужен, работает все плюс минус хорошо. Если нагрузок нет то проблем возникнуть не должно.

Я не программист, я бухгалтер. Работаю с главной бухгалтерской книгой. Компы вообще не нужны, всё можно вручную записывать плюс минус хорошо. Если нагрузок нет то проблем возникнуть не должно

Если нагрузок нет то проблем возникнуть не должно

В целом при нагрузках оно масштабируется достаточно линейно простым добавлением нодов персонала.

>

Я не программист, я бухгалтер

так тут что-то на уровне когда действительно бухгалтеру хватает того что есть без навороченого программиста.

То есть ваш сарказм вышел совсем не сарказмом — все именно так как вы и говорите.
Я ведь даже не сказал что фаирбейс не может в нагрузки — очень даже может, гугл обещает масштабирование и прочее, я скорее говорил о том что возможно написать высоконагруженный проект на фаирбейсе будет сложнее чем на классическом подходе. Но вот быстрый старт и всякие там MVP заходят на отлично.

1. Стоит ли нам с нуля переписывать бэкенд на Node.js?

Сейчас имеет смысл использовать GraphQL мапперы, типа postgraphile — что бы не плодить копипасту.

Правда годных пока нет в природе, и надо писать самим руками — что без хорошего опыта разработки совсем не вариант.

Проекты типа Loopback не особо жизнеспособны, хоть и IBM ввалил туда 8 лям у.дмурдских ё.жиков...

Надо сразу, целиком и полностью окунаться в FP/FRP, если с FRP сейчас более-менее понятно — это Rx.js, то вот с FP как-то не очень — есть Ramda, есть lodash-fp, но ramda в раза 3 медленее.

Касательно статической типизации — если у вас распределённая команда больше 10 человек, лучше использовать что-то, что Flow что TS имеют свои недостатки. Flow имеет поддержку Variadic Functions и других ништяков, особенно годных для FP/FRP, которых нет в TS, но написан на OCaml’e и часто, очень часто, отваливается.

2. Подходит ли Node.js для проекта где есть чат

До 15-17К RPS подходит — можете спокойно складывать в какую-то очередь типа Redis / Kafka / RabbitMQ что душе угодно...

Я обычно прикручиваю на GraphQL notifications поверх http/2.

Там libuv используется, и в принципе быстрее только uvloop + asyncio в питоне, питон сейчас гораздо быстрее ноды в плане производительности, и статическую типизацию завезли... и уже совсем не похоже на питон %) Скоро можно будет Python разработчиков dependency lock’ать — типа «старше Python 3.6 проекты не беру». Люди не особо спешат доучиваться/переучиваться в Украине и вообще... Контингент питонистов нынче региден не чуть не меньше чем контингент J2EE джавистов.

Golang требует zero-lloc подхода, что собственно отлично показано в проектах Валялкина, типа fasthttp. Конечно там будет 300К RPS, но и порог входа довольно высокий. Сам по себе golang из-за кодогенерации имеет кучу ограничений. По производительности разработчиков — JavaScript с FP/FRP сейчас более эффективен.

Научитесь профилировать, снимать Flame Graph’ы в продакшене, завести OpenTracing какой-то... проводить нагрузочное тестирование — будет видно где слабые места и что действительно стоит оптимизировать. Обосрать конечно можно что-угодно, и это отличный повод переписывать всё на ассемблер, cloudflare уже делал так.

3. Как правильно все спланировать чтоб не запороть архитектуру?

Не писать очередное MVC спагетти, приправленное копи-пастой из CRUD контроллеров.
Понимать что это MVVM с CQRS-ES...

Лучш научится сначала нормально работать с базами, нормализовать до 6ой нормальной формы, выучить SQL и использовать контролируемую денормализацию... лучше всего сейчас на PostgreSQL’e.

Если есть какие-то логи, например чатег — можно брать колоночные СУБД типа Cassandra.
НО на PostgreSQL’e под BRIN индексом тоже заводиться при похожих объёмах (+1Тб в сутки).

4. Ну и конечно же «плюсы, минусы, подводные камни»?

Популярное решение — не значит качественное или оптимальное, значит что там дохера дилетантов, и нет выработанных лучших практик... Надо понимать динамику сообществ целевых OpenSource проектов, цели, мотивацию, источники финансирования — что бы правильно оценить долгосрочные риски внедрения и эксплуатации.

Подводных камней у Ноды довольно много, но с хорошим тестированием и правильной организацией работы большая часть «узких мест» вылазит в первую неделю работы.

У меня еще миллион вопросов, но попробую ограничиться этими.

Мне можно писать в дискорд.

p.s. пишу flow typecheck’er плагин под eslint, т.к. babylon вроде как нормально парсит Flow. Да, переписываю кривые фейсбучные поделки с OCaml’я на JS. Да, я работал с Erlang, Clojure/ClojureScript, Haskell, PureScript... в общем почти со всеми популярными языками/решениями последних лет, кроме C# / ASP.NET.

Можна поцікавитися де Ви працювали до цього та які проекти закінчили? Через self-employed та не закінчений вуз в мене склалося враження, що Ви є диванним аналітиком.

Через self-employed та не закінчений вуз

Вже не для кого тут не секрет що ВУЗ гарантує рівно нічього...

Життя склалось так що багато де працював, часто змінював місце роботи.
Ну там в Walmart’i, в Cake Solutions, в HashiCorp ... тощо

та які проекти закінчили?

Різне бувало, починаючи від мобільних додатків, закінчуючи залізом та драйверами...
Зазвичай працював або контрактором, або консультантом, більшість контрактів під NDA.

Ви є диванним аналітиком

Я розумію шо DOU — помойка, але не треба одразу ж ярлички чіплять.

Можна, конкретно, що з цього Ви, особисто, вважаєте невірним ?

більшість контрактів під NDA

Условия работы, название компании на которую работал, общее описание деятельности (в общем, то что обычно рассказывают на собеседованиях) — не могут являться НДА, т.к. не являютя конфиденциальной информацией.

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

Можна, конкретно, що з цього Ви, особисто, вважаєте невірним?
Да, я работал с Erlang, Clojure/ClojureScript, Haskell, PureScript... в общем почти со всеми популярными языками/решениями последних лет, кроме C# / ASP.NET.

Це все що завгодно, але не популярні мови(принаймі в Україні).

До 15-17К RPS подходит — можете спокойно складывать в какую-то очередь типа Redis

Redis не почне втрачати повідомлення ще раніше?

нормализовать до 6ой нормальной формы

Навіщо 6 форма для чатика?

Популярное решение — не значит качественное или оптимальное, значит что там дохера дилетантов, и нет выработанных лучших практик..

Для джави значить немає бест практіс, а для хаскеля є?

Надо сразу, целиком и полностью окунаться в FP/FRP

Чому?

Сам по себе golang из-за кодогенерации имеет кучу ограничений.

Можна детальніше?

Це все що завгодно, але не популярні мови(принаймі в Україні).

Бекенд українського ПриватБанку написаний на Erlang.
Clojure/ClojureScript використовують такі українські продуктові компанії як Attendify та Grammarly, загалом там підхід: фронтенд, бекенд, мобільні додатки пишимо на Clojure.
PureScript зараз використовують у MapBox (Агафонкін наче шось там робив).

Не всі ж «гребуть» — хтось шось й розумне робить...

Redis не почне втрачати повідомлення ще раніше?

Чого б це ?
$ redis-benchmark -n 1000000 -t set,get -P 16 -q SET: 403063.28 requests per second GET: 508388.41 requests per second

Навіщо 6 форма для чатика?

Вона стосується не чатика, а нормальної архітектури.
Всі користуються СУБД, а от проектувати та підтримувати нормально реляційну схему не взмозі.

У нас є відморозки недосвідчені люди, які вважають що нормалізація — то антипаттерн, усюди треба зменьшувати кількість SQL’них JOIN’ів та денормалізовувати... або ж використовувати MongoDB, бо там наче треба меньше заморачуватись... Про те що MongoDB є реляційною й потребує такої ж нормалізації схеми — вони не знають.

Так от власне нічього не заважає створити матеріалізоване представлення (MATERIALIZED VIEW) у тому ж PostgreSQL’і, денормалізувать та упакувать туди все в JSONP (є для того zson), наприклад усі данні користувачів що були активні останній місяць, а все інше тримати нормалізованим, щоб не роздувать розмір табличок та індексів...

Денормалізовані представлення тримать в окремому табличному просторі (TABLE SPACE) на SSD’шках, а самі данні безпосередньо на дискових масивах... Відповідно можна використати різні індекси, не обовязково BTree — можна GIN/BRIN, що дозволить значно зменьшити їх розмір, та розмір Heap’у PostgreSQL’я.

Це нормальний підхід, котрий, наприклад, використувався в Instagram’i під Django’ю ще з 2009го року (так, я ще памятаю ті часи...).

Для джави значить немає бест практіс, а для хаскеля є?

Конкретно для джави зараз немає, якби було то у нас би не було такого пестрого різноманіття фреймворків та рішень до джави.

З хаскелем трохи легше — там є спільноти та визнані найкращі практики, а не специфікації нав’язані потребами ентерпрайсу, що безпосередньо до досвіду розробки (development experience) не мають ніякого відношення.

Надо сразу, целиком и полностью окунаться в FP/FRP

Тому що є купа задач на фронті які набагато легше реалізовуються з FP/FRP.
Ну там робота з WebSocket’ами на ванільному JS ~300 LoC на якомусь redux-observable під React 16-20 LoC...

Зараз всі великі фронтенд проекти, будь то чи Веб, чи мобільні додатки, чи десктоп, використовують Rx в різних варіаціях.

Сам по себе golang из-за кодогенерации имеет кучу ограничений.

Швидкість компіляції зменьшується дуже швидко з ростом проекту, рефлексія та interface{} дуже дорого обходяться, немає нормальних примітивів для роботи з zero-lloc підходом. Доходить до того що пітон зараз в продакшені себе набагато краще показує під uvloop + asyncio...

Да, использует ссылки и B-tree индекс, и точно так же подлежит нормализации.

в HashiCorp

Так вот, оказывается, кому я хотел последние 2 недели за горло подержаться! ;)))
В действительности, конечно, не Вам, а документописателям. Ошибок в доке там мама не горюй. Но, впрочем, это тоже скорее не проблема, а возможность в нашем случае. ;)

Пишите в Дискорд, помогу/расскажу.

Код правят быстрее чем документацию — часто релизят противоречивые фичи.
Тулсет Hashicorp’a довольно специфичен, и не со всем дружит... ну там, например, Consul с K8S подружить довольно большой и сложный квест.

Я довольно известен в фронтендерских кругах... beer.js’ы KyivJS’ы и около того.

Спасибо, если что — обращусь.
Из их стека пока только vault народ пользует, там все относительно просто (если, конечно, проверять что выходит а не тупо из доки код копировать).

например, Consul с K8S подружить довольно большой и сложный квест.

В моем проекте запустить консул в кубике никаких проблем не было. Хотя, смотря что ты имеешь ввиду под подружить.

Полностью заменить etcd на консул.

Ого, много инфы! Я слабо это все понимаю, покажу это все нашему девелоперу. Большое спасибо! Смотрим, если что ещё будет — напишем обязательно:)

Если сильно переживаете за производительность чатика — можете оформить его на Golang’e под fasthttp с встраиваемой очередью, синхронизацию для чатиков обычно достаточно выполнить на векторных часах (метках Лампорта). У HashiCorp’a для этого, например, есть Serf — можно от туда подтянуть консенсус.

А всё остальное можно и на Ноде / Питоне написать — под что есть люди/ресурсы.

Очередь лучше свою руками собрать, с нужными оптимизациями и кодогенерацией, — родной сontainers/list из-за interface{} и рефлексии не особо производителен, да и тоже желательно делать zero-lloc (zero memory allocations) для нормальной производительности (можно глянуть исходники fasthttp для хорошего примера).

Если будете заморачиваться с DevOps’aми и контейнеризацией- для хорошей производительности желательно использовать OVS, можно и под DPDK, это сделано например в Cisco Contiv.

Т.е. там такая ситуация что заменив сетевой стек, ну там Kubernetes’овский Flannel на тот же Contiv или Calico, и Storage стэк можно увеличить производительность в 8-10 раз. Правда под Storage ещё мало проектов — есть мелкие нестабильные поделки под SPDK...

Хорошим примером подобного подхода является OpenOnload, правда не знаю есть ли у них поддержка Linux Namespaces — там можна, например, заставить nginx обрабатывать 500K RPS на 40Gbit’ах, просто заменив реализацию BSD Sockets...

Дозвольте поцікавитись, які плюси ви знайшли від переписування з OCaml на JS?

Справа в тому що Facebook часто робить биті релізи flowtype.
Так як воно під форточки збирається з Cygwin’ом — банально просто glibc підтягують, збірки дуже часто відвалюються, та й воно не відрізняється стабільністью. Єдиною причиною використовувати OCaml було те що його розробник більше нічього не хотів використовувати для AST traversal’у. Зараз є 151 PR до Flowtype й невідомо хто й як їх буде опрацьовувати — таке часто буває у Faceboo’чгних проектах. Сам Facebook приділяє недостатньо уваги цьому проекту, хоча він є значною частиною їх стеку, — релізять з багами...

Загалом швидкодія Babylon’у зараз вища — суб’єктивно в 1.5-2 рази. Є купа Flowtype розробників, які плюються на його стабільність та кривий конфіг — чому б й не переписати ?...

нормализовать до 6ой нормальной формы

мамма міа...
на...пуркуа ???

Чтобы было чем процессору заняться.

Чтобы было чем процессору заняться.

Если у нас пользователь заходит на страницу, всего его данные перестраиваются в денормализованные проиндексированные материализованные представления, то размер их индексов можно сократить в 2-3 раза. Соответственно значительно снижается вычислительная сложность соответствующих запросов.

Сама по себе нормализованная схема, в особо весёлых случаях, может приводить к снижению размера таблиц в 5-6 раз. Храня копи-пасту особо на процессорных тактах не сэкономишь...

Что-то я уже запутался, говоришь про экономию места при 6-й нормальной форме и тут же про материализованные представления. Разве они не хранятся на диске? Да и место сейчас достаточно дешевый ресурс.

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

Разве они не хранятся на диске?

Хранятся, но в перепакованом виде, с отдельным набором индексов.
Т.е. там уже не b-tree, а GIN с jsonb упакованным deflate’ом...

Смысл в том что бы хранить денормализованное не для всей базы, а только для пользователей активных в последнее время. Понятное дело что если денормализовать сразу всё — толку от нормализации в 6ой форме не будет.

Например, если у нас 30 тысяч пользователей, но из них в сутки активно только 2000 имеет смысл — эти 2000 сразу перегнать в jsonb, проиндексировать, перепаковать и работать с ними... Хранить денормализованное с критерием now() - user.lastSeen > '1 month'::interval и радоваться жизни.

ты несколько лет штудировал разные доки

Скорее дней, и сразу обкатывал фичи СУБД в продакшене... Были разные «кровавые» проекты без какой-либо оптимизации с базами по 2-3Тб. Просто подобный КМБ повторялся каждые 2-3 года с новым функционалом.

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

универсальных рецептов нет

Есть лучшие практики, просто они выработаны непосредственно у разработчиков СУБД. Это прям как с keyset паджинацией, которая гораздо эфективнее, но про неё мало кто слышал и знает...

Представлен простой способ уменьшить нагрузку на чтение и сериализацию для больших проектов.

В моём случае «мозги боятся, а руки делают».
Понятное дело что без возможности отката и нормального профилирования, под нагрузкой, применение любых оптимизаций дело рисковое, и то что работает у меня может не заработать у кого-то ещё, просто, хотя бы, из-за разных окружений...

Что бы меньше места занимали таблички и индексы места на винте.
Про контролируемую денормализацию через Materialized Views уже рассказал.
Просто у большинства — ORM головного мозга, хотя сам концепт функционал существующих реляционных СУБД не покрывает.

Відповім цитатою з того ж джерела:

Essentially the ORM can handle about 80-90% of the mapping problems, but that last chunk always needs careful work by somebody who really understands how a relational database works.

От надмірну нормалізацію ORM і не покриває (або дає в результаті на виході жахливий SQL запит). Тому іноді цілком можна денормалізовувати дані, якщо це позитивно впливає на продуктивність — на даному етапі проблема

Что бы меньше места занимали таблички и индексы места на винте.

 не надто актуальна.

about 80-90% of the mapping problems

ORM’ы не маплять
* обмеження
* домени
* тригери
* представлення

Для мене, особисто, це точно не 80-90%.

не надто актуальна.

Коли працюєш з проектами по типу Discord, коли люде міняють бази кожних пів року із-за проблем з оптимизацією — доводиться вчитись усілякому.

маплять (з нюансами, звичайно).
IMHO, тут треба вибирати — або тримати бізнес-логіку в СУБД, або в application server.
Розмазування бізнес-логіки переважно несе більше проблем, чим вирішує.

або тримати бізнес-логіку в СУБД

Валідація сутностей та перетворення представлень — не є «бізнес логікою».

маплять (з нюансами, звичайно).

Можна, будь ласка, приклад ORM’у який може згенерувати CONSTRAINT і DOMAIN в DDL.

Валідація сутностей ... не є «бізнес логікою»

Я думаю, вы очень удивитесь погуглив «validation ddd», взять хотябы docs.microsoft.com/...​n-model-layer-validations. То же касается

перетворення представлень

в event-driven системах.

Почему так сложно ответить прямо на вопрос ?...
Нет, проще пытаться унизить, особенно когда есть вероятность что не прав.

У entity framework генератор DDL по шаблонам генерирует далеко не все — надо руками дописывать... Парсить схему по шаблонам он раньше не умел, домены не умеет до сих пор.

1) це таки є бізнес-логікою, як і ті ж constraint/domain
2) не бачу особливого змісту для ORM-а генерувати DDL, на мою думку його завдання забезпечувати маппінг готової реляційної моделі на готову об’єктну модель. Які на етапі розробки корегуються паралельно. Щоб з об’єктної моделі отримати від ORM-а нормальну реляційну модель для продакшн потрібно буде написати в коді стільки уточнень/анотацій, що простіше написати це в SQL DDL. Але «для тих, хто вірує в hbm2ddl » :) Hibernate щось таки генерить ( @UniqueConstraint, @Index і т.п.)

це таки є бізнес-логікою, як і ті ж constraint/domain

Мені зручніше писать нормальні two-way маппери, та не заморачуватись де там що люде називають. Тобто, грубо кажучи, створив я вьюху / обмеження — воно мені аннотацію сутності додало де треба у коді, й навпаки... просто я дійшов до того що можна повністю SQL замапить на GraphQL з ААА сервісами по лямбді.

Які на етапі розробки корегуються паралельно

Що створює купу складностей з підтримкою та версіонуванням / міграціями.

я дійшов до того що можна повністю SQL замапить на GraphQL

ті ж яйця (ще й сирі :) ), вид збоку

ААА

То ж не формат батерейок, правда? )) Розшифруйте плз

Аутентифікація, Авторизація та Акаунтинг. У телекомі є протоколи по типу Radius / Diameter / Tasacs — там доволі непогано описані відповідні моделі.

ORM-и всього лиш дозволяють автоматизувати частину роботи, яка раніше «робилась руками». Не більше і не менше. І, як всякий інструмент, мають свої недоліки.
P.S.
Якщо ж ви про те, що «нєокрепшие умы» зразу використовують ORM-и (не знаючи JDBC/SQL «під капотом» ) - фігня, кому треба, навчиться, а комусь може і не треба. А буде сильно треба — наймуть дядю, який знає — він поправить.

проблемы индейцев шерифа не волнуют ©

Из плюсов:
* В NodeJS одно из лучших API для работы с потоками. Так что если вам требуется работа с большими файлами — нода для этого очень хорошо подойдет. Глупости про однопоточность в других комментариях можете игнорировать — там мягкое с теплым путают
* Хорошая инфраструктура для микросервисов. Позволит переходить плавно а не резко
* Сравнительно быстрая разработка

Из нейтрального:
* Чат писать можно абсолютно на чем угодно — особо разници не будет

Из минусов:
* Найти нормальных специалистов, конечно, проще чем на Erlang, но сложнее чем на почти что угодно другое из меинстрима. Ситуация у вас с поиском улучшится, но с той-же Java собрать команду будет быстрее. И это при том что кандидатов будет много — сложность в том что непосредственно с NodeJS хороший опыт имеет малая часть тех кто на JS пишет

В общем могу советовать переходить только если у вас уже есть, или знаете где взять, кого-то кто реально хорош в ноде и закроет вам пункт 3 об архитектуре. Так как никакой архитектуры сама по себе нода не навязывает написать полную хрень будет намного проще чем на других платформах, если не знать как правильно (или хотя-бы как не правильно)

Спасибо за ответ, полезно!

Так как никакой архитектуры сама по себе нода не навязывает написать полную хрень будет намного проще чем на других платформах, если не знать как правильно (или хотя-бы как не правильно)

Плюсую.

1. не знаю какая у вас финансовая ситуация, но имхо для стартапа переписывание всего бекенда не супер идея. лучше переходить на микросервисы и понемногу куски переписывать. к тому же нода все таки сомнительный выбор по сравнению с эликсиром например. он простой, удобный и тоже на beam работает
еще сильно зависит от того, что у вас там, например если вы мнезию используете как бд, то еще геморней может быть переход
2. подходит, во всяком случае на ноде это можно сделать, хотя возможно это и не самое эффективное решение. главное при работе с большими файлами не забывать, что нода однопоточная и если функцию требующую много времени на выполнение не разбивать с помощью nextTick и не использовать кластер, то можно сильно всё подвесить. и стоит не забывать пользоваться стримами по возможности для работы с файлами. в остальном масштабируется может и не так просто как BEAM, но ± можно.
3. имхо никакой архитектурной специфики для ноды нет, можно обычные микросервисы делать со всякими grpc
4. минус это js — постоянные (undefined is not a function и Cannot read property ’*’ of null) поэтому возможно стоит подумать о typescript или flow, но хотя бы колбеков можно избежать благодаря async/await

Спасибо за развернутый ответ. Я еще его покажу нашему девелоперу и возможно задам еще вопросы.

для чата и коментариев нода подходит она для такого и создавалась. Для остального возьмите нормальный бекенд а не очередную экзотику

я один еще помню времена (пару лет назад) когда при упоминании ноды у всех жаваскриптологов случался оргазм?

Ок, а файлы как раз у нас на Azure, тут нагрузки нет у нас. Если чат, комменты стреляют ок, то где тогда проблема в node.js?

Проблема в ее архитектуре. Нода была спроектирована для обработки множества мелких ответов в одном потоке. Потом ее начали пытаться превращать в полноценный бекенд но ничего путного этого не вышло. Так же как ничего путного не вышло например с недавним хайпом вокруг NoSql баз.

поймите свои требования, умножте их на 2-10 и наймите, наконец, архитектора
только не жабаскриптолога, а то он вам все нажабасктрипте перепишет
а нода, она хоть и на плюсах написана, непонятно что там с мультизадачностью

Як на мене, то перехід на nodejs це кілька кроків назад.
Ви хочете вкластись в короткострокову перспективу. Проекти на erlang порівняно легше дебажити.
Спробуйте Elixir (запіліть якийсь блог, туторіал пройдіть). Сьогодні людей зацікавлених в ньому більше. Вони на одній віртуальній машині крутяться, можна без проблем існуючі модулі erlang використовувати і навпаки.

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

Іншої відповіді від js developer не варто було очікувати.

Список літератури — «27301 залежностей в проекті на ноді ніяк не впливають на безпеку, та інші жарти».
Кожен раз нестримно сміюсь, як згадую лефтпад і тролінги типу цих:
pypi.python.org/pypi/left-pad , rubygems.org/...​s/left-pad/versions/1.0.0

очередной комментатор, который о жс знает только шутеечки

Откуда вы все беретесь? Зависимость — это всегда риск если не безопасности, то ошибок. Это совершенно не зависит от языка. И никто не мешает не использовать вообще ничего и писать всё самому, основываясь только на стандартном API. И это приведет к контролю над каждой строкой кода и (возможно) стабильности, но также к

Очень долго пилим функции, медленно проводим эксперименты по продукту

Нажаль статистика показує, що пітонщики і рубісти не пилять такі модулі, а знають стандартні бібліотеки мови.
Це я до якості проекту, якою вона буде, коли дуже швидко набрати команду на ноді з вчорашніх фронтендерів, які на питання як в js додати 2+2 відповідали «є jQuery плагін для цього». Це Óбразно звичайно ж.

Толкових нодщиків буде реально набрати, звичайно ж, але не варто сподіватись, що дуже швидко.

А по ділу — найзмістовнішою є відповідь Bohdan Chechin

Да, правда написали

очередной комментатор, который о жс знает только шутеечки

Выдаёте на гора какой-то набор стереотипов, а по сути ноль.

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

Не нанимайте сомнительных личностей, в чем проблема?

Також порекомендую дуже файний фреймворк на Elixir : phoenixframework.org, але навіть на Erlang є подібні рішення zotonic.com.

Звичайно, можна переписати і на базі іншої платформі (PHP, NodeJS, Ruby, Python ...), але треба найти перевіреного професіонала у команду, щоб не зруйнувати наявний сервіс.

Подписаться на комментарии