отговорите: (nodejs) vue.js + express + pg-promise + postgresql + docker

только js сразу меняй на ts

А почему бы сразу не на жабу? 🤔

жаба в браузер не умеет без костылей

А вот на сервер жс пихать мне были бы нужны веские основания.

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

настоятельно не рекомендую писать бизнес логику на pl/pgSQL.

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

Есть у меня один знакомый. Торчит на работе за 30к рублей, мечтает вкатиться на удаленку / фриланс. И вот уже 2 года как на может выбрать технологии... Ну не глупость ?

Если по делу. Твоя связка окей. Сам использую такую для небольших сервисов. Если что-то сложнее, то беру Python. Там где питон немного не тянет, переписываю на Golang.

Если проект очень большой, то тут лучше Java, без вариантов.

p.s. вчера посмотрел видео от JetBrains. Они очень сильно развивают Kotlin. По сути это один язык который компилируется во все что можно. Сейчас они поддерживают на продакшен уровне платформы: JVM, Javascript, Android, iOS. Меня немного это зацепило. Они предложили очень крутую идею шаринга кода между фронтом / веб-приложением и сервером. Причем не на таком тупом уровне как в Meteor / NodeJS. А серъезно озадачились и сделали модули, которые можно подключать и там и там. Планирую смотреть в эту сторону, возможно и тебе стоит. Но это только мое мнение.

Почему?

настоятельно не рекомендую писать бизнес логику на pl/pgSQL.

Поддерживаю. Отладка и обновление хранимых процедур это отдельный ад.

Я читал, что у Котлина слишком тяжёлый рантайм для JS. Как твоё мнение, он дейтсвительно жизненен? Насчют того, что он во всё компилируется, не надо строить иллюзий. Программы всё равно исполняются на конкретной платформе и проблемы будут специфичные для платформы. Т.е. знание платформы понадобится + стоимость лишнего слоя. Не факт, что будет какой-то профит. Есть уже haxe, и что? Были трансляторы Java<->Js, и тоже об их успехе мало слышно.

А вообще зря я упомянул про TS. Буду писать на ваниле, пока не освою. Без find definition придётся потерпеть.

А писать логику на pl/pgSQL для меня имеет смысл. Во-первых, есть большой аналогичный опыт на MSSQL и Firebird. Во-вторых, если веб не пойдёт, буду искать себя в области Postgres.

Понял, спасибо. Я в принципе посмотрел - под отдельные элементы этого стека много вакансий. Под стек целиком не смотрел. Насчёт допиливания и мелких заказов - это совсем другая стратегия. Она требует более высокой квалификации, поэтому начинать с неё неразумно. Я буду делать всё в 10 раз медленнее, чем ты, и не у кого будет научиться.

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

писать логику на pl/pgSQL для меня имеет смысл. Во-первых, есть большой аналогичный опыт на MSSQL и Firebird

Аааа! Я про то и говорил вчера — сделать хер пойми что на хер пойми чем. Ты делаешь успехи. Поздравляю!

А смысл писать на жаваскрипте там, где на нем можно не писать?

Два смузи этому адеквату.

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

Ну вообще если ты хочешь об этом поговорить, SQL - это декларативный язык. Реляционная парадигма мощнее объектной, т.к. более высокоуровневая. Оптимизатор запросов позволяет отделить суть алгоритма от реализации, а сам sql обычно весьма компактен. Компилятор статически проверяет тип объектов и переменных (лучше JS). Структура предметной области видна по структуре таблиц. Автоматическое управление памятью, простое и ясное. Отличная рефлексия. Плюс к тому, производительность на порядок-два выше, чем у каких-нибудь ORM-ов. Ясная, мощная и хорошо документированная модель параллельности. Средства контроля параллельности. Встроенная персистентность.

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

Жаль только, что в pg нет эрзац-корутин, как в Firebird.

Реляционная парадигма

Она не единственная. Прими микстурку mongodb например.

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

Ты не там ищешь выгоду.

Структура предметной области видна по структуре таблиц

Ога )) Что чуть сложнее бложика, так сразу начнешь искать где бы не сильно нарушить нормальную форму и сдблировать что-то ради легкого доступа.

управление памятью

Вебер срал на память. Все о чем он думает это сфетчить результат выборки в цикле.

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

На лошади тоже приятнее чем на мотоцикле. И тебя никто не заставляет юзать ОРМ, можно и прямые запросы писать, твои любимые.

Пора переходить в 2018. В современном мире JS это как ассемблер. Ты когда пишешь код на сишарпе например вникаешь что так CLR сгенерировало на уровне ассемблерного кода ? Я думаю нет.

Я не агетирую за Kotlin, просто предложил вектор движения. Над SQL/plPgSQL я бы не стал сидеть. За это просто сейчас очень мало платят. Час работы программиста дороже, чем условное увеличение памяти на сервере, да и память теперь стоит копейки.

Я мегабайты кода на SQL написал, т.е. я её там не ищу, а уже давно нашёл :) Лёгкий доступ делается вьюхами, а где они не годятся, я придумал свои макросы для SQL. Для управления жизненным циклом базы тоже есть решения (у меня самописка, но и на рынке что-то есть).

И тебя никто не заставляет юзать ОРМ

Это я просто к тому, что есть мнение о том, что СУБД нужна только для хранения данных, как слой персистентности, а над ней нужно наворотить многоэтажное чудище, и в итоге получить меньше и хуже, чем может сам SQL, за бОльшие деньги.

Пока этот ассемблер работает, вникать не нужно. А когда сломается - нужно.

Я не агетирую за Kotlin

А я не агитирую против, я просто спросил, что ты думаешь об этом.

тебя никто не заставляет юзать ОРМ, можно и прямые запросы писать

Вы так говорите, будто для ноды существует какой-то вменяемый ORM. В его случае как раз выгоднее таки налечь на хранимки, ведь это его конек. Возможно единственное конкурентное преимущество Дэна перед стаей макак - умение написать эффективный слой работы с данными. Нужно этим пользоваться конечно же, а не сливаться с толпой неосиляторов РСУБД.

наворотить многоэтажное чудище, и в итоге получить меньше и хуже, чем может сам SQL, за бОльшие деньги.

Да, это из серии «как нам обернуть высокоуровневые средства в низкоуровневую лапшу». Макака-вей. В вебе, к сожалению, очень популярен.

Я планирую посмотреть на Котлин более пристально. В своем время присматривался к Scala. За 2 года работы с ней особого профита не получил, а лишь сложность. Да кода стало меньше, но модель типов в Scala ужасна. Пока Kotlin выглядит как меньшее из зол.

т.е. я её там не ищу, а уже давно нашёл
я придумал свои макросы для SQL

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

многоэтажное чудище

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

Возможно. Но его никто не поймет.

mongodb

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

А разве его система типов не из java?

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

В целом же человек маленький, а мир большой. В молодости человек быстро растёт и, думая, что он будет жить вечно, ему кажется возможным захватить или хотя бы познать весь мир. Со временем становится ясно, что это не так. Я в целом довольно равнодушен к технологиям, особенно к современным. Раньше делали лучше. ПОэтому мне по барабану, хороша ли монгодб. Узнать ради интереса можно, но очевидно, что она не является необходимостью.

И над этим аргументом тоже

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

Кроме тупых геттеров-сеттеров которые ты хочешь налабать на сикелях, тебе нужны: права доступа пользаков, валидаторы, вьюхи, формы, контроллеры, роутинг, многоязычность

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

всеравно останешься при своем мнени

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

Ой даладна, монга в тренде же. Вернее так — она нужна когда сикель уже не справляется. Причина её появления — хотелки эффективных менеджеров внутри продуктов, которыми они пользуются. Мир гораздо сложнее реляционки.

И не обижайся что я тебя тугим назвал. Мне 35 и я знаю о тугости не по наслышке и постоянно с собой борюсь.

Джавовская с кучей дополнений и не всегда совместимая обратно.

Я вообще не сторонник ОРМа, если что. Поэтому и сказал ему если хочет то пусть пишет запросы вручную. Ты как-то не туда прикопался.

А ты не борись. Ты научись с этим сживаться и быть эффективным, невзирая на это. Ты всё равно не будешь столь же быстр, как в молодости.

Я смотрю на hh.ru, по монге 300 вакансий, по слову nosql - 300, по sql - 4800. Если искать «программист X», то для X = sql - 300, для X = mongodb - 0. Мне с моим SQL бояться пока нечего :)

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

я не совсем понимаю, что понимается под галерами

Галера условно это бодишоп, т.е. тебя продают заказчику в 3-10 раз(а) дороже. Какой там стек у заказчика узнаешь потом. Грести надо сразу и всем пофигу что ты первый раз в жизни увидел например elasticsearch. 1 час на гугление и гребем. Потом другой проект и т.д.

Если такое не нравится, а нравится это определенно не может, то лучше идти в продуктовую компанию. Но и там свои проблемы.

Тебя перестанет это кормить, т.к. веб — самый быстро развивающийся. Там все меняется. Не будет о том насколько эффективны новые решения. Оно просто меняется. Если ты не будешь за трендами следить, то очень быстро останешься на задворках.

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

Значит я не распарсил контекст, извини. Но все что ты написал не составляет большой сложности, если это нормальные компоненты, а не один большой ком, накрученный на орме.

Я смотрю на hh.ru, по монге 300 вакансий, по слову nosql - 300, по sql - 4800.

Хайп nosql уже давно прошел, забудь. Их помножили на ноль когда стали доступны дешевые SSD на серверах. Ясно, что у тупых хранилищ область применения очень ограничена.

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

Потому я думаю так: пусть пишет без ОРМ (это вне контекста ноды, может он захочет на пыхе), но с осторожностью и без фанатизма перетащить по максимуму все в сикель.

Хайп по NoSQL прошел да, и начался новый хайп по NewSQL. Это такие NoSQL базы с SQL-пободным языком поверх и нормальными транзакциями. Типа как ArangoDB, RethinkDB...

Так хаха их выискивает во всём теле вакансии. Что, нет разве? Даже если технологии и умрут, из всех можно выбирать какую-то одну. Ну и в любом случае, необязательно идти по всем граблям, можно ведь некоторые ходы пропускать. После того, как технология вышла из моды, она ещё может долго жить. Не знаю, как в вебе, а на какой-нибудь перл всё ещё есть спрос. Может быть, я зря выбрал вуй - он слишком сырой. Может быть, нужно выбирать технологии, которые уже расцвели - производительность труда на них выше. Ну ничего, значит переучусь на реакт - всё равно я этот вуй ещё освоил процентов на 20 только.

Реакт тебя сильно разочарует

Почему выбрать инструмент А вместо Б? Почему рассматривались только А и Б хотя есть еще В, Г, Д, Е Ж, З , И, К? А потому что только А и Б максимально клеются к задаче, но у них сильно разные подходы. Остальные инструменты тоже могли бы решить задачу, но менее эффективно. И ты не можешь выбрать что-то одно — это все сосуществует и взаимодействует между собой.

Тебе говорят — бери А. Потому что мы знаем 10-20 инструментов. Ты говоришь — я хочу взять Б. Потому что знаю только Б. Чуешь где подвох?

Не знаю, как в вебе

В том то и дело. А я там семь лет проварился. Про вуй и реакт уже сказали.

Вот я нашёл про postgres. https://habrahabr.ru/company/pgdayrussia/blog/326758/ Сам, правда, не читал целиком. Могу подтвердить, что почти во всех местах, где я работал, бизнес-логика на хранимках, и они существуют с начала 90-х по сей день, не разорившись :)

Это зависит от задачи.

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

Ну слушай, за mongodb меня не заагитируешь :) По поводу остального - есть варианты. Но в любом случае из ряда достаточно брать одно. В случае вуя всё просто: реакт, ангуляр и вуй вроде ставят в один ряд, хотя я знаю, что они разные. Ангуляр вроде на спаде, реакт в пике, вуй растёт, но спрос пока мал. Если я не промахнусь, то я буду расти вместе с ним и через год попаду в самую моду. Могу и промахнуться.

С начала 90-х не было монги. На безрыбье и рак рыба.

Я не защищаю конкретно монгу, это просто как пример в контексте нашего разговора.

Я знавал одного чела, в те времена ему было уже почти 40, он все вхреначил в хранимки мускуля, а на пыхе лепил:

echo "<tr><td>";

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

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

На хабре была статья, как с ngix прямо в постгрес запросы слать. Т.е. node.js не нужен.

Там пишут что можно и зубы через задний проход рвать. Ну так, потому что можно.

Но та статья выгдядела здраво. Особенно в сравнении с JavaScript.

Я с метапрограммированием на ты, наигрался со всякими макрогенераторами. По невежеству изобрёл свой json, свой data-driven подход к метаданным, генераторы приложений, все дела. Так вот после всего этого оказывается, что иногда echo <tr><td> - проще во всех отношениях, включая поддержку.