«OpenApi упомянут» — не нашёл. Поиск по тексту в браузере ctrl+F «OpenApi» «Open Api» «swagger» и «сваггер» так же не дал результатов.
«не нравится идея генерировать «болванку» для сервиса на основе yml и клиента как отдельную сборку» — хотелось бы аргументов
«Хорошо подходит для web-приложений, где нужно предоставлять большое количество разнородных и часто меняющих структуру данных» — чем же для этого плох сваггер? Он как бы считается пром стандартом, и структур данных в спеке можно много наобъявлять, и менять их легко. Но в отличие от вашего решения сваггер унифицирует апи и предоставляет бесплатно транспорт, валидацию и документацию.
«Если Вы знакомы с упоминаемой книгой Хорсдала, Вы поймете, почему я привел именно этот пример.» — знаком. Но там имхо существует путаница между журналированием и логированием (да, спасибо за поправку). Если ваш мета сервис именно _журналирует_, то вопросов нет. Но у вас же сервис назван Logger-ом — логично предположить из названия, что он «логирует»
Кроме того остался вопрос межсервисной коммуникации — как в вашей архитектуре её осуществлять, вручную? но это не правильно.
Сегодня статья была про 6 грехов программиста, вот у вас тут как минимум 2 — оверинжиниринг и велосипед. Велосипед потому, что вы игнорируете общепринятые стандартные фреймворки для микросервисов: OpenApi для веб и grpc для внутреннего взаимодействия. Они обеспечивают валидацию, транспорт и документирование апи, создают из декларативного описания сервисов код клиента и заглушки для конечных точек (grpc к тому же обеспечивает двунаправленный стриминг) — всё это в вашем случае придётся выполнять вручную. И вы блин такое рекомендуете другим? не смешите. У вас всё взаимодействие сервисов сводится к редиректу запроса — вы серьёзно считаете, что это исчерпывающий кейс?
Кроме того, ваши измышления противоречат 12 factor apps в части логгирования. К вашему сведению, логи пишутся в консоль и никуда более, и далее транслируются в систему типа ELC. Иные решения, в стиле вашего ActivityLogger — грех.
Для систем, написанных на разных языках я не вижу альтернативы swagger
Ну вот автор утверждает, что у него всё на ts, и тем не менее из кода генерируется спека сваггера в качестве документации. Получается, даже написав всё на одном языке сваггер всё равно нужен. Вот только, как мы выяснили, такая документация не соответствует апи или не является полной. Поскольку, например, декларативную валидацию из кода на ts едва ли адекватно воспроизведёт тулза, генерирующая спеку сваггера (аналогично другие фичи).
swagger менее удобен, когда спеку пора разбить на несколько файлов, не все инструменты экосистемы swagger нормально работают с $ref, ведущими в другой файл.
ну это значит экосистема совсем никудышная, раз таки мелочи не осиливает
Я вижу контракт API в виде отдельного модуля, который состоит из набора DTO и интерфейсов
Авторы OpenApi к счастью видят это по другому, поэтому добавили в сваггер много чего ещё, см. обзор фич сваггера. Сразу же возникает куча вопросов — как задать в ваших модулях методы аутентификации, схемы AND|OR авторизации, доп. форматы(base64 string, date-time, bsonobjectid и т.п.), доп. валидацию «через интиерфейс». Я понимаю, что какие-то ответы у вас могут быть, но могу заверить — они точно не понравятся любому, кто не пишет регулярно на java, особенно фронтендерам
Вы предлагаете фронтенд разработчику слегка подучить джаву и ваши гайдланы, которые вам кажутся простыми. Но у него своих гайдлайнов хватает. Потом ему предложат написать ui для бекенда на рубях — ror учить? едва ли это кому-то понравится. Проще изучить OpenApi вместо специфических гайдлайнов и ЯП. Зачем фронтендеру вникать что можно и что нельзя делать в вашем проекте, если есть де факто стандартный язык компактного и декларативного описания сервисов?
В этом же модуле можно сделать валидацию, ведь DTO не будут генерироваться через swagger, а будут переиспользоваться.
Не проще ни разу, это довольно нудный бойлерплейт, особенно если нужен канонический RESTfull и требуется выбирать нужные коды ошибок хттп. На много проще валидацию описать декларативно в сваггере, и пусть себе генерируется.
Для общения между модулями на java я использовал такой подход без swagger вообще.
для такого есть другая универсальная технология — grpc. Используется чуть более чем везде .
Я думаю, что автор статьи привел хороший пример того, когда это удобно.
Да не сказал бы. Автор привёл пример примитивного круд сервиса, коих сотни тысяч на любых языках.
«проект, в котором одинаковые бизнес-правила нужны и на фронте и на бэке» — к сожалению такая формулировка мне не понятна
Да, у меня очень похоже всё на ваш воркфлоу, только у меня го, поэтому ни какие доп. хттп фреймворки типа спринга не нужны. Спеку правят совместно бэкендеры и фронтендеры, ревьюется тимлидом — и это всема удобно я бы сказал. Из спеки генерится всё — модели для сервера и фронта, валидация, транспорт, аутентификация, простой fetch-клиент и т.д.
«Главный минус: официальные генераторы кода» — я так понимаю это для всех языков. В го ни кто не пользуется офиц. генератором, есть годная сторонняя либа
«Если бы на фронте и на бэке был typescript, то я бы использовал подход code first» — ага, и фротендеру, чтобы править спеку, пришлось бы учить какой нибудь лютый expressjs и прочее node-специфическое г-но, ломая при этом проект бекенда. Человек занят важным делом — пиксили подгоняет, flexbox-ы выравнивает. И тут ему — фигакс! — внезапно надо лезть в серверный код.
Во-2, сильно сомневаюсь, что спека из кода генерируется адекватно. Что правильно прописывает валидацию, например. Правильно понимает схемы авторизации. Это всё не тривиально.
И вообще притягивать за уши nodejs чтобы всё писать на одном языке — это бред. Нет конкаренси, нет праллелизма, код изуродован асинхронщиной, npm этот дебильный с миллиардам node_modules — чего ради? На рынке труда полно соискателей со знанием js/ts(react) + ЯП бекенда. Ориентироваться на тупых, ниасиливших второй ЯП? если только
«swagger нужен или в проекте с солянкой технологий» — ну то есть везде где есть веб. Вот и я говорю — пром. стандарт
Проблема в привязке к стеку проприетарных технологий там, где в этом нет ни малейшей необходимости. Спеку OpenApi проще читать, чем контроллеры asp net, она более выразительна и компактна. Проще перейти с работающего прототипа asp net на тот же nodejs. Проще декларативно прописать валидацию, аутентификацию, композирование требований безопасности и т.д.
Я должен добавить его в спецификации и у меня автоматически обновится соответствующая модель в исходном коде?
Разумеется так, иначе нафиг оно всё это было бы нужно
Не работал с таким потоком
хз как это сделано в net (и сделано ли). Но в том яп, который я использую, это всё на достаточно рабочем уровне
swagger-описание REST API должно автоматически генерироваться из исходного кода
Это в корне не верно. OpenApi — пром. стандарт описания сервисов, соответственно пишутся сервисы на сваггере, и из сваггер-описания генерируются заглушки с исходным кодом с готовым транспортом и валидацией. А не наоборот.
2.
Тимлиды не разруливают споры между бэкендерами и фронтендерами;
Во только при чём тут выбор ЯП для бэка? Вообще ни как не связано. Есть огромное количество бэкендов, написанных на ЯП, отличных от js/ts и C#, в которых тимлиды и близко ничего такого не разруливают, да и разруливать нечего ввиду отсутствия споров.
3. Из предыдущего
чтобы загрузить все ядра сервера придется воспользоваться модулем “Cluster” или внешним управлением процессами.
Опять таки решение не имеет ничего общего с задачей. «чтобы загрузить все ядра сервера», нужно оптимизировать CPU-bound вычисления. Cluster к этому ни каким боком
Валидация, транспорт и генерирование типов апи из схемы — это всё задачи фреймворка swagger, thrift, grpc, gql/apollo.js. Решать это вручную — жуткий колхоз, кодовая помойка и полное непонимание принципов распределённых систем. Отсутствие базовых знаний о базовых знаниях о мире
Ну это развод лохов. F# может оперировать любыми объектами .Net, которые вполне могут быть null. Обычные строки, например, или массивы. Но по на самом то деле проблемы null dereference нет в том виде, как её преподносят адепты фп — первый же прогон интеграционных тестов даёт эксепшон, и null dereference мгновенно фиксится по стектрейсу
А вот тайп-суммы — полезная штука. Но конечно не настолько полезная, чтобы переходить из-за неё с топового языка на язык с хреновым IntelliSense и отсутствием фреймворков.
С другой стороны, есть задачи для которых ни фреймворки, ни зависимость от внешних C# либ не нужны. Парсинг например — вот тут F# на высоте, есть весьма удобная либа для парсер-комбинаторов. Или например сложные билинговые расчёты. В общем F# годен там, где чистая математика — вот там пригодится улучшенный вывод типов и тайп-суммы
Затем, что useState и useReducer предоставляют те же опции, что стейт контейнеры. При этом не создают гемороя и идиотизма, свойственного приложениям со стейт контейнерами
Вы забыли упомянуть про WCF — какое это старое г-но. grpc делает в сущности примерно то же самое и поэтому не нужен по вашей логике
«не нравится идея генерировать «болванку» для сервиса на основе yml и клиента как отдельную сборку» — хотелось бы аргументов
«Хорошо подходит для web-приложений, где нужно предоставлять большое количество разнородных и часто меняющих структуру данных» — чем же для этого плох сваггер? Он как бы считается пром стандартом, и структур данных в спеке можно много наобъявлять, и менять их легко. Но в отличие от вашего решения сваггер унифицирует апи и предоставляет бесплатно транспорт, валидацию и документацию.
«Если Вы знакомы с упоминаемой книгой Хорсдала, Вы поймете, почему я привел именно этот пример.» — знаком. Но там имхо существует путаница между журналированием и логированием (да, спасибо за поправку). Если ваш мета сервис именно _журналирует_, то вопросов нет. Но у вас же сервис назван Logger-ом — логично предположить из названия, что он «логирует»
Кроме того остался вопрос межсервисной коммуникации — как в вашей архитектуре её осуществлять, вручную? но это не правильно.
Кроме того, ваши измышления противоречат 12 factor apps в части логгирования. К вашему сведению, логи пишутся в консоль и никуда более, и далее транслируются в систему типа ELC. Иные решения, в стиле вашего ActivityLogger — грех.
Вы предлагаете фронтенд разработчику слегка подучить джаву и ваши гайдланы, которые вам кажутся простыми. Но у него своих гайдлайнов хватает. Потом ему предложат написать ui для бекенда на рубях — ror учить? едва ли это кому-то понравится. Проще изучить OpenApi вместо специфических гайдлайнов и ЯП. Зачем фронтендеру вникать что можно и что нельзя делать в вашем проекте, если есть де факто стандартный язык компактного и декларативного описания сервисов?
Не проще ни разу, это довольно нудный бойлерплейт, особенно если нужен канонический RESTfull и требуется выбирать нужные коды ошибок хттп. На много проще валидацию описать декларативно в сваггере, и пусть себе генерируется.для такого есть другая универсальная технология — grpc. Используется чуть более чем везде .Да не сказал бы. Автор привёл пример примитивного круд сервиса, коих сотни тысяч на любых языках.
«проект, в котором одинаковые бизнес-правила нужны и на фронте и на бэке» — к сожалению такая формулировка мне не понятна
«Главный минус: официальные генераторы кода» — я так понимаю это для всех языков. В го ни кто не пользуется офиц. генератором, есть годная сторонняя либа
«Если бы на фронте и на бэке был typescript, то я бы использовал подход code first» — ага, и фротендеру, чтобы править спеку, пришлось бы учить какой нибудь лютый expressjs и прочее node-специфическое г-но, ломая при этом проект бекенда. Человек занят важным делом — пиксили подгоняет, flexbox-ы выравнивает. И тут ему — фигакс! — внезапно надо лезть в серверный код.
Во-2, сильно сомневаюсь, что спека из кода генерируется адекватно. Что правильно прописывает валидацию, например. Правильно понимает схемы авторизации. Это всё не тривиально.
И вообще притягивать за уши nodejs чтобы всё писать на одном языке — это бред. Нет конкаренси, нет праллелизма, код изуродован асинхронщиной, npm этот дебильный с миллиардам node_modules — чего ради? На рынке труда полно соискателей со знанием js/ts(react) + ЯП бекенда. Ориентироваться на тупых, ниасиливших второй ЯП? если только
«swagger нужен или в проекте с солянкой технологий» — ну то есть везде где есть веб. Вот и я говорю — пром. стандарт
2.Во только при чём тут выбор ЯП для бэка? Вообще ни как не связано. Есть огромное количество бэкендов, написанных на ЯП, отличных от js/ts и C#, в которых тимлиды и близко ничего такого не разруливают, да и разруливать нечего ввиду отсутствия споров.
3. Из предыдущего Опять таки решение не имеет ничего общего с задачей. «чтобы загрузить все ядра сервера», нужно оптимизировать CPU-bound вычисления. Cluster к этому ни каким боком
Интеграционные и функциональные — да, они пишутся согласно спецификации на апи и покрывают всё возможные сценарии. Иначе грош им цена
Ну это развод лохов. F# может оперировать любыми объектами .Net, которые вполне могут быть null. Обычные строки, например, или массивы. Но по на самом то деле проблемы null dereference нет в том виде, как её преподносят адепты фп — первый же прогон интеграционных тестов даёт эксепшон, и null dereference мгновенно фиксится по стектрейсу
А вот тайп-суммы — полезная штука. Но конечно не настолько полезная, чтобы переходить из-за неё с топового языка на язык с хреновым IntelliSense и отсутствием фреймворков.
С другой стороны, есть задачи для которых ни фреймворки, ни зависимость от внешних C# либ не нужны. Парсинг например — вот тут F# на высоте, есть весьма удобная либа для парсер-комбинаторов. Или например сложные билинговые расчёты. В общем F# годен там, где чистая математика — вот там пригодится улучшенный вывод типов и тайп-суммы