А ещё можно на ассемблере написать - просто летать будет. Естественно что спринг добавляет оверхед и если его не использовать будет быстрее, но удобнее - большой вопрос
один сервер НЕ всегда будет быстрее кластера, потому что у него есть потолок производительности, у кластера его нет (ну или почти нет :)), это называется горизонтальное масштабирование Насчет DTO, их имеет смысл использовать, когда сигнатруа метода раздувается до 5 и более параметров, это никак не связано с Rest API, такого правила желательно придерживаться в любом API
"Синхронное API — одна из ключевых причин низкой производительности вебсервисов." Вообще странное утверждение потому что синхронный вызовы по умолчанию быстрее асинхронных, т.к. не используются очереди, дополнительные потоки и т.д.
А насчет "Что произойдет если появится необходимость добавить новый параметр?" у RequestParam есть проперть defaultValue которую всегда можно выставить
Если честно, до конца не дочитал, наверняка еще найдется пара/трока спорных утверждений
Все это хорошо, но летом там ну очень жарко, а с учётом глобального потепления будет ещё жарче. Так что лето, по крайней мере, я бы проводил в другом месте, как американские пенсионеры, которые зимуют во флориде, а лето где нибудь по севернее, типа чикаго
Пользуюсь комьюнити идею начиная с первых дней её появления и никаких проблем не испытываю. Все эти визарды, плагины, все это костыли для тех кто под капот ленится заглядывать. А модульная или микросервисая архитектура позволяет быстро разобраться с проектом любой сложности.
Когда то я ехал в поезде с профессором, он возмущался по поводу зарплат. Я спросил у него сколько книг по профессии он прочёл за последнее время, на что он ответил, зачем мне что то читать, если если ничего нового не было с начала прошлого века. Вот по этому и такая разница в зарплате, программист учится пока работает. Каждые 3-5 лет новая мулька, не сказать чтобы сильно новая, но все же поизучать придётся.
По поводу оценки времени, если задача хорошо декомпозирована на подзадачи, проблем с оценкой нет. Для декомпозиции необходимо провести исследование и потратить 1, 2 дня иногда побольше, но иначе никак
У меня федора на неттопе с целероном купленным на авито за 4 тыс и 2 диска через юсб воткнуть, вот и все
В том что за неё надо заплатить
Сто процентов
Вы просто не умеете их готовить.
С гантелями/штангой поинтересней будет потому что прогресс виден когда делаешь тоже количество повторений но с большим весом
Вообще ddd 20 лет в обед, это уже давно не хайп а стандарт для некоторых
я бы предпочел увеличивать версию агрегата вручную, не люблю я магию под капотом
Забыли упоминуть об инвесии зависимостей, на картинах она есть, но подробно не разобрана, хотя является одной из ключевых особенностей
Наверное больше зарубежные, не сказать что большой опыт в собеседованиях, но не припомню чтобы в наших компаниях было что то подобное
"условие ожидания — Condition await()/signal(). С synchronized это недоступно. " - а как же wait и notify?
А ещё можно на ассемблере написать - просто летать будет. Естественно что спринг добавляет оверхед и если его не использовать будет быстрее, но удобнее - большой вопрос
один сервер НЕ всегда будет быстрее кластера, потому что у него есть потолок производительности, у кластера его нет (ну или почти нет :)), это называется горизонтальное масштабирование
Насчет DTO, их имеет смысл использовать, когда сигнатруа метода раздувается до 5 и более параметров, это никак не связано с Rest API, такого правила желательно придерживаться в любом API
"Синхронное API — одна из ключевых причин низкой производительности вебсервисов."
Вообще странное утверждение потому что синхронный вызовы по умолчанию быстрее асинхронных, т.к. не используются очереди, дополнительные потоки и т.д.
А насчет "Что произойдет если появится необходимость добавить новый параметр?" у RequestParam есть проперть defaultValue которую всегда можно выставить
Если честно, до конца не дочитал, наверняка еще найдется пара/трока спорных утверждений
Все это хорошо, но летом там ну очень жарко, а с учётом глобального потепления будет ещё жарче. Так что лето, по крайней мере, я бы проводил в другом месте, как американские пенсионеры, которые зимуют во флориде, а лето где нибудь по севернее, типа чикаго
handleRequest(key) там ещё может не быть запроса, потому что он может приходить по частям tcp не пакетный протокол
И наверное правильнее называть этот принцип более общим словом - модульная архитектура
Пользуюсь комьюнити идею начиная с первых дней её появления и никаких проблем не испытываю. Все эти визарды, плагины, все это костыли для тех кто под капот ленится заглядывать. А модульная или микросервисая архитектура позволяет быстро разобраться с проектом любой сложности.
А потом ваш впн начинает конфликтовать с рабочим и вы курите бамбук
Есть прекрасный сайт где все это собрано https://microservices.io/index.html и книга от того же перца
Microservices Patterns: With Examples in Java есть вроде и на русском, от неё мне спать не хотелось, увлекательное чтиво
Когда то я ехал в поезде с профессором, он возмущался по поводу зарплат. Я спросил у него сколько книг по профессии он прочёл за последнее время, на что он ответил, зачем мне что то читать, если если ничего нового не было с начала прошлого века. Вот по этому и такая разница в зарплате, программист учится пока работает. Каждые 3-5 лет новая мулька, не сказать чтобы сильно новая, но все же поизучать придётся.
По поводу оценки времени, если задача хорошо декомпозирована на подзадачи, проблем с оценкой нет. Для декомпозиции необходимо провести исследование и потратить 1, 2 дня иногда побольше, но иначе никак