Взываю к Мастерам! Нужна ваша помощь, нижайше ваш Джун. Мне нужно написать мобильное приложение to-do list с авторизацией. Как я понял, нужен express – конструктор приложений и база данных, mongoose или mysql. Посоветуйте пожалуйста, оптимальный набор для его создания, от мануала к мануалу всё слишком разное. Я мало знаю, но готов это исправлять.

Feathers -> sequelize -> MySQL (если знаете именно его)

to-do list?

Чтобы плохому не учиться

https://habrahabr.ru/post/352688/

Кто знает, может человеку больше надо SQLite подобное Хотя, Sequelize же, в таком простом приложении можно будет одной строчкой СУБД менять

Зачем постгре для такой задачи?

а ты параллельно сохраняешь item-ы?

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

Зачем постгре для такой задачи?

Вроде сенатор уже ответил выше

Чтобы плохому не учиться

Значит, предварительно: Express – конструктор MySql, sequelize – база данных Passport – авторизация.

hapi hapi-auth-jwt2.0

Странно, почему mоngoose никто не рекомендует, но не моего это ума дело

mongoose хорош

Значит, предварительно: Express – конструктор MySql, sequelize – база данных Passport – авторизация.

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

Вроде сенатор уже ответил выше

А с каких пор выбирать базу данных под задачу, а не исходя из каких-то субъективных предпочтений это плохо?

Странно, почему mоngoose никто не рекомендует, но не моего это ума дело

сам щас с ним мучаюсь

jwt - сила

jwt - сила

What's JWT?

JsonWebToken

так а за что его рекоммендовать, ваш монгус?

Почитай статью на Вики, там всё понятно

я бы на самом деле вообще никакую orm не рекоммендовал бы

В npm есть библиотека для работы с jwt, jsobwebtoken так и называется

Почитай статью на Вики, там всё понятно

any library answer

меня еще всегда фанила валидация модели в монгусе

вот нахуя, кто объяснит?

я бы на самом деле вообще никакую orm не рекоммендовал бы

на нативных модулях писать

ну я могу поспорить за это

так она везде есть

смотри

ща буду длинное сообщение писать

бля, сумбурно получается, дай мне время

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

так?

ага

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

но го про монгу

в итоге на первом этапе будет правельнее заюзать обычный драйвер монги

ну если это, предположим, конечная точка нашего приложения. ну нахуй нам тянуть монгус

mongoose не орм

ну как не орм

а одм

если я не ошиб

аа =)

ну ок

я бы на самом деле вообще никакую orm не рекоммендовал бы

* Защита от SQL инъекций из коробки * Абстра(о)гирование от конкретного диалекта для небольших (несложных) проектов. Одна строчка и вот оно уже работает на sqlite * Могут быть встроенные фичи типа дополнительного кеширования, статистики, логирования и много всего * Миграции * Валидаторы * Удобства типа создать моделько, поработать, а потом может сохранить (обновить), а может нет и т.д.

ну ты же понимаешь о чем я, зачем цепляешься

ну ты же понимаешь о чем я, зачем цепляешься

Я вот тоже решил, что речь про реляционные

ща отвечу

* Защита от SQL инъекций из коробки * Абстра(о)гирование от конкретного диалекта для небольших (несложных) проектов. Одна строчка и вот оно уже работает на sqlite * Могут быть встроенные фичи типа дополнительного кеширования, статистики, логирования и много всего * Миграции * Валидаторы * Удобства типа создать моделько, поработать, а потом может сохранить (обновить), а может нет и т.д.

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

по поводу валидаций на уровне орм/одм у меня вообще бомбит

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

* Когда я писал ответ, я думал, что про ORM * вот про привязку не очень согласен * золотых пуль вообще нет, а всякие потенциально опасные вещи обычно отключать можно легко. * А про валидацию почему так? Вот наоборот не согласен. У меня есть модель. У неё есть конкретные ограничения. Почему бы мне не прописать все эти ограничения там же, где я описываю модель, и там же не прописать разные сообщения, которые выдаются. * Про последнее - чисто про удобство кодирования, ибо именно для этого они и созданы, чтобы было проще и красивее собственно кодитить

ну давай для начала про валидацию

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

перебираю массив, с каждым элементом делаю const newItem = new Item(obj); Item.save(newItem, function(err, item) { game.items.push(item); game.save(callback); }); в итоге в таблице item получаю N записей (все правильно), а в таблице Game получаю грубо 50*N референсов

по-моему у тебя в айтем падает весь массив, и ты этот массив пушишь в айтемс, получается у тебя на 1 итерации в гэйм массив [1], на второй [1, 1, 2], на третей [ 1, 1, 2, 1, ,2 ,3] и т.д. может тебе нужно пушить item[item.length-1]?

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

Ну ORM обычно имеют DB.raw какой-нибудь

только я пока про монгу буду писать, по поводу sql потом

В большом проекте один фиг, если не испоьлзуется ORM, придётся делать свою прослойку какую-то для работы с БД.

только я пока про монгу буду писать, по поводу sql потом

А я только про sql =)

ок, ща сохраню в черновик и давай про sql =)

ну смотри, все sql базы имеют встроенную концепцию модели, так?

по-моему у тебя в айтем падает весь массив, и ты этот массив пушишь в айтемс, получается у тебя на 1 итерации в гэйм массив [1], на второй [1, 1, 2], на третей [ 1, 1, 2, 1, ,2 ,3] и т.д. может тебе нужно пушить item[item.length-1]?

точно нет, братан, один айтем падает, вот так точнее: _.each(marketItems, function(obj, index, list) { const newItem = new Item(obj); Item.save(newItem, function(err, item) { game.items.push(item); game.save(callback); }); }

ну типо схема

@ShaGrisha

вся эта тенденция джавовскай, мутить абстракции над абстракциями с годами (для меня) начинает выглядеть избыточной

вот блять, кложа

ERROR: S client not available

Всё программирование построено на абстракциях, моделях, виртуализации и прослойках

За счёт этого с годами в истории в программировании приложения всё прикольнее, а делаются всё проще

я не писал что абстракция - плохо

я говорю что излишество приводи к головной боли

смотри, что легче - иметь два валидатор (один на уровне формирования данных, вторйо на уровне орм), или один хороший на уровне формирования данных?

я на Koa рендерю стриничку с помощью мидлвари koa-views. На самой страничке у меня подключаются файлы js/css там же у меня путь прописан относительно файла html. Но когда страничка прилетает в браузер все эти файлы запрашиваються с путя localhost:3000/test/sometextв моем случаи . Как это исправляется, что бы файлы брались с папки?

точно нет, братан, один айтем падает, вот так точнее: _.each(marketItems, function(obj, index, list) { const newItem = new Item(obj); Item.save(newItem, function(err, item) { game.items.push(item); game.save(callback); }); }

пилишь список обьектов потом const inserted = await Item.insertMany(items) game.items.push(inserted) await game.save()

ну хотя постой, меня не туда загнало.

А есть ли излишество? Мне всё равно надо где-то описывать валидацию. Почему бы не описать валидацию модели Стул там, где я описал Стул? Кроме того, я уже писал, один фиг нужна в большом проекте будет прослойка в любом случае (логгирование и всё такое).

ну ты мыслишь как настоящий ООП-шник

Не люблю ООП

ты должен валидировать *данные* а не их описание

т.е. валидация на входе а не при сохранении в бд?

А никто не говорил, что при сохранении

Sequelize позволяет делать валидацию, и это не имеет отношения к сохранению в БД

т.е. валидация на входе а не при сохранении в бд?

именно

ну ок, вы на своих проектах валидируете данные только при помощи орм?

На входе пишу Armchair(DataFromUser).validate()

ну ок, я вас понял ? я предпочитаю отдавать в функции для работы с базой отвалидированные данные.

вот и вся наука

ну ок, я вас понял ? я предпочитаю отдавать в функции для работы с базой отвалидированные данные.

Так и будет

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

да я понимаю, я имею ввиду, что пришедшие ко мне данные из вне (не важно, http, stdin), они предварительно будут провалидированы

и вставлены в sql запрос например

Кто будет гарантировать их валидность?

Давай ситуацию теперь от меня. У тебя три модели А, Б и В. И три типа запросов, З1, З2, З3. В З1 используются все модели. В З2 испоьзуется А и Б. В З3 используется Б и В. Сколько раз ты напишешь код, проверяющий, что А.name не содержит пробелов?

Кто будет гарантировать их валидность?

если явно разделить слой валидации и слой работы над данными например

пилишь список обьектов потом const inserted = await Item.insertMany(items) game.items.push(inserted) await game.save()

const inserted = await Item.insertMany(itemsArray); SyntaxError: await is only valid in async function

если явно разделить слой валидации и слой работы над данными например

Почему при этом нельзя, чтобы слой валидации использовал валидацию модели, которая описана в модели?)

const inserted = await Item.insertMany(itemsArray); SyntaxError: await is only valid in async function

почитай про промисы потом про async функции все равно рано или поздно придется

точно нет, братан, один айтем падает, вот так точнее: _.each(marketItems, function(obj, index, list) { const newItem = new Item(obj); Item.save(newItem, function(err, item) { game.items.push(item); game.save(callback); }); }

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