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

Писать комментарии к коду на русском языке считается дурным тоном

На галерах - может быть. А некоторые заказчики требуют именно на русском.

Спасибо. Не секрет ли - кто эти некоторые заказчики, хотя бы из какой области?

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

Может и правда, ну её, нодку.

Так тебе и на всем другом тоже самое надо будет делать. xD
Вообще под каждый твой термин генерить статик файл это можно сделать, но не нужно. Я бы просто на любой термин отдавал 1 и ту же страницу, а уже после загрузки она брала из url название термина и через ajax получала его с сервера.
https://nuxtjs.org/guide/routing#dynamic-routes
https://nuxtjs.org/api/configuration-generate#routes

Этот веб что-то всё время похож на то, что меня душат-душат, а я как-то вырываюсь.

Нет, это ты сам натягиваешь сову на глобус. Твоя задача вытащить данные из базы, сгенерить страницу по шаблону и отдать клиенту. Классика. Но ты тянешь вуй, который вообще-то для SPA. Еще раз раскури что есть SPA: это _одна_ страница со скриптами, из которых асинхронно тянутся данные с сервера и строятся ветви DOM. Зачем такое нужно? Для быстрого обновления на лету, самый очевидный пример - чат. Нужно ли такое для обычного документа? Очевидно, нет. Даже если тебе нужно где-то достраивать DOM динамически, ты можешь подтягивать аяксом готовые фрагменты HTML. Еще раз почитай внимательно что есть AJAX. Никакие вуи для твоей задачи не нужны, если кто-то применяет их бездумно везде, знай - это жертвы абортахайпа.

Может и правда, ну её, нодку.

Может попробуешь таки PHP. Вот не очень понятна твоя неприязнь. Может у тебя отрыжка со времен php3, но сейчас это язык ничем не хуже других скриптовых. Если надумаешь, смотри сразу laravel чтобы не бегать по граблям.

Vue не обязательно для SPA. И сейчас бы ручками DOM трогать когда есть Vue.

Я купился исключительно на однофайловые компоненты с правильным синтаксисом, html, а не pug(jade), которые содержат в себе и стиль, и код, и разметку. Я считаю, что это правильно и из модного нашёл такое только в vue. Но ввиду неортогональности их остальным фичам вуя их не получается (с трудом получается) использовать, если страница генерируется на сервере и, к примеру, если данный кусок содержит только статику (как хлебные крошки для статической страницы). Я бы сказал, что SSR - это неправильный подход, он подразумевает, что мы сначала всё делаем на клиенте, а потом как бы оптимизируем, делая часть этого же на сервере. Где, естественно, другой расклад, отчего возникают усложнения. Плюс к тому, вуй создаёт красивую модель декларативного программирования и она работает, пока мы рендерим на клиенте. Но она перечёркивается дефицитом проверок. Я уже налетал на то, что если в конфигурации компонента сделать опечатку, никто тебе ничего не скажет - просто молча будет работать неправильно. При переходе к SSR некоторые события просто молча не будут вызываться и красивая декларативная модель (которая немало стоит по сложности) внезапно сломается и перестанет работать. Итогом чего станет необходимость отлаживать не своё простое приложение, а сложный вуй. Т.е., как минимум, приложение под SSR должно изначально проектироваться с учётом SSR. А тогда нафига делать вид, что это имитация клиентского рендеринга? Это просто другая технология.

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

Плюс к тому - тормозной JS при сборке уже меня достаёт, хотя мой проект ещё очень маленький. Что же будет для взрослых приложений?

Про SPA я примерно понял уже, спасибо.

Да, и плюс к тому есть слишком много способов сборки: dev, prod, ssr, генерация статического сайта. Т.е. сложность, вероятность ошибок, трудоёмкость тестирования и количество ограничений в вуе вдвое больше, чем для «обычной» технологии, подразумевающей только dev и prod.

Дело не в неприязни. Просто я разрабатываю свой ЯП и поэтому мне интересен JS. Плюс экономлю усилия. Два языка - это две экосистемы, а это бОльшие трудозатраты на обучение и поддержание квалификации. Но допустим, мне не нужен вуй. Есть ли аналог PHP/lavarel для nodeJS?

А какие у Vue ограничения? И зачем ты постоянно проект собираешь? Я вот пока админку пилил не разу его не собрал.

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

Я бы просто на любой термин отдавал 1 и ту же страницу, а уже после загрузки она брала из url название термина и через ajax получала его с сервера.

И в поисковике ни одного термина не будет, т.к. поисковые боты выполняют только синхронный JS, согласно доке vue-ssr (https://ssr.vuejs.org/ru/)

Есть ли аналог PHP/lavarel для nodeJS?

Express с шаблонизатором, отличным от pug.

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

О, ну наконец-то здравая мысля. Так вот, vue - это для клиента, а на сервере нужно другое решение (и лучше вообще не жснутое).

И сейчас бы ручками DOM трогать когда есть Vue.

Если не смущает дополнительная сложность, копай огород экскаватором, кто же запретит.

https://github.com/expressjs/express/wiki#template-engines

Я купился исключительно на однофайловые компоненты с правильным синтаксисом, html, а не pug(jade), которые содержат в себе и стиль, и код, и разметку.

Express + marko

Вот еще почитай: https://markojs.com/docs/why-is-marko-fast/

Мне проще декларативной биндить, чем писать лапшу кода.

Еще тебе принес чтива: Marko vs React. Похоже лучше ты ничего не найдешь, если хочешь изоморфные компоненты.

Вот блин мне и не нравится то, как они режут функционал на «для клиента» и «не для клиента». Т.е. круто, что у них есть однофайловые компоненты, но неясно, почему это только для клиента. Какая-то дискриминация (и недомыслие авторов). Тут-то как раз не должно быть разницы, особенно с учётом ограничений SSR. При наличии nuxt generate получается костыльный «vue для сервера», и в общем-то, он работает. Но костыльно.

Вот норм генератор статики https://github.com/nuxt-community/nuxt-generate-cluster

Спасибо, погляжу. Правда, известность этого Marko почему-то близка к нулю, если сравнить с тем же реактом, хотя ему больше года. В чём ты видишь причину?

Я верно понял, что это лишь кластер для nuxt generate?

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

Как я понимаю nuxt generate, все генерит. А этот может все (-b опция) , а может только те роуты что передашь и тогда довольно быстро получается. У меня где-то 3-4 секунды на 1 роут.
Т.е. у тебя api сервер может отдавать список id слов которые надо заново генерировать. А кластер при запуске будет получать этот список и заново генерировать только его.

SSR - это не статика, вот в чём засада. Это динамика, прикинувшаяся статикой для оптимизации. Слишком сложно, чтобы быть эффективным инструментом. Хотя посмотрим ещё. В целом, я конечно, постараюсь додавить хотя бы вывод списка слов и одного слова на vue+express, но поищу и альтернативы. Может быть, тот же marko.

Ну всё равно в общем-то. Я пока недоволен в целом организацией vue/nuxt, но я об этом уже много написал, см. выше.

Вот блин мне и не нравится то, как они режут функционал на «для клиента» и «не для клиента».

Я другой анонимус и я в ужасе. Меня пугает то, что ты не понимаешь очевидной пользы разделения коцептов. То, что у клиента в компьютере, это совсем не то, что у тебя в сервере. Без разделения зёрен и плевел в WEB (да и вообще в программировании) делать нечего. Лепёчки из оперы «смешались в кучу кони, люди» - это ужас для модификации и понимания. Даже для самого себя, через пол года. А именно это важнее всего в (корректно работающем) коде. Фронтенд и бякенд разрабатывай по отдельности/поочерёдно, только в таком случае у тебя что то стоящее получится. WEB приложение, по сути, это два мини приложения - то, что видит клиент, и то, что есть у тебя. И это почти всегда о-о-очень разные вещи.

Ну SSR нужен что-бы поисковые роботы увидели то-же что видят пользователи и страница чутка быстрее показывалась при загрузке.
А без SSR, бот видит страницу на которой информации нету т.к. компоненты Vue еще не отработали.
А так статика-динамика, ботам на это все равно, да и не определить это ни как статика к тебе пришла или динамика.
Статика нужна что-бы сервер не загружать рендерингом шаблонов. Или для того что-бы закинуть ее на CDN.

У меня где-то 3-4 секунды на 1 роут.

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

Ты шаблоны на рельсах/PHP рендеришь(выполняешь на них js) на сервере и потом сохраняешь в статику?
Тут вся это заморочка с SSR началась когда люди придумали ангуляры/реакты а потом поняли что боты то контент не видят.

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

выполняешь на них js

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

Я не страдаю, у меня сразу SSR хорошо заработал что в dev моде, что в билде. Единственное при SSR надо как то отделять скрипты которые не должны в SSR отрабатывать. Но с этим как я понимаю тоже проблем нету.
Я даже не знал что с ним бывают проблемы какие-то.
Там медленно отрабатывает не сам SSR, а билд проекта и/или сохранение проекта в статику.
Сам SSR моментально отрабатывает.

Да я понял давно это, просто если копаешь ямки, нужно сначала докопать одну, а потом приниматься за другую. Я склонен приниматься за другую, а мне нужно начать продавать свои скиллы в сжатые сроки, поэтому насильно заставляю себя докапывать именно эту ямку. Но чем глубже копаю, тем больше меня поражает увиденное :)

Ну не знаю, я прочитал (не до конца, правда) мануал. И в нём прямо и ясно написано, что есть куча вещей, которые при переходе к SSR сломаются. Если ты сразу знаешь об SSR и делаешь проект под него, то всё ок (не считая того, что часть vue превращается в шлак, причём нужно всегда смотреть в мануал про SSR, поскольку базовый мануал vue про SSR не выделяет особо те события и методики, к-рые сломаются при SSR). Если у тебя уже готовый проект, который не использует SSR, и нужно к нему добавить SSR, то будут проблемы. Примерно это, но немного другими словами, написано в доке по SSR для Vue.

В общем, текущий план состоит в том, чтобы попробовать наладить имитацию серверной генерации на базе SSR. При этом данные будут получаться не на mounted (что подразумевает запрос с клиента), а я попытаюсь воткнуть получение данных из БД в более раннее место - вроде это можно.

Тогда будет такой вот карточный домик из костылей, превращающий всё же vue в серверный шаблонизатор.

А обращение к БД - это отдельное приложение по мотивам Designing a RESTful API with Node and Postgres, к-рое попробую переделать на async/await с учётом https://stackoverflow.com/questions/41570031/express-error-handling-and-async...

Но у меня клиент (пока) не будет обращаться к БД сам - этим будет заниматься только SSR. Вот такой эрзац-PHP.

Если ты что-то не так сделаешь в nuxt в dev режиме. У тебя сразу ошибка вылезет. Попробуй console.log(window) добавь в скрипт.
Т.е. делать билд при каждом чихе тебе не надо.

С помощью axios данные отлично себе берутся откуда угодно через ajax что в ssr, что в браузере.
А вот если ты хочешь что-бы у тебя данные брал только SSR.
Это какой-то прогресс наоборот.
Нахер тебе тогда vue? Он как раз нужен что-бы тебе данные через AJAX шли, а не на каждый чих страницу перезагружать.
Тогда тебе правильно советуют шаблонизаторы.
Берешь любой фремворк на чем угодно и все у тебя работает из коробки.
Хочешь ноду? Возьми express или koa. Любой хелло ворлд с шаблонизатором.

Слушай, ну долго рассказывать, как я попал на vue. Я понял суть. Уже смотрю express, завтра попробую ещё посмотреть на шаблонизаторы. Возможно, я упустил что-то, но мне нужно было:

• компоненты, к-рые можно включать, и к-рые генерят сразу css, html и js, как nuxt из файлов .vue
• интеграция с вебпаком
• при этом возможность на выходе получить файл (а не рендерить сразу при отдаче клиенту + кеш)

аксёс, эсэсэр, вуе, нода, экспресс, коа, фреймворк, нукст...

Вы там в своем веб-два-с-половиной-ноле совсем с катушек посъезжали? Смешались кони, люди..

когда люди придумали ангуляры/реакты а потом поняли что боты то контент не видят

Придумать проблему чтобы её решать. Неоновый гламур!

Дэн, тебе еще не страшно?

Да на kore.io и вебсокетах, расширения на lua.

Дэн, пили уже сам компоненты своей мечты по мотивам vue, а лучше marko. Видишь же, что существующее не очень вписывается в твои хотелки. Кажется я понял что ты хочешь: компонентный фреймворк для бэкенда, а не MVC. Но жаваскриптеры они в основном смотрят на фронт, бэкенд для них это такая йоба, откуда данные сыпятся, они хотят минимизировать работу с ним. Если бы не роботы, они вообще бы на бэкенд забили, нодка плюет json и ладно. А ты наоборот напираешь на бэкенд и статику, т.е. ты не в тренле, ломишь против шерсти.

Возьми express или koa

Вот только не надо ему koa советовать... Это тот фреймворк, который базировался на генераторах, а когда они вышли из моды перескочил на async / await, при всем при этом особого профита не давал. По сути это тот же самый express, только разрубили на много много мелких кусочков. Зачем непонятно.

Дэн, подумай еще раз нужна ли тебе нода вообще. Там недавно школьники нашли баг у себя в npm, когда тот самый npm менял права файлов и папок в операционной системе просто так. Причем эти школьники завезли этот баг еще в версию 5.7.0 и вот заметили только сейчас. Молодцы чо. Я каждый раз удивляюсь багам в ноде и производных от нее.

отговорите: (nodejs)

Дырявая nmp-помойка. Пиши, если тебе насрать на результат.

С другой стороны на бэкенде компонентный подход не уважают, любят MVC. Т.е. не хотят как проще, а сидят такие цари похапешки высасывают из пальца ОО архитектуру. Я вообще подозреваю, что реакт вырос из васянского похапе-фреймворка времен, когда о MVC в вебе еще не слышали. Как ни странно, но такая компонентная архитектура наиболее естественна именно для чистого PHP.

Придумать проблему чтобы её решать. Неоновый гламур!

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

Это прекрасно npm под рутом запускать.

Да я знаю как это говно работает. Просто совсем недавно такого раковника (в головах) еще не было.