но если я микросервисную реализую то jwt необходим? Тру?

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

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

Что будет быстрее - класс на джаве сериалтзовать в строку или объект на жс?

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

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

С выборкой вроде проблем нет, хотя особо сложные по тз делать не приходилось. А вот механизма массовой записи у них нет. Сейчас это делается так. Берётся строка, делается select по всей таблице, если PK уже там есть делается update, если нет то делается insert, затем берётся след строка и так по кругу. Соответственно из за этого селекта постоянного запись идёт оооочень долго.

Это из примера работы модуля причем не из гитхаба а из состава npm. Как в npm может быть модуль с неочевидным поведением ? "node-opus"

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

С выборкой бывают проблемы. Недавно у коллеги нужно было выбрать не очень большое(около 20000) кол-во записей из БД с несколькими джойнами. Запрос TypeORM осилила, а вот на парсинге ответа блочила ивент луп минуты так на 2. В итоге просто переписали в этом месте на SQL запрос, и всё заработало как часы

зато сбежали из мира хаоса

Не вижу противоречий к моему высказыванию, я призываю к использованию ОРМ только на простых запросах.

и в итоге у тебя получается в проекте и то и другое, и для поддержки надо знать и тонкости скл, и тонкости орм

Ситуация заключается в том, что меня пригласили на работу. И сообщили об отсутствии навыков работы с бд(я не работал с бд раньше), предложили изучить в течение короткого времени sequelize и postgresql, чтобы выполнить тестовое задание и продолжить общение, но я не смог разобраться в том, с чего следует начать и потому выбрал просто sql. Сейчас же, после диалога с Вами и Вашими коллегами, пришёл к выводу, что в данный момент правильней будет сосредоточиться на sequelize, не забрасывая освоение чистого sql, и надеюсь, что делаю правильные выводы

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

Благодарю Вас

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

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

самое смешное было видеть, как с помощью ORM быстро и круто делали выборки, которые под капотом превращались в десятки запросов... а если сделать на SQL - то все можно было получить в один =)))

+)