Здравствуйте, Pauel, Вы писали:

P>>>Во вторых, меньше интеграционного кода, меньше шансов сломать.
P>·>Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать.
P>Наоборот, нужно, только не надо дублировать 100500 тестов либы которая для этого испольуется.
Если у тебя в c#-коде сервер есть аннотация [Header("blah")], то где-то в js-коде клиента надо будет интеграционно тестировать, что это именно этот хедер именно с этим именем именно на этом параметре. И так надо для каждого параметра и метода, и для каждой реализации клиента. В случае же если у вас будет написана спека openapi, то вам достаточно проверить, что клиент и сервер используют одинаковую спеку (банально сравнить контрольную сумму). В худшем случае протестировать совместимость пар версий спек (часто это можно сделать алгоритмически, см avro schema evolution rules).
Справедливо заметить, что всё равно нужно будет тестировать логику в любом случае, но, по крайней мере, 90% случаев интеграции хотя бы по типам и структуре данных это покроет (ту самую проблему, с которой тут началось обсуждение о dto-шках с 40 полями).

>> На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.
P>Парсер формата .proto тоже требует тестов.
Это не ваша забота. Этим занимаются инженеры гугла и тестируется всем миром.

P>И это сторонняя либа. Соответсвенно в продукте нет необходимости заниматься дурью и дублирвать все тесты подобного рода.
P>А вот тесты апи всё равно надо делать, не важно чем ты это апи пропишешь. Или у вас и таких тестов тоже нет?
Если оба апи используют ту же спеку, то они совместимы by-design.
Т.е. вы можете тестировать свой c#-сервер используя тестовый c#-клиент. А реальные пользователи могут использовать js-клиент, если он по той же спеке.

P>>>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.
P>·>Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.
P>Цикл разработки версии — месяцы, иногда и годы. И нужен быстрый способ менять апи в разработке.
Ну так в том же openapi это переместить парам из "in: query" в "in: header" и собственно всё. Сгеренённые сигнатуры методов, скорее всего, и не поменяются.

P>·>Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.
P>А ты похоже не в курсе, что нет полноценного grpc для веба, т.к. браузер и особенно приложение унутре, не контролируют полностью протокол хттп. А вот где грпц играет — в изолированой сети, когда созданы специальные условия.
Во-первых, в курсе. Во-вторых, и чё? В-третьих, rest это вовсе не означает, что непременно браузер. В-четвёртых, это просто пример. Пусть будет openapi вместо gprc, суть моего тезиса не менятеся.

P>>>Не надо изобретать — есть декларативные способы задания аспектов апи.
P>·>Где они есть-то? Ссылочку на стандарт можно?
P>grpcs это один из таких вариантов. Одна проблема — для веба не летает. А потому фремворки умеют все эти вещи.
P>еще есть graphql. И много чего есть. Фичи конкретного фремворка это эквивалентное решение.
Не очень понял. Какие именно "декларативные способы задания аспектов апи" ты имел в виду?

P>>>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
P>·>Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
P>Пока что эта сила в веб вылезть не может. грпц это круто, только что делать в вебе? есть grpc-web, но это костыль и он убог.
P>Теоретически, когда grpc вылезет из своей конуры, это будет прорыв в вебе. Но шота предпосылок к этому не имеется.
Потому что всем интересно изобретение фреймворков на аннотациях для своих любимых яп, побыстрому колбасят code-first, получить бонус и потом тратят время и деньги заказчиков на "писать клиентов нужно руками".

Здравствуйте, Pauel, Вы писали:

P>>>Во вторых, меньше интеграционного кода, меньше шансов сломать.
P>·>Потому что вы заблуждаетесь, что навешанные аннотации это не код и можно не тестировать.
P>Наоборот, нужно, только не надо дублировать 100500 тестов либы которая для этого испольуется.
Если у тебя в c#-коде сервер есть аннотация [Header("blah")], то где-то в js-коде клиента надо будет интеграционно тестировать, что это именно этот хедер именно с этим именем именно на этом параметре. И так надо для каждого параметра и метода, и для каждой реализации клиента. В случае же если у вас будет написана спека openapi, то вам достаточно проверить, что клиент и сервер используют одинаковую спеку (банально сравнить контрольную сумму). В худшем случае протестировать совместимость пар версий спек (часто это можно сделать алгоритмически, см avro schema evolution rules).
Справедливо заметить, что всё равно нужно будет тестировать логику в любом случае, но, по крайней мере, 90% случаев интеграции хотя бы по типам и структуре данных это покроет (ту самую проблему, с которой тут началось обсуждение о dto-шках с 40 полями).

>> На самом деле, каждая повешанная аннотация — это точно такой же код, как и всё остальное, и требует соответствующих тестов.
P>Парсер формата .proto тоже требует тестов.
Это не ваша забота. Этим занимаются инженеры гугла и тестируется всем миром.

P>И это сторонняя либа. Соответсвенно в продукте нет необходимости заниматься дурью и дублирвать все тесты подобного рода.
P>А вот тесты апи всё равно надо делать, не важно чем ты это апи пропишешь. Или у вас и таких тестов тоже нет?
Если оба потребителя апи используют ту же спеку, то они совместимы by-design.
Т.е. вы можете тестировать свой c#-сервер используя тестовый c#-клиент. А реальные пользователи могут использовать js-клиент, если он по той же спеке.

P>>>В третьих, в таких случаех обычно измненения требуют перекомпиляции, а не переписывания всего подряд что связано с переносом параметра из квери в хидеры.
P>·>Это работает в лучшем случае на местечковых небольших проектах, где все свои. Попробуй какой-нибудь гугл в своём api переместит параметр из квари в хидер — так пол мира сломается.
P>Цикл разработки версии — месяцы, иногда и годы. И нужен быстрый способ менять апи в разработке.
Ну так в том же openapi это переместить парам из "in: query" в "in: header" и собственно всё. Сгеренённые сигнатуры методов, скорее всего, и не поменяются.

P>·>Метаданные — это просто ещё один язык описания. Т.е. вместо того, чтобы использовать стандарт типа grpc, вы изобретаете своё на квадратных колёсах.
P>А ты похоже не в курсе, что нет полноценного grpc для веба, т.к. браузер и особенно приложение унутре, не контролируют полностью протокол хттп. А вот где грпц играет — в изолированой сети, когда созданы специальные условия.
Во-первых, в курсе. Во-вторых, и чё? В-третьих, rest это вовсе не означает, что непременно браузер. В-четвёртых, это просто пример. Пусть будет openapi вместо gprc, суть моего тезиса не менятеся.

P>>>Не надо изобретать — есть декларативные способы задания аспектов апи.
P>·>Где они есть-то? Ссылочку на стандарт можно?
P>grpcs это один из таких вариантов. Одна проблема — для веба не летает. А потому фремворки умеют все эти вещи.
P>еще есть graphql. И много чего есть. Фичи конкретного фремворка это эквивалентное решение.
Не очень понял. Какие именно "декларативные способы задания аспектов апи" ты имел в виду?

P>>>Собственно на всех платформах есть сотни решений для этого, а для тебя это похоже рокет саенс.
P>·>Вот именно, что сотни решений, у каждого свой велоспиед. А gprc — один, в этом и сила.
P>Пока что эта сила в веб вылезть не может. грпц это круто, только что делать в вебе? есть grpc-web, но это костыль и он убог.
P>Теоретически, когда grpc вылезет из своей конуры, это будет прорыв в вебе. Но шота предпосылок к этому не имеется.
Потому что всем интересно изобретение фреймворков на аннотациях для своих любимых яп, побыстрому колбасят code-first, получить бонус и потом тратят время и деньги заказчиков на "писать клиентов нужно руками".