Вхід і реєстрація
Розробка · 12 квітня 2018, 23:04 7283
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?

Відповісти
Підтримати
Юрій Ярош developer в bitsnap 16.04.2018 18:12

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

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

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

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

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

Відповісти
Підтримати
Grez
Юрій Ярош developer в bitsnap 16.04.2018 18:13

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 18:41

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

Відповісти
Підтримати
Vlad Stelmahovsky
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
Юрій Ярош developer в bitsnap 14.04.2018 20:27

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

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

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

Відповісти
Підтримати
Artur Plysiuk
Юрій Ярош developer в bitsnap 14.04.2018 21:41
не сможет стать бэкендщиком (фул-стек разработчиком)?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Відповісти
Підтримати
Ivan Talaychuk
Юрій Ярош developer в bitsnap 14.04.2018 20:24

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

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

Відповісти
Підтримати
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
Юрій Ярош developer в bitsnap 14.04.2018 14:15

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

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

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

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

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

Відповісти
Підтримати
Artyom Krivokrisenko
Юрій Ярош developer в bitsnap 14.04.2018 18:19

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

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

www.cppwebframework.com

Відповісти
Підтримати
Юрій Ярош
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 потеряли гибкость/скорость в разработке и поиске сотрудников. (кстати ищем соучредителя СТО, доля в компании тоже кофаундерская). Очень долго пилим функции, медленно проводим эксперименты по продукту + найти заветного соучредителя СТО практически невозможно.

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

Відповісти
Підтримати
Юрій Ярош developer в bitsnap 14.04.2018 14:19
может стоит посмотреть на что-нибудь более мейнстримное?

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

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

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

Відповісти
Підтримати
Леголас Трандуилович
Юрій Ярош developer в bitsnap 14.04.2018 16:39

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 паджинация говно — напрочь отсутствует. Об этом довольно неплохо написано, например, вот здесь Маркусом.

Відповісти
Підтримати
Андрей Литвинов
Vlad Stelmahovsky Software Engineer в Verity AG 14.04.2018 16:43

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 16:54

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 17:01

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 17:15

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

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

Відповісти
Підтримати
Андрей Литвинов
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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 15:12

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

Відповісти
Підтримати
Олекса **
Dmitry Bugay Java Team Lead 17.04.2018 00:49

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 17:12

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 20:40

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 21:44

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 21:20

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

Відповісти
Підтримати
Aleksandr Anokhin
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 для создания сущности использовал))

Відповісти
Підтримати
Юрій Ярош
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?

Відповісти
Підтримати
Максим Веденеев
Юрій Ярош developer в bitsnap 14.04.2018 20:29

-

Максим Веденеев 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
Юрій Ярош developer в bitsnap 13.04.2018 16:29
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.

Відповісти
Підтримати
Юрій Ярош developer в bitsnap 14.04.2018 01:30
Через self-employed та не закінчений вуз

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

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

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

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

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 03:38

Говорю ж — помойка...

Відповісти
Підтримати
Кодерок
Юрій Ярош developer в bitsnap 14.04.2018 18:17
Це все що завгодно, але не популярні мови(принаймі в Україні).

Бекенд українського ПриватБанку написаний на 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...

Відповісти
Підтримати
anonymous
Юрій Ярош developer в bitsnap 16.04.2018 18:42

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 20:38

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

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 14:23

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 14:37

Если сильно переживаете за производительность чатика — можете оформить его на 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...

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 14.04.2018 12:12

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

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

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

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

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

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

Відповісти
Підтримати
Vitaliy Fedoriv
Юрій Ярош developer в bitsnap 16.04.2018 14:31
Чтобы было чем процессору заняться.

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 14:44
Разве они не хранятся на диске?

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

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 15:10
универсальных рецептов нет

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

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

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

Відповісти
Підтримати
Андрей Литвинов
Юрій Ярош developer в bitsnap 16.04.2018 14:28

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 16:10
about 80-90% of the mapping problems

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 17:25
або тримати бізнес-логіку в СУБД

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

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 18:47

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 16.04.2018 21:56
це таки є бізнес-логікою, як і ті ж constraint/domain

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

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

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

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

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

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

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

Відповісти
Підтримати
Юрій Ярош
Юрій Ярош developer в bitsnap 17.04.2018 12:58

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

Відповісти
Підтримати
Олекса **
Vitaliy Fedoriv Java Developer 16.04.2018 21:03

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

Відповісти
Підтримати
anonymous
Юрій Ярош developer в bitsnap 16.04.2018 21:56

Дуже відповідально ...

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

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

Відповісти
Підтримати
Юрій Ярош
Aleksey _ 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

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

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