Вхід і реєстрація
Розробка · 12 квітня 2018, 23:04 7299
Ivan Talaychuk, Co-founder, CEO в Pibox.com

Нужна помощь: Перевод бэкенда проекта с 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 крутой по-своему, но у нас в коде/архитектуре есть проблемы и все равно надо многое переписывать, так что если с нуля то переходить на что-то менее хардкорное.

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті

Теми: Erlang, node.js
👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Владимир Кожаев 14.04.2018 20:30

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

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

Перейти до дискусії
Artur Plysiuk 13.04.2018 08:39

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

Перейти до дискусії
anonymous 14.04.2018 13:14

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

Перейти до дискусії
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 18.04.2018 00:56

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

Відповісти
Підтримати
minodvesP Vasya 17.04.2018 20:46

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

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

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

Відповісти
Підтримати
Дима Дима 16.04.2018 16:41

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

Відповісти
Підтримати
Grez 16.04.2018 16:31

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

Відповісти
Підтримати
Vlad Stelmahovsky Software Engineer в Verity AG 16.04.2018 17:04

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

Відповісти
Підтримати
Grez
Vlad Stelmahovsky Software Engineer в Verity AG 16.04.2018 18:18

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

Відповісти
Підтримати
anonymous
Grez 17.04.2018 00:42

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

Відповісти
Підтримати
Vlad Stelmahovsky
Vlad Stelmahovsky Software Engineer в Verity AG 17.04.2018 09:14

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

Відповісти
Підтримати
Grez
Vlad Stelmahovsky Software Engineer в Verity AG 17.04.2018 14:04
или разобраться с новой трендовой технологией, которая приносит лаве.
и заливать какой ты окуенный спец
Відповісти
Підтримати
anonymous
Iliya Isd Software Engineer 16.04.2018 15:27

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 16.04.2018 23:19

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

Відповісти
Підтримати
Iliya Isd
schwarzlichtbezirk 15.04.2018 14:26

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 21:31

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

Відповісти
Підтримати
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 14.04.2018 22:33
И если уже переписывать то на что-то более гибкое.

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

Відповісти
Підтримати
Ivan Talaychuk
Bogdan Shyiak SE or Dev 14.04.2018 22:49
Я категорически не согласен с претензиями к гибкости Erlang.
используя Erlang потеряли гибкость/скорость в разработке и поиске сотрудников.

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

Відповісти
Підтримати
Vitaly Chernooky
Владимир Кожаев 14.04.2018 20:30

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

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

Відповісти
Підтримати
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 14.04.2018 17:40

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 19:12

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

Відповісти
Підтримати
Vitaly Chernooky
Artur Plysiuk Працює в proSapient 14.04.2018 19:20

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

Відповісти
Підтримати
Ivan Talaychuk
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 21:21

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

Відповісти
Підтримати
Artur Plysiuk
Андрей Литвинов C Señor 14.04.2018 22:00

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

Відповісти
Підтримати
anonymous
Vlad Stelmahovsky Software Engineer в Verity AG 16.04.2018 11:08
удет использовать «псевдо-оптимальные» решения что бы «быстро выкатить»

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

Відповісти
Підтримати
anonymous
Gennady Dogaev full-stack web developer (freelance) 14.04.2018 22:39

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

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

Відповісти
Підтримати
Ivan Talaychuk
anonymous 14.04.2018 13:14

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

Відповісти
Підтримати
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 18.04.2018 00:59

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

Відповісти
Підтримати
anonymous
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 14.04.2018 17:41

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

Відповісти
Підтримати
Artyom Krivokrisenko
Alex Fogol Software Developer, C/C++ Expert 14.04.2018 21:57
У Rust’a есть вэб-фреймворки

www.cppwebframework.com

Відповісти
Підтримати
anonymous
Yuriy Pitometsu Оглаголиватель существительных 15.04.2018 05:17

Haskell или Scala?

Відповісти
Підтримати
Artyom Krivokrisenko
Grez 16.04.2018 16:24

Тгда уже Erlang.

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

Відповісти
Підтримати
Yuriy Pitometsu
Леголас Трандуилович 14.04.2018 12:51
Короче говоря, сейчас мы понимаем, что используя Erlang потеряли гибкость/скорость в разработке и поиске сотрудников. (кстати ищем соучредителя СТО, доля в компании тоже кофаундерская). Очень долго пилим функции, медленно проводим эксперименты по продукту + найти заветного соучредителя СТО практически невозможно.

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

Відповісти
Підтримати
Андрей Литвинов C Señor 14.04.2018 16:04
99% галерных гребцов не знают что такое REST

Відповісти
Підтримати
anonymous
Vlad Stelmahovsky Software Engineer в Verity AG 14.04.2018 16:43

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 14.04.2018 16:53

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 14.04.2018 17:10

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

Відповісти
Підтримати
anonymous
Bogdan Shyiak SE or Dev 14.04.2018 22:07
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

Відповісти
Підтримати
anonymous
Dmitry Bugay Java Team Lead 17.04.2018 00:49

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

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

Відповісти
Підтримати
anonymous
Oleksandr Tkalenko . 14.04.2018 20:03
тут можно целую серию статей написать про REST...

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

Відповісти
Підтримати
anonymous
Oleksandr Tkalenko . 14.04.2018 21:14
так что и статьи про него куда-то буду писать

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

Відповісти
Підтримати
anonymous
Aleksandr Anokhin Software Engineer в WP 16.04.2018 20:03
но он пока не отличается стабильностью — вот переписываю на JS.

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

Відповісти
Підтримати
anonymous
Bogdan Shyiak SE or Dev 14.04.2018 22:08
Я бы, кстати, почитал.

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

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

Відповісти
Підтримати
Oleksandr Tkalenko
anonymous 15.04.2018 02:15
99% галерных гребцов не знают что такое REST и плодят копи-пасту с CRUD контроллеров.

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

Відповісти
Підтримати
anonymous
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 19:09

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

Відповісти
Підтримати
Леголас Трандуилович
Андрей Литвинов C Señor 14.04.2018 20:24

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

Відповісти
Підтримати
Ivan Talaychuk
Леголас Трандуилович 14.04.2018 20:53

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

Відповісти
Підтримати
Ivan Talaychuk
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 21:25

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

Відповісти
Підтримати
Леголас Трандуилович
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 21:28

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

Відповісти
Підтримати
Ivan Talaychuk
Леголас Трандуилович 15.04.2018 09:28
и скорее всего на node.js и с этим человеком это будет быстрее.

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

Відповісти
Підтримати
Ivan Talaychuk
Максим Веденеев TeamLead Frontend 14.04.2018 08:18

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

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

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

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

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

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

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

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 14.04.2018 19:13

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

Відповісти
Підтримати
Максим Веденеев
Максим Веденеев TeamLead Frontend 22.05.2018 15:13

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

Відповісти
Підтримати
Ivan Talaychuk
Serge Rybalchenko Software Engineer в ENVISIONX 24.04.2018 19:06
Я не бекегд, фронт. Работаю с фаирьейсом. Бекегд вообще не нужен, работает все плюс минус хорошо. Если нагрузок нет то проблем возникнуть не должно.

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

Відповісти
Підтримати
Максим Веденеев
Alex Fogol Software Developer, C/C++ Expert 25.04.2018 11:07
Если нагрузок нет то проблем возникнуть не должно

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

Відповісти
Підтримати
Serge Rybalchenko
Максим Веденеев TeamLead Frontend 22.05.2018 15:18

>

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

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

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

Відповісти
Підтримати
Serge Rybalchenko
Кодерок 14.04.2018 01:44
більшість контрактів під NDA

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

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

Відповісти
Підтримати
anonymous
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 14.04.2018 20:33
в HashiCorp

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

Відповісти
Підтримати
anonymous
Tim Tretyak ASM, TS Consultant в Hewlett Packard Enterprise 15.04.2018 22:20

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

Відповісти
Підтримати
anonymous
anonymous 16.04.2018 10:30
например, Consul с K8S подружить довольно большой и сложный квест.

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

Відповісти
Підтримати
anonymous
Ivan Talaychuk Co-founder, CEO в Pibox.com 13.04.2018 22:31

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

Відповісти
Підтримати
anonymous
Artur Plysiuk Працює в proSapient 14.04.2018 07:23

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 12:33
нормализовать до 6ой нормальной формы

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 16.04.2018 12:38

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

Відповісти
Підтримати
Vitaliy Fedoriv
Андрей Литвинов C Señor 16.04.2018 14:35

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

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 16.04.2018 14:51

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 16:00

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

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 запит). Тому іноді цілком можна денормалізовувати дані, якщо це позитивно впливає на продуктивність — на даному етапі проблема

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

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 16:56

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

Відповісти
Підтримати
anonymous
Андрей Литвинов C Señor 16.04.2018 17:38
Валідація сутностей ... не є «бізнес логікою»

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

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

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 20:41

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 22:38
я дійшов до того що можна повністю SQL замапить на GraphQL

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

Відповісти
Підтримати
anonymous
Олекса ** 17.04.2018 10:54
ААА

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 21:03

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

Відповісти
Підтримати
anonymous
Vitaliy Fedoriv Java Developer 16.04.2018 22:49

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

Відповісти
Підтримати
anonymous
Aleksey Senior SWE в Meta Platforms, Inc. 13.04.2018 15:06

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

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

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

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 13.04.2018 22:45

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

Відповісти
Підтримати
Aleksey
Vitaly Chernooky C, Embedded and Linux в Self-Emplyed 14.04.2018 17:45
Так как никакой архитектуры сама по себе нода не навязывает написать полную хрень будет намного проще чем на других платформах, если не знать как правильно (или хотя-бы как не правильно)

Плюсую.

Відповісти
Підтримати
Aleksey
anonymous 13.04.2018 13:09

Коментар порушує правила спільноти і видалений модераторами.

Bohdan Chechyn SSE 13.04.2018 12:39

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

Відповісти
Підтримати
Ivan Talaychuk Co-founder, CEO в Pibox.com 13.04.2018 14:16

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

Відповісти
Підтримати
Bohdan Chechyn
Леонид Мартынюк инженер-программист в 1World online R&D Сenter 13.04.2018 12:26

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

Відповісти
Підтримати
Vlad Stelmahovsky Software Engineer в Verity AG 13.04.2018 13:28

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

Відповісти
Підтримати
Леонид Мартынюк
Ivan Talaychuk Co-founder, CEO в Pibox.com 13.04.2018 14:23

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

Відповісти
Підтримати
Леонид Мартынюк
Леонид Мартынюк инженер-программист в 1World online R&D Сenter 13.04.2018 14:49

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

Відповісти
Підтримати
Ivan Talaychuk
Vlad Stelmahovsky Software Engineer в Verity AG 13.04.2018 10:39

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

Відповісти
Підтримати
Artur Plysiuk Працює в proSapient 13.04.2018 08:39

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

Відповісти
Підтримати
Alik Ovsepian js developer – Lucky Labs 13.04.2018 09:14

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

Відповісти
Підтримати
Artur Plysiuk
Andriy Kupchanko 13.04.2018 10:30

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

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

Відповісти
Підтримати
Alik Ovsepian
Ivan Tumanov JS Dev 13.04.2018 12:24

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

Відповісти
Підтримати
Andriy Kupchanko
Gennady Dogaev full-stack web developer (freelance) 13.04.2018 13:25

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

Очень долго пилим функции, медленно проводим эксперименты по продукту
Відповісти
Підтримати
Andriy Kupchanko
Andriy Kupchanko 13.04.2018 13:35

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

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

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

Відповісти
Підтримати
Gennady Dogaev
Gennady Dogaev full-stack web developer (freelance) 13.04.2018 13:56

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

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

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

Відповісти
Підтримати
Andriy Kupchanko
Sergei Epatov Staff RnD Engineer в Apptopia 13.04.2018 17:59

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

Відповісти
Підтримати
Gennady Dogaev
Gennady Dogaev full-stack web developer (freelance) 13.04.2018 18:54

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

Відповісти
Підтримати
Sergei Epatov
Fedir RYKHTIK Сам собі режисер в Челобака Corp. 13.04.2018 13:34

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

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

Відповісти
Підтримати
Artur Plysiuk

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

Не підписуватись
Скористайтесь акаунтом
×
з умовами використання сайту і політикою конфіденційності.