вложенные объекты - действительно вариант для ORM. Но, честно говоря, сейчас я так перестал делать. Если запросы разделить (отдельно юзеры, отдельно комменты из вашего примера) то интерфейс реагирует живее. Но если непременно нужно вложенные, то да - ORM, это проще, чем строить запрос с вложенными объектами (что поддерживают не все БД). Может, напишу об этом отдельную статью про DI с разными реализациями одного интерфейса - согласен. Но я бы делал инъекции вручную - кажется, что такие случаи не настолько всепроникающие, чтобы использовать библиотеку Ошибки, кажется, тоже проще перехватывать одним мидлваром - и Spring и NEST с Fastify позволяют это делать, именно в нём вы делаете проверки на prod\dev и решаете что именно отдавать клиенту. В целом у вас совершенно верное восприятие - я не против этих технологий вообще. Я против того, чтобы использовать их там где они профита не дают, а код усложняют
Про фронт только один абзац, TS я в основном, использую на бэке. Вы правы - на Java я тоже писал на Spring, и старался отметить (в абзаце про ORM), что на Java его использование не только оправдано, но и удобно. Но это автоматически не распространяется на другой язык. А вот бессмысленное использование DI без моков я встречал и на Java и на TS. И на Java статические репозитории работают так же как и на TS. И описанный случай с GUID был с JAVA программистом — т.е. он настаивал, что именно в Джаве так принято (хотя, конечно, это личное мнение в реальности к Java не имеет никакого отношения, просто привычно, что там всё "солидно" и "промышленно").
Я того же мнения. Но меня часто смущает - правильно ли я делаю? Ведь кто-то старался, что-то уже написал. Но чужие обёртки всегда "жирнее" предусматривают случаи, с которыми твой код никогда не столкнётся, а в душе я за минимализм.
Если вы любите Нест, то хотел давно задать вопрос. (Не подумайте, тут нет никакого подвоха), я действительно не очень понимаю, в чём вообще удобство DI на ноде? В джаве понятно - там по-другому не очень получается - надо импортировать класс из него делать инстанс, а если синглтон, то с бубнами - всё это отдаётся фреймворку. А в ноде сделал инстанс от репозитория в файле (модуле) этого репозитория, его экспортнул - вот у тебя и зависимость-синглтон в одну строчку (Injectable Default). Можно придумать зачем это на фронте - может в течении текущего сеанса тебе какая-то зависимость вообще не понадобится, так зачем от неё сразу делать инстанс. Но на REST-сервере вряд ли такое имеет смысл. Чего дополнительного дают декораторы Injectable со скоупами. В (моём личном эстетическом) представлении это только делает код очень неявным, но может я что-то упускаю, случайно не столкнулся с ситуацией где это действительно "бомба". Спасибо.
php ведь был "предназначен" для других целей - для простого и удобного создания динамичных html-страниц. И в этом качестве остаётся настолько удобным, что до сих пор его не могут выбить из этой ниши ни питон ни руби ни нода, не смотря на гигантское количество очень старого легаси. Даже нода на первоначальном этапе использовалась похожим образом - она хостила какие-нибудь jade/pug страницы, рендерила из них на лету html. Но в таком качестве не особо прижилась. Основной смысл ноды - затащить на сервер JavaScript, поскольку JS невозможно изъять из фронтенда. Это изначально чисто организационное решение, которое позволяет шэрить кодовую базу (и программистов) хотя бы частично. Нода на этом пути далеко не первое решение, но самое известное (и на момент появления самое быстрое, потом появились и побыстрее). Применение Ноды стало расширяться с появлением SPA приложений, когда применение JS на фронтенде увеличилось настолько, что по-сути исчез голый html. Использовать в этой связке php просто потеряло всякий практический смысл. Уж если тащить на сервер что-то другое, то что-то однозначно более мощное (Java, Go, может Rust). Решения затыкать каждую дырку одним языком - Джава с Ваадином, Нода с pug/jade, php с fastCGI - они всегда будут, т.к. решают ОРГАНИЗАЦИОННЫЕ задачи - занять уже имеющихся специалистов. Так и надо эти технологии воспринимать - ну есть у вас php программисты, ну можно сделать и так. Но пропагандировать им везде заменять другие языки - это лишнее, IMHO.
Это сравнение инспирировано исключительно фразой создателя Ноды и несколькими статьями описывающими именно такой переход. Здесь нет Джавы и питона только по этой причине, а не потому что они не пригодны для серверов. Как раз наоборот мне было бы любопытно написать одинаковые сервера на Node, Java, Go и сравнить. Думаю писать на Джаве (Спринге) концептуально меньше, только постоянная декларация типов увеличит количество букв. И память, кажется, будет жрать не меньше ноды. Но это предположение
Экзотичный, это значит что мне удалось найти на него 11 вакансий на известном сайте против двух тысяч на Джаву. Но вы не думайте, что я не люблю Эрланг - это очень интересный практичный язык, я с удовольствием смотрел лекции Джо (Лесли) Армстронга. Я пользовался продукцией эрливидео. Если на нём есть стабильная работа, то я понимаю, почему она может нравится. Паттерн мэтчинг, отсутствие привычных конструкций - всё выглядит очень "вкусно". У меня даже создаётся впечатление, что горутины это идея инспирированная удачным применением "легковесных процессов" в BEAM
Я так понимаю, человек имеет в виду Panic, но в Go они используются сильно реже чем Exceptions в других языках. Рекомендуемый способ - это возвращение error, а не бросание паники, и методы из стандартных пакетов так и делают. Мне показалось, что вы и так в курсе.
Нест часто требует к известным библиотекам свои враперы, увеличивая количество зависимостей, которые на чистом экспрессе/фастифае были бы не нужны. плюс как-то получается что node_modules у одного и того же сервера на Несте жирнее чем на фастифае. Поэтому чисто статистически на Несте эта проблема возникает чаще. Честно говоря, на фастифае такого вообще не видел, а на Несте регулярно. На экпрессе тоже наверняка проблем меньше, просто давно на нём не писал
Спасибо, я добавил это в статье. Но тут нет манипуляции, т.к. слова Даля продолжают использовать как аргумент для противопоставления Го и Ноды - поэтому они приведены.Но я добавил упоминание Deno, чтобы смягчить формулировки. Я не слышал его мнение о Rust применительно к серверам, возможно этот язык воспринимается скорее как системный, как и C на котором написана LibUV лежащая в основании Ноды.
Согласен. Express прекрасен. Предпочёл Fastify, т.к. там можно избежать колбеков и писать через async/await, в результате получается практически линейный код, очень простой визуально.
Ну оптимальным REST я считаю Fastify+TypeScript+Knex, организация кода в парадигме DDD, в гитхаб пока не выкладывал. У меня была мысль написать про DDD+Fastify. После вашего комента вероятно придётся сделать еще и на гитхабе scaffold-проект. Для НЕСТа честно, говоря не планировал поскольку для себя считаю его бесперспективным и возвращаться к нему не хочется.
Скорее всего, вы имете в виду противопоставление структурной и явной типизации.
я думал "явная", это когда надо указывать тип переменной при инициации (он не выводится из присвоения). Я имел в виду - когда отсутствует приведение типов, вроде это называют "сильной" или "строгой" типизацией
Что вы имеете в виду про SOLID.
Принцип Interface segregation из SOLID рекомендует использовать много специализированных интерфейсов вместо одного обобщённого. Для того, чтобы "скармливать" методам более разнообразные данные в условиях сильной типизации. Ту же самую задачу решает структурная типизация, применяемая и в TS и в Go. Т.е. интерфейс "сегрегировать" можно, но при этом его можно не имплементировать вообще
Singletone - переводится как "одиночка", а любой импорт в JS'e импортируется один раз, а объекты передаются по ссылке, автоматически оставаясь одиночками. Именно его "одиночность" я и имею в виду
сервис создается ровно когда вы к нему обращаетесь
В принципе, вы правы, просто мне привычнее такое называть "ленивой загрузкой" / deffered / или on-demand. Но если смысл синглтона именно в отложенной инициации, то он имеет смысл и в JS. Но тогда выходит, что его применение другое и более редкое
А когда то вообще TS не было ... сильно короче могли написать на JS.
Ну вот TS, как мне кажется, полезен и решает задачи, которые голый JS не может решить в принципе, а имитация сильной типизации из Джавы уже никаких дополнительных задач не решает.
Т.е. все что вам мешает - это не высокий порог входа. Не избыточное количество обслуживающего кода а...
Вы совершенно правы, для меня это серьёзное препятствие для внедрения. Постеснялся это написать из-за определённой субъективности - некоторым почему-то нравится показная сложность
вложенные объекты - действительно вариант для ORM. Но, честно говоря, сейчас я так перестал делать. Если запросы разделить (отдельно юзеры, отдельно комменты из вашего примера) то интерфейс реагирует живее. Но если непременно нужно вложенные, то да - ORM, это проще, чем строить запрос с вложенными объектами (что поддерживают не все БД). Может, напишу об этом отдельную статью
про DI с разными реализациями одного интерфейса - согласен. Но я бы делал инъекции вручную - кажется, что такие случаи не настолько всепроникающие, чтобы использовать библиотеку
Ошибки, кажется, тоже проще перехватывать одним мидлваром - и Spring и NEST с Fastify позволяют это делать, именно в нём вы делаете проверки на prod\dev и решаете что именно отдавать клиенту.
В целом у вас совершенно верное восприятие - я не против этих технологий вообще. Я против того, чтобы использовать их там где они профита не дают, а код усложняют
Про фронт только один абзац, TS я в основном, использую на бэке. Вы правы - на Java я тоже писал на Spring, и старался отметить (в абзаце про ORM), что на Java его использование не только оправдано, но и удобно. Но это автоматически не распространяется на другой язык. А вот бессмысленное использование DI без моков я встречал и на Java и на TS. И на Java статические репозитории работают так же как и на TS. И описанный случай с GUID был с JAVA программистом — т.е. он настаивал, что именно в Джаве так принято (хотя, конечно, это личное мнение в реальности к Java не имеет никакого отношения, просто привычно, что там всё "солидно" и "промышленно").
имеется в виду визуальная простота, которую некоторые люди могут воспринять за примитивность. Слегка изменил формулировку.
Я того же мнения. Но меня часто смущает - правильно ли я делаю? Ведь кто-то старался, что-то уже написал. Но чужие обёртки всегда "жирнее" предусматривают случаи, с которыми твой код никогда не столкнётся, а в душе я за минимализм.
Если вы любите Нест, то хотел давно задать вопрос. (Не подумайте, тут нет никакого подвоха), я действительно не очень понимаю, в чём вообще удобство DI на ноде? В джаве понятно - там по-другому не очень получается - надо импортировать класс из него делать инстанс, а если синглтон, то с бубнами - всё это отдаётся фреймворку. А в ноде сделал инстанс от репозитория в файле (модуле) этого репозитория, его экспортнул - вот у тебя и зависимость-синглтон в одну строчку (Injectable Default). Можно придумать зачем это на фронте - может в течении текущего сеанса тебе какая-то зависимость вообще не понадобится, так зачем от неё сразу делать инстанс. Но на REST-сервере вряд ли такое имеет смысл. Чего дополнительного дают декораторы Injectable со скоупами. В (моём личном эстетическом) представлении это только делает код очень неявным, но может я что-то упускаю, случайно не столкнулся с ситуацией где это действительно "бомба". Спасибо.
php ведь был "предназначен" для других целей - для простого и удобного создания динамичных html-страниц. И в этом качестве остаётся настолько удобным, что до сих пор его не могут выбить из этой ниши ни питон ни руби ни нода, не смотря на гигантское количество очень старого легаси.
Даже нода на первоначальном этапе использовалась похожим образом - она хостила какие-нибудь jade/pug страницы, рендерила из них на лету html. Но в таком качестве не особо прижилась. Основной смысл ноды - затащить на сервер JavaScript, поскольку JS невозможно изъять из фронтенда. Это изначально чисто организационное решение, которое позволяет шэрить кодовую базу (и программистов) хотя бы частично. Нода на этом пути далеко не первое решение, но самое известное (и на момент появления самое быстрое, потом появились и побыстрее).
Применение Ноды стало расширяться с появлением SPA приложений, когда применение JS на фронтенде увеличилось настолько, что по-сути исчез голый html. Использовать в этой связке php просто потеряло всякий практический смысл. Уж если тащить на сервер что-то другое, то что-то однозначно более мощное (Java, Go, может Rust).
Решения затыкать каждую дырку одним языком - Джава с Ваадином, Нода с pug/jade, php с fastCGI - они всегда будут, т.к. решают ОРГАНИЗАЦИОННЫЕ задачи - занять уже имеющихся специалистов. Так и надо эти технологии воспринимать - ну есть у вас php программисты, ну можно сделать и так.
Но пропагандировать им везде заменять другие языки - это лишнее, IMHO.
Это сравнение инспирировано исключительно фразой создателя Ноды и несколькими статьями описывающими именно такой переход. Здесь нет Джавы и питона только по этой причине, а не потому что они не пригодны для серверов. Как раз наоборот мне было бы любопытно написать одинаковые сервера на Node, Java, Go и сравнить. Думаю писать на Джаве (Спринге) концептуально меньше, только постоянная декларация типов увеличит количество букв. И память, кажется, будет жрать не меньше ноды. Но это предположение
Экзотичный, это значит что мне удалось найти на него 11 вакансий на известном сайте против двух тысяч на Джаву.
Но вы не думайте, что я не люблю Эрланг - это очень интересный практичный язык, я с удовольствием смотрел лекции Джо (Лесли) Армстронга. Я пользовался продукцией эрливидео. Если на нём есть стабильная работа, то я понимаю, почему она может нравится. Паттерн мэтчинг, отсутствие привычных конструкций - всё выглядит очень "вкусно". У меня даже создаётся впечатление, что горутины это идея инспирированная удачным применением "легковесных процессов" в BEAM
Больно это экзотичный вариант с BEAM. Сравнение между го и нодой сам Даль создал. Его фраза про Го известная, что он там потом делал не все помнят
Я так понимаю, человек имеет в виду Panic, но в Go они используются сильно реже чем Exceptions в других языках. Рекомендуемый способ - это возвращение error, а не бросание паники, и методы из стандартных пакетов так и делают.
Мне показалось, что вы и так в курсе.
Это любопытно, честно говоря, пока не встречал суждений про Rust в качестве серверного языка. Нужно провентилировать вопрос.
Нест часто требует к известным библиотекам свои враперы, увеличивая количество зависимостей, которые на чистом экспрессе/фастифае были бы не нужны. плюс как-то получается что node_modules у одного и того же сервера на Несте жирнее чем на фастифае. Поэтому чисто статистически на Несте эта проблема возникает чаще. Честно говоря, на фастифае такого вообще не видел, а на Несте регулярно. На экпрессе тоже наверняка проблем меньше, просто давно на нём не писал
Спасибо, я добавил это в статье.
Но тут нет манипуляции, т.к. слова Даля продолжают использовать как аргумент для противопоставления Го и Ноды - поэтому они приведены.Но я добавил упоминание Deno, чтобы смягчить формулировки.
Я не слышал его мнение о Rust применительно к серверам, возможно этот язык воспринимается скорее как системный, как и C на котором написана LibUV лежащая в основании Ноды.
)) Ну так устроена прошивка в некоторых LED-панелях. И сам был в шоке
В статье была ремарка о Fast CGI, но я удалил её т.к. статья совсем не об этом, но для вас вернул на место
Согласен. Express прекрасен. Предпочёл Fastify, т.к. там можно избежать колбеков и писать через async/await, в результате получается практически линейный код, очень простой визуально.
Ну оптимальным REST я считаю Fastify+TypeScript+Knex, организация кода в парадигме DDD, в гитхаб пока не выкладывал. У меня была мысль написать про DDD+Fastify. После вашего комента вероятно придётся сделать еще и на гитхабе scaffold-проект. Для НЕСТа честно, говоря не планировал поскольку для себя считаю его бесперспективным и возвращаться к нему не хочется.
Вот! Это называется "номинальная типизация" - вы правы, внёс изменения, спасибо
Наверное, это такое техно-колдовство. Людям нравится знать заклинания для избранных.
я думал "явная", это когда надо указывать тип переменной при инициации (он не выводится из присвоения). Я имел в виду - когда отсутствует приведение типов, вроде это называют "сильной" или "строгой" типизацией
Принцип Interface segregation из SOLID рекомендует использовать много специализированных интерфейсов вместо одного обобщённого. Для того, чтобы "скармливать" методам более разнообразные данные в условиях сильной типизации. Ту же самую задачу решает структурная типизация, применяемая и в TS и в Go. Т.е. интерфейс "сегрегировать" можно, но при этом его можно не имплементировать вообще
Singletone - переводится как "одиночка", а любой импорт в JS'e импортируется один раз, а объекты передаются по ссылке, автоматически оставаясь одиночками. Именно его "одиночность" я и имею в виду
В принципе, вы правы, просто мне привычнее такое называть "ленивой загрузкой" / deffered / или on-demand. Но если смысл синглтона именно в отложенной инициации, то он имеет смысл и в JS. Но тогда выходит, что его применение другое и более редкое
Ну вот TS, как мне кажется, полезен и решает задачи, которые голый JS не может решить в принципе, а имитация сильной типизации из Джавы уже никаких дополнительных задач не решает.
Вы совершенно правы, для меня это серьёзное препятствие для внедрения. Постеснялся это написать из-за определённой субъективности - некоторым почему-то нравится показная сложность