А можете привести пример, что можно сделать в XML-конфигурации такого, что нельзя сделать через Conditional-аннотации в Java-конфигурации? Я просто начал работать сразу со Spring Boot и XML не использовал.
Осталось научиться игнорировать разницу в скорости пилотов из-за:
1. Машины, которая не подходит стилю одного из гонщиков. Пример из текущего сезона: Феттель/Леклер в Феррари. Проблемы Феррари со стабильностью задней части из-за неудачной подвески, настройки которой плавают в зависимости от температуры жидкости. Леклер смог к этому адаптироваться, а Феттель — нет. В итоге Феттель на 0.5 секунды медленнее. Можно еще взять любого партнера Алонсо после Хэмильтона, машины всегда строились именно под Алонсо.
2. Новой, незнакомой машины. Пример из прошлого: когда Хэмильтон пришел в Мерседес, он долго не мог использовать тормоза на 100%, потому что ощущения от них сильно отличались от тормозов Макларен. В то же время Росберг к тому времени был в команде давно и к тормозам привык. В тот сезон Нико был быстрее, но зато на следующий Льюис уже привык к машине и опережал.
Даже в моносерии не получится легко и просто сравнить пилотов, потому что машины нужно настраивать и не все команды могут правильно попасть в настройки.
Я думаю, что логика добаления unions такая-же, как изначально в TypeScript — возможность типизировать существующий код, например библиотеки, не ломая обратную совместимость.
Вы предлагаете фронтенд разработчику слегка подучить джаву и ваши гайдланы
Нет, я писал про ситуацию, в которой и фронт и бэк написаны на одном языке, на typescript, а не на java. Для систем, написанных на разных языках я не вижу альтернативы swagger.
Не проще ни разу, это довольно нудный бойлерплейт
Язык описания схемы в swagger более многословен, чем java + lombok, kotlin или typescript, так что в на swagger бойлерплейта будет больше. Плюс swagger менее удобен, когда спеку пора разбить на несколько файлов, не все инструменты экосистемы swagger нормально работают с $ref, ведущими в другой файл.
На много проще валидацию описать декларативно в сваггере, и пусть себе генерируется.
Валидация точно так же декларативно делается аннотациями на полях класса. Только в swagger кастомную аннотацию сложно добавить, а в код на java / typescript — просто.
см. обзор фич сваггера
И исходники генераторов, чтобы понять, какие из них реально поддерживаются.
Давайте я вам проясню мою позицию по swagger:
Идея технологии хорошая, но как и любая другая имеет свою область применения. В случае swagger еще добавляются особенности реализации — не все заявленные фичи поддерживаются для всех языков, поэтому нужно обязательно это иметь в виду, когда принимаешь решение о его использовании. В своих проектах я его использую, в основном spec first, но с удовольствием бы поменял на что-то более удобное и лучше сделанное.
фротендеру, чтобы править спеку, пришлось бы учить какой нибудь лютый expressjs и прочее node-специфическое г-но
Я вижу контракт API в виде отдельного модуля, который состоит из набора DTO и интерфейсов. В нем не должно быть ничего специфичного для клиента или сервера. DTO описывают, какие данные передаются в API, интерфейсы описывают, какие методы API доступны. Потом интерфейсы реализуются на фронте, чтобы получить клиент и на бэке, чтобы получить контроллер. Таким образом фронтенд-разработчик меняет именно контракт, не трогая реализацию бэкенда, бэкенд-разработчик — контракт, не трогая фронтенда. В этом же модуле можно сделать валидацию, ведь DTO не будут генерироваться через swagger, а будут переиспользоваться.
Для общения между модулями на java я использовал такой подход без swagger вообще.
сильно сомневаюсь, что спека из кода генерируется адекватно. Что правильно прописывает валидацию, например
Теоретически, springfox, который превращает java-классы в спеку, должен работать с JSR 303: Bean Validation, но практически я не видел поддержки валидации в генераторах фронта, хотя библиотеки c валидаторами на аннотациях для фронта я видел. Это основная проблема swagger — очень фрагментарная реализация фишек.
притягивать за уши nodejs чтобы всё писать на одном языке — это бред
Я думаю, что автор статьи привел хороший пример того, когда это удобно — проект, в котором одинаковые бизнес-правила нужны и на фронте и на бэке.
Как я уже писал, сильно зависит от проекта / команды. Например:
1.
проект, где фуллстеков не было, причем разработка спеки API шла от фронта
В этом проекте бэкенд-разработчик спеку вообще не трогал, можно было бы использовать code first
2. Проект, который я пишу сейчас, состоит из нескольких модулей, один занимается обработкой данных и спеку его API я писал от бэкенда, второй модуль — админка (формы / визарды на фронте), спеку его API я писал от фронта. Поэтому я использовал подход spec first, это позволило единообразно собирать оба модуля.
Вообще, я время от времени сталкиваюсь с тем, что спека написанная мной от бэкенда не полностью устраивает фронтенд-разработчика, так как я что-то не учел. Не вижу ничего плохого в том, что фронтенд-разработчик предложит правки к спеке, и сам их внесет после обсуждения. Мне кажется, что так будет быстрее, чем построчно объяснять мне, что и где поменять.
Самописного кода у вас там нет? Боюсь, как бы генератор его не потерял.
Это одно из ограничений подхода с генерацией кода, если не устраивает сгенерированный код — или переделать генератор или написать еще слой абстракции поверх или смириться с тем, что есть. Использую все три варианта в зависимости от задачи. Но код для обычного CRUD вполне нормальный.
как часто вам нужно менять модель и не менять сам код АПИ? Грубо говоря, если я добавил новое поле к условному заказу, то мне и обрабатывать его надо, так что бекенд работа всё равно присутствует.
Я имел в виду, что если используется подход code first, и спека API создается из аннотаций на java-классах бэкенда, то фронтенд-разработчик должен каждый раз на пальцах объяснять бэкенд-разрабочику, что он хочет поменять. В подходе же spec first они оба могут вносить изменения сразу в спеку. Да, изменения в спеке сломают проект и оба разработчика должны будут исправить свою часть проекта.
В идеале, конечно, иметь команду из фуллстеков, которые внесут изменения сразу и на фронт и на бэк, но так бывает не всегда. Я видел проект, где фуллстеков не было, причем разработка спеки API шла от фронта. В таком проекте code first со стороны бэка не подходил, возможно есть инструменты для code first со стороны фронта, тут я не в курсе.
Вообще, самое главное, по моему мнению, обеспечить типобезопасность для API, для этого нужны статически типизированные языки на фронте и бэке и единый источник правды, из которого потом будут сгенерированы клиенты API / интерфейсы для серверов. А что будет этим источником правды — спека swagger или классы с аннотациями — не так важно и определяется скорее структурой команды и/или проекта.
Фронт на typescript + react, бэк на java + spring, подход к контракту API — api spec first.
По спеке API генерируется клиент API с DTO для фронта и интерфейсы для контроллеров и DTO для бэка.
Если в API что-то поменять, то при сборке будут заново сгенерированы клиент, интерфейсы контроллеров и DTO, и на этапе компиляции typescript или java покажут сломанные места.
Главный плюс такого подхода: фронтенд-разработчик может менять спеку API так, как нужно ему, не зная java, бэкенд-разработчик может менять спеку не зная typescript. Естественно, этот плюс пропадает, если на фронте и бэке один язык.
Главный минус: официальные генераторы кода. Некоторые вещи сложно выразить, например streaming больших файлов. Некоторые вещи, описанные в документации swagger, поддерживаются не всеми генераторами или поддерживаются неправильно. В принципе качество кода этих генераторов ужасно (видел, когда улучшал поддержку некоторых нужных вещей).
Если бы на фронте и на бэке был typescript, то я бы использовал подход code first, выделив контракт API в модуль, который бы переиспользовался и на фронте и на бэке, руками написав реализацию этого контракта. По большому счету swagger нужен или в проекте с солянкой технологий или для публичного API.
Я бы предложил исправить неточность в статье — вместо «После прохождения теста вы увидите свои результаты и сможете создать профиль» должно быть «После прохождения теста оставьте нам максимум личной информации и тогда мы покажем вам результат». Не находите, что такой подход снижает готовность работать с вашей компанией и забивает вашу базу мусорными данными?
def parse(enum)
processor = MetadataProcessor.new
reader = ->(dir_path) {processor.read_metadata dir_path}
saver = ->(metadata) {processor.save_metadata metadata if metadata}
loop do
EM.run_block do
enum.portion.each do |dir_path|
# EventMachine вызывает первый коллбэк без параметров,
# поэтому необходимо обернуть лямбду с параметром в замыкание.
EM.defer(reader.carry(dir_path), saver)
end
end
end
end
Этот же код без каррирования:
def parse(enum)
processor = MetadataProcessor.new
reader = ->(dir_path) {processor.read_metadata dir_path}
saver = ->(metadata) {processor.save_metadata metadata if metadata}
loop do
EM.run_block do
enum.each do |dir_path|
# EventMachine вызывает первый коллбэк без параметров,
# поэтому необходимо обернуть лямбду с параметром в замыкание.
reader_closure = ->() {reader.(dir_path)}
EM.defer(reader_closure, saver)
end
end
end
end
То есть в этом случае каррирование — синтаксический сахар для создания замыкания.
Ну не совсем, преимущество Фау-2 было только в том, что ее было невозможно перехватить на том этапе развития ПВО, а по поводу боевой эффективности можно посмотреть на вики:
К 29 марта 1945 года около 10 000 было запущено по Англии; 3200 упали на её территории, из них 2419 достигли Лондона, вызвав потери в 6184 человек убитыми и 17 981 ранеными.
ракеты имели малую точность попадания (в круг диаметром 10 км попадало только 50 % запущенных ракет) и низкую надёжность (из 4300 запущенных ракет более 2000 взорвались на земле или в воздухе при запуске, либо вышли из строя в полёте). По различным источникам, пуск 2000 ракет, направленных за семь месяцев для разрушения Лондона, привели к гибели свыше 2700 человек (от каждой ракеты погибал один или два человека).
Doctrine к сторонним изменениям относится бережно — добавление геттеров-сеттеров инкрементальное (имеющиеся геттеры и сеттеры не изменяются, сторонние методы тоже, новые пишутся в конец класса), бэкап старого файла с классом делается автоматически. IDE подствечивает отличия от текущей ревизии VCS, всегда можно в этом убедиться после генерации. Проблем с модификацией классов сущностей и параллельным добавлением новых полей с помощью генерации кода нет.
Наконец-то они одумались! Нужна не строгая проверка на тип, а приведение.
У меня несколько иное мнение на этот счет. Можете почитать эту ветку комментов, например. А если коротко — то в современных фреймворках объект, инкапсулирующий запрос, имеет методы для получения ключей с приведеднием к заданному типу. Поэтому строгая типизация, без приведения, лучше, чем приведение «без потерь», так как разработчик всегда знает, какой тип нужно ожидать в том или ином ключе, а строгая типизация делает валидацию неизбежной.
1. Машины, которая не подходит стилю одного из гонщиков. Пример из текущего сезона: Феттель/Леклер в Феррари. Проблемы Феррари со стабильностью задней части из-за неудачной подвески, настройки которой плавают в зависимости от температуры жидкости. Леклер смог к этому адаптироваться, а Феттель — нет. В итоге Феттель на 0.5 секунды медленнее. Можно еще взять любого партнера Алонсо после Хэмильтона, машины всегда строились именно под Алонсо.
2. Новой, незнакомой машины. Пример из прошлого: когда Хэмильтон пришел в Мерседес, он долго не мог использовать тормоза на 100%, потому что ощущения от них сильно отличались от тормозов Макларен. В то же время Росберг к тому времени был в команде давно и к тормозам привык. В тот сезон Нико был быстрее, но зато на следующий Льюис уже привык к машине и опережал.
Даже в моносерии не получится легко и просто сравнить пилотов, потому что машины нужно настраивать и не все команды могут правильно попасть в настройки.
Нет, я писал про ситуацию, в которой и фронт и бэк написаны на одном языке, на typescript, а не на java. Для систем, написанных на разных языках я не вижу альтернативы swagger.
Язык описания схемы в swagger более многословен, чем java + lombok, kotlin или typescript, так что в на swagger бойлерплейта будет больше. Плюс swagger менее удобен, когда спеку пора разбить на несколько файлов, не все инструменты экосистемы swagger нормально работают с $ref, ведущими в другой файл.
Валидация точно так же декларативно делается аннотациями на полях класса. Только в swagger кастомную аннотацию сложно добавить, а в код на java / typescript — просто.
И исходники генераторов, чтобы понять, какие из них реально поддерживаются.
Давайте я вам проясню мою позицию по swagger:
Идея технологии хорошая, но как и любая другая имеет свою область применения. В случае swagger еще добавляются особенности реализации — не все заявленные фичи поддерживаются для всех языков, поэтому нужно обязательно это иметь в виду, когда принимаешь решение о его использовании. В своих проектах я его использую, в основном spec first, но с удовольствием бы поменял на что-то более удобное и лучше сделанное.
Я вижу контракт API в виде отдельного модуля, который состоит из набора DTO и интерфейсов. В нем не должно быть ничего специфичного для клиента или сервера. DTO описывают, какие данные передаются в API, интерфейсы описывают, какие методы API доступны. Потом интерфейсы реализуются на фронте, чтобы получить клиент и на бэке, чтобы получить контроллер. Таким образом фронтенд-разработчик меняет именно контракт, не трогая реализацию бэкенда, бэкенд-разработчик — контракт, не трогая фронтенда. В этом же модуле можно сделать валидацию, ведь DTO не будут генерироваться через swagger, а будут переиспользоваться.
Для общения между модулями на java я использовал такой подход без swagger вообще.
Теоретически, springfox, который превращает java-классы в спеку, должен работать с JSR 303: Bean Validation, но практически я не видел поддержки валидации в генераторах фронта, хотя библиотеки c валидаторами на аннотациях для фронта я видел. Это основная проблема swagger — очень фрагментарная реализация фишек.
Я думаю, что автор статьи привел хороший пример того, когда это удобно — проект, в котором одинаковые бизнес-правила нужны и на фронте и на бэке.
1. В этом проекте бэкенд-разработчик спеку вообще не трогал, можно было бы использовать code first
2. Проект, который я пишу сейчас, состоит из нескольких модулей, один занимается обработкой данных и спеку его API я писал от бэкенда, второй модуль — админка (формы / визарды на фронте), спеку его API я писал от фронта. Поэтому я использовал подход spec first, это позволило единообразно собирать оба модуля.
Вообще, я время от времени сталкиваюсь с тем, что спека написанная мной от бэкенда не полностью устраивает фронтенд-разработчика, так как я что-то не учел. Не вижу ничего плохого в том, что фронтенд-разработчик предложит правки к спеке, и сам их внесет после обсуждения. Мне кажется, что так будет быстрее, чем построчно объяснять мне, что и где поменять.
Это одно из ограничений подхода с генерацией кода, если не устраивает сгенерированный код — или переделать генератор или написать еще слой абстракции поверх или смириться с тем, что есть. Использую все три варианта в зависимости от задачи. Но код для обычного CRUD вполне нормальный.
Я имел в виду, что если используется подход code first, и спека API создается из аннотаций на java-классах бэкенда, то фронтенд-разработчик должен каждый раз на пальцах объяснять бэкенд-разрабочику, что он хочет поменять. В подходе же spec first они оба могут вносить изменения сразу в спеку. Да, изменения в спеке сломают проект и оба разработчика должны будут исправить свою часть проекта.
В идеале, конечно, иметь команду из фуллстеков, которые внесут изменения сразу и на фронт и на бэк, но так бывает не всегда. Я видел проект, где фуллстеков не было, причем разработка спеки API шла от фронта. В таком проекте code first со стороны бэка не подходил, возможно есть инструменты для code first со стороны фронта, тут я не в курсе.
Вообще, самое главное, по моему мнению, обеспечить типобезопасность для API, для этого нужны статически типизированные языки на фронте и бэке и единый источник правды, из которого потом будут сгенерированы клиенты API / интерфейсы для серверов. А что будет этим источником правды — спека swagger или классы с аннотациями — не так важно и определяется скорее структурой команды и/или проекта.
Фронт на typescript + react, бэк на java + spring, подход к контракту API — api spec first.
По спеке API генерируется клиент API с DTO для фронта и интерфейсы для контроллеров и DTO для бэка.
Если в API что-то поменять, то при сборке будут заново сгенерированы клиент, интерфейсы контроллеров и DTO, и на этапе компиляции typescript или java покажут сломанные места.
Главный плюс такого подхода: фронтенд-разработчик может менять спеку API так, как нужно ему, не зная java, бэкенд-разработчик может менять спеку не зная typescript. Естественно, этот плюс пропадает, если на фронте и бэке один язык.
Главный минус: официальные генераторы кода. Некоторые вещи сложно выразить, например streaming больших файлов. Некоторые вещи, описанные в документации swagger, поддерживаются не всеми генераторами или поддерживаются неправильно. В принципе качество кода этих генераторов ужасно (видел, когда улучшал поддержку некоторых нужных вещей).
Если бы на фронте и на бэке был typescript, то я бы использовал подход code first, выделив контракт API в модуль, который бы переиспользовался и на фронте и на бэке, руками написав реализацию этого контракта. По большому счету swagger нужен или в проекте с солянкой технологий или для публичного API.
Этот же код без каррирования:
То есть в этом случае каррирование — синтаксический сахар для создания замыкания.
Фау-1: Боевое применениеФау-2: Боевое применение