Коллеги привет. Как вы решаете задачу с GraphQL + SQL + отпимизация получения результатов из БД?
Например когда нужно получить структуру cat = {id: 1, name: "Tom"} нам не нужно левое соединение с таблицей children
А в случае {id: 1, name: "Tom", children: [ {id:2, name: "foo"} ] } нужно получать из БД дополнительные данные

Привет. Можете поделиться опытом, при разработке, клиент на Nuxtjs сервер Nodejs. Панель админа должна быть на стороне клиента?

@tshemsedinov Тимур, добрый день!
Спасибо, вам большое за видео "Байки про JavaScript и Node.js с Тимуром Шемсединовым".
Для меня особенно ценно сравнение Node.js с другими серверными технологиями.
В данном видео вы частично коснулись данного вопроса.
В виду того что в "интернете" практически нет конкретных примеров и разборов конкретных ситуаций, ваш опыт поэтому поводу звучит бесценным.
Было бы здорово если бы на своем канале или еще где разобрали и привели примеры конкретных сценариев где нода луче или хуже других технологий.
Я думаю это сильно поможет новичкам в Node.js, они будут больше ее "уважать". Возможно это также поможет архитекторам, при выборе лучшего решения для бизнеса.
Я задавался данным вопросом 2 года назад. Прочитал кучу статей, и ничего конкретного не нашел.
Раньше я думал, что преимущество Node.js в том, что на фронте и на бэке один язык, но изучив архитектуру бекендов, прочитав Фаулера "шаблоны корпоративных приложений" я пришел к выводу, что фронт и бек настолько разные, что преимущество единого языка сходит на нет.
Сейчас у меня предвзятое отношение к Node.js, я считаю его костыльным, хотя делаю бэкенд на нем.
Так, например, в ноде нет встроенного механизма DI, нужно пользоваться костылем в виду Inversify хотя, глядя на Spring у меня глаза радуются насколько он там классно сделан.
Я конечно не профессионал, опыт ноды у меня 1 год +.
Но после того как в видео я услышал конкретный кейс с "Поддержанием 2 млн соединений за счет libuv", у меня появилось больше интереса и уважения к ноде.
Было бы здорово услышать от вас или комьюнити, вот такие конкретные кейсы с примерами где нода лучше, хуже и почему.
Например, насколько я знаю, в Java есть асинхронность, чем она луче, хуже Node.js (libuv)?
Java сможет на том же сервере поддерживать 2 млн соединений?
Я слышал от джавистов что асинхронность сложно дебажить , поэтому они выбирают синхронность, интересно узнать ваше мнение по этому поводу.
Я понимаю что нужно разделать фреймворки, языки, подходы.
Но тем не мене интересно ваш анализ Node.js vs ...
Спасибо!

Всем привет.
Подскажите стоит ли осваивать ORM, например Sequelize?
Лично мне показалось что он только все усложняет когда дело доходит до сложных запросов к БД. Да и я так и не понял в чем профит его использовать.
Часто ли ORM используют на практике вместо чистого SQL?
Судя о редком упоминании ORM в вакансиях, их почти не используют. Или их не указывают потому что это как само собой разумеющиеся?

Я не знаю, не использовал. Но что я заметил:
1) много джавистов используют ORM (hibernate)
2) Куча вакансий Node.js где нужно знать ORM. Лично я для себя как появится время, обязательно буду ее учить, именно для резюме.

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

а точно надо поддерживать 2 млн. соединений на одном сервере?
цель именно такая?

Ну ORM полезная и лично для меня удобная штука для работы с SQL db. Node.js сам только недавно начал изучать. Но когда писал бек на джаве с mysql то использовал orm и впринципе доволен. Так как довольно таки читабельно и легко поддерживать

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

Их точно не нужно осваивать ВМЕСТО непосредственно SQL.

Если SQL уже знаешь, и умеешь работать с БД, умеешь строить запросы сам, то освоение ОРМ сводится к освоению основных паттернов (которых мало), и не посредственно интерфейса конкретной ОРМ.

> показалось что он только все усложняет когда дело доходит до сложных запросов
Когда как, зависит от конкретной ОРМ. В некоторых есть построитель запросов, который пытается быть максимально близким к SQL, и не сильно тебя ограничивает.
Главная задача орМ - это делать собственно маппинг результата из бд в объекты и обратно.
Но, конечно, это слой абстракции, и он может приводить к иногда неоптимальным решениям или не использованию чего-то из конкретной РСУБД, что могло бы сделать решения лучше.

> Часто ли ORM используют на практике вместо чистого SQL?
Да

> Судя о редком упоминании ORM в вакансиях
Это не что-то такое, что требует упоминания в вакансии

Понял, спасибо всем за ответы!

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

Понял, спасибо!

а в запросах на чтение вручную мапишь результаты в объекты?

ORM(ODM) это не библиотека, а слой в архитектуре приложении. Советую именно этот вопрос изучить и тогда будет легче решения принимать

И тем более ORM это не query bulder
У тебя может быть ORM слой в приложении, но при этом ты будешь всё равно писать голые запросы

скажите такой роутинг можно как то улучшить?

А библиотека это как я понимаю что то вроде реализации универсального orm?

Да