LINUX.ORG.RU

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

 ,


1

2

Хочу сделать небольшое и легконагруженное приложение - редактор словарей терминов. Есть список слов, можно искать слово. У слова есть карточка, которая своя для каждого пользователя, но можно смотреть чужие карточки. Карточка в формате markdown или что-то около того.

Клиента буду делать на vue.js, а сервер хочу на node.js . Да, меня уже отговаривали использовать node.js на стороне сервера. Но вдруг для такого простого проекта прокатит? В принципе, я готов всю тяжесть написать на pl/pgSQL, а на нодке - только тончайший интерфейс и собственно веб сервер. Соответственно, вопрос - как там с утечками памяти и прочими такими вот ужасами?

Т.е. вопрос состоит не в удобстве и не в производительности, а в качестве с т.з. надёжности.

Перемещено tailgunner из development

★★★★★
Ответ на: комментарий от leprikon

auth-module по определению имеет серверную часть. Нельзя же авторизовать клиента на клиенте :) Она там сделана на express. Так что это не я считаю, это пример такой. Могли бы сразу и https впилить, поскольку впилить что-бы то ни было в express ли, в vue ли - вещь не вполне тривиальная. Нужно знать, куда впиливать и как. Тут я пасусь на stackoverflow, и обычно второе или третье решение подходит. Со входом в систему проблема в том, что фронтенд игнорирует 401 при неверном пароле. Просто нажимаешь кнопку и ничего не происходит.

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

Далее, передача токена в put запрос к бекенду сама по себе нетривиальна, там было issue, которое долго разруливали с матюками. Я за некоторое время разобрался по мотивам лога этого issue, но это были какие-то танцы с бубном, на мой дилетантский взгляд. Об устаревании токена мне пока и подумать страшно. Ведь здесь должен быть сделан и фронтенд, и бекенд. Этого нет и это некая работа. И ведь если токен устарел, то я должен получить новый и повторить запрос - это какая-то фигня, которая должна проходить красной нитью через всё приложение. А нет на это даже никакого намёка. Максимум, что я там нашёл - это переадресация после login. Спасибо! Т.е. похоже, мне придётся присоединиться к увлекательному процессу разработки архитектуры vue.

Такое вот типичное «можно сделать». Для игр годится, для прокорма семьи или удовлетворения заказчика - как-то пока не очень.

den73 ★★★★★ ()
Ответ на: комментарий от den73

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

den73 ★★★★★ ()
Ответ на: комментарий от den73

Дэн, но ведь vue - это view. Там и не должно быть никакой авторизации и всего такого. Тупо шаблоны с привязкой данных. А для всего прочего по идее нужно тащить другие либы и как то самому их сопрягать. И тут кроме рукоблудия возникает еще проблема разбухания клиентского кода. Вот что хипсторы не осознают и не хотят об этом думать. Для полнофункционального толстого клиента нужно дофига кода, и если на сервере ты можешь хоть гиг зависимостей притянуть, то с клиентом будет жопа. Поэтому хипстосайты люто тормозят и жрут память, хотя сделаны казалось бы идеологически верно.

anonymous ()
Ответ на: комментарий от den73

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

leprikon ()
Ответ на: комментарий от den73

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

Можно делать это и на клиенте. Но тогда отваливается SSR и получается, что и контент будет строиться через JS. Прощай, SEO.

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

Пойду копать, как выглядит этот частный SSR. Надо сказать, что пока вопрос аутентификации/авторизации мне не поддаётся, да и не только мне.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

В общем, я затратил на это изрядно времени. Нормального примера не нашёл (попробовал три разных, они либо не собираются, либо не работают в каких-то случаях, например, ломаются после обновления страницы). Как согласовать аутентификация и SSR - не понял. В некоторых примерах токены безопасности хранятся в памяти, доступны из JS и обрабатываются в JS. Как я понял, это более опасно, чем http-only куки. И это не будет работать при отключенном JS. Поэтому из этого проекта vue, скорее всего, выкину. Попробую использовать шаблоны lodash с express, а для экспресс много всего есть по аутентификации.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)

Отговаривать точно не буду, т.к. лучше самому один раз попробовать, чем потом сто раз слушать рассказы как там (node, vue, mango e.t.c) всё работает. Сам после теплового LAMPового набора инструментов до сих пор как на сковородке с одним проектом на VUE, NODE, Mango. Что-то периодически падает, что-то отрубается, приходится во всё вникать, но в целом очень интересно. Сам сайт работает по другому принципу и доступен как приложение на определенном порту. Архитектура подобных современных сайтов (не только на node) сильно отличается от привычных. Конфиг прописан в json файле. Чем-то всё напоминает Android приложение, думаю, что из- такого сайта несложно будет сделать настоящее Android или другое приложение. Конечно, node тянет очень много непонятных зависимостей, но это было заложено в node изначально. Да и не обязательно их все запускать одновременно, можно же собрать сайт, всё проверить и запускать готовый.

poshat ★★ ()
Последнее исправление: poshat (всего исправлений: 1)
Ответ на: комментарий от poshat

Конечно, node тянет очень много непонятных зависимостей, но это было заложено в node изначально.

Нода это один единственный исполняемый файл. Все зависимости у тебя в твоих проектах, а не в ноде.

anonymous ()
Ответ на: комментарий от poshat

Ну я уже попробовал, вот сайт на nuxt generate,

https://bitbucket.org/budden/ppr

Ссылка на сайт программирование-по-русски.рф там не работает.

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

Сейчас мне нужна авторизация и у меня создаётся чувство, что в vue это просто ещё толком не продумано, вот пруфлинк https://github.com/nuxt/nuxt.js/issues/2124

Сегодня более-менее продвинулся - стоило только отказаться от vue, как дела резко пошли вперёд. Прикрутил сессии (правда, сохраняются они в памяти, а надо бы в базе хранить), сделал на них новый login/logout, а также прикрутил lodash-express и написал пару очень простых шаблонов.

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от anonymous

Нода это один единственный исполняемый файл. Все зависимости у тебя в твоих проектах, а не в ноде.

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

poshat ★★ ()
Ответ на: комментарий от den73

У меня проект, который правда только админю кое-как, менее технической направленности, хотя как сказать.
До сих пор не пойму как правильно демонизировать ноду. Ни forever ни pm2 нормально статус не отслеживает и , естественно, ноду не перезапускает. И даже снимать все процессы ноды приходится вручную, т.к. forever stopall ничего толком не делает.
В логах ничего конкретно нет, ощущение, что маловато ресурсов и надо вместо обычного VDS переезжать на что-то типа Heroku или Amazon, с необходимыми выч. ресурсами по запросу.

poshat ★★ ()
Ответ на: комментарий от den73

Можно делать это и на клиенте. Но тогда отваливается SSR и получается, что и контент будет строиться через JS. Прощай, SEO.

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

anonymous ()
Ответ на: комментарий от den73

Сегодня более-менее продвинулся - стоило только отказаться от vue, как дела резко пошли вперёд.
прикрутил lodash-express и написал пару очень простых шаблонов.

Ай молодца, выкинул современный фреймворк и пошел костылять велокактусы.

anonymous ()
Ответ на: комментарий от anonymous

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

bread ()
Ответ на: комментарий от bread

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

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

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

Лол.

anonymous ()
Ответ на: комментарий от anonymous

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

anonymous ()
Ответ на: комментарий от anonymous

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

int64 ()
Ответ на: комментарий от int64

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

anonymous ()
Ответ на: комментарий от bread

По сути дела, тему можно закрывать, т.к. проект заморожен. Вот здесь заготовка ТЗ и ссылка на все репозитории.

https://bitbucket.org/budden/ppr/src/380b861c15cca4bde1e39b0bf7a20dde506eb6b3...

И вот мой негативный отзыв на nuxt как таковой:

http://программирование-по-русски.рф/как-сделан-этот-сайт.яргт

den73 ★★★★★ ()
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Клад нашел? Ну и долго же ты грыз кактус. Где-то еще на первых страницах сказали, что эта хипстня не для сайтов, а для приложений со сложным UI. И то большие вопросы. Ясно, что расчитано оно на вчерашних верстаков, для которых работа с деревом это какой-то заоблачный матан. Нужно «чтобы оно как-то само». А интегрировать с серваком все должен другой специалист с помощью синей изоленты и такой-то матери. Это может и нормально для большой конторы, а для одиночных запилов чистейший ССЗБизм.

anonymous ()
Ответ на: комментарий от den73

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

Телеграм, например, это приложение. А ЛОР это сайт.

Еще можно разделить что есть SPA и не SPA - но это такое себе деление, потому что и лэндинг это SPA.

Разница в выполняемых функциях. Фотошоп онлайн - это приложение. А галлерея фотографий это скорее сайт, если только эта галлерея не имеет одновременно функциональности по управлению этими фотографиями (сортировка\поиск\редактирование\етк).

anonymous ()
Ответ на: комментарий от anonymous

что эта хипстня не для сайтов, а для приложений со сложным UI. И то большие вопросы.

Ну удачи тебе писать сложный UI на jquery. Jquery - вообще потрясающе ублюдочная вещь, как будто специально спроектированная чтоб писать write-only спагетти-говнокод. Ну может во времена IE6, прости господи, оно и было полезно, чтоб сделать что-нибудь простенькое на домашней страничке васяна, не заморачиваясь с кроссбраузерностью. Но сейчас-то зачем?

anonymous ()
Ответ на: комментарий от den73

Что тут не понятно? SPA и не-SPA - это два разных мира, с разными подходами, разными архитектурами и разным инструментарием. Первое - чистое клиент-серверное приложение, типа как MMORPG, хехе, второе - классический сайт, что-то сабмитим на сервер, обратно получаем отрендеренную страницу. И для второго надо было учить PHP+Symphony (да-да) или Python+django (RoR походу уже рип). Попытки же скрестить ужа с ежом и усидеть на двух стульях ничем хорошим не заканчиваются.

anonymous ()