Комментарии 24
А тайп-чеккинг ответов с бэка на фронте проводится в рантайме? Или они принудительно приводятся к соответвующему типу, предлагая, что бэк иного прислать не может никогда и ни при каких условиях?
В рантайме нет никаких проверок, если бек вдруг пришлёт что то не то, то это считается багом и надо искать причины и чинить или бек или фронт
Как выявляется, что пришло что-то не то?
В любом случае, если приходит что то не то, это явное нарушение контракта и спецификации.
Надо смотреть логи и разбираться
Так вся эта машинерия со статической типизацией затевается не для валидации в рантайме, а для проверок во время билда. Чтобы можно было безопасно переименовывать сущности в API и было видно, где они используются.
Я к тому, что если тайпгвардов полноценных нет, то гарантии типов мало чего стоят.
гарантии типов мало чего стоят
Почему вы так считаете?
Ну какие могут быть гарантии, если где-то в коде что-то вроде:
async function getCurrentUser(): Promise<User> {
const response = await axios.get('/me')
return response.json as User;
}Так, а зачем вы такой код пишете?)
Так это же автогенеренный код, по типам с бека, которые проверены компилятором. Если эндпоинт вернет что-то не то — это ошибка в компиляторе бека или самом кодогенераторе, других вариантов нет. Если генерить рантайм-проверки то там может быть такая же ошибка, т.е. статические проверки уже дают максимум гарантий. Больше никак не получить.
Ещё может быть банальная рассинхронизация версий схем, ожидаемых клиентом и реально отправляемых сервером.
Ещё может быть банальная рассинхронизация версий схем, ожидаемых клиентом и реально отправляемых сервером.
Откуда она может взяться? Бек обновлен => типы перегенерены. С-но, типы всегда актуальные.
То, что они перегенерировались ещё не значит, что на фронте они актуальны. Особенно если фронтов несколько.
То, что они перегенерировались ещё не значит, что на фронте они актуальны.
Каким образом они могут быть неактуальны? Вы поменяли бек, перегенерили типы, теперь типы точно соответствуют тому, что на беке. Единственный рассинхрон может быть только в том случае, если забыли пергенерить. Но это решается элементарно — шаг генерации просто добавляется в сборку бека.
Если вы видите какой-то кейз, в котором типы окажутся неактуальны, вы опишите.
Перегенировалаи типы беком во время его сборки, но фронт после этого не собрали. Или собрали, но не задеплоили.
Перегенировалаи типы беком во время его сборки, но фронт после этого не собрали. Или собрали, но не задеплоили.
Очевидно, это все автоматически в рамках CI должно происходить. Тогда варианта, где кто-то что-то забыл, быть не может.
Понятно, что проблемы случиться могут.
Но нужно ли ради этих редких ситуаций тащить проверки типа typeof user.firstname === 'string' в свой бандл, если можно просто завернуть все в try/catch?
Использую такой же подход, очень удобно.
Для упрощения генерации кода по спецификации OpenAPI из Visual Studio (как для фронтенда на C# и TypeScript, так и бэкенда на C#) могу посоветовать расширение Unchase OpenAPI Connected Service, которое использует актуальный NSwag.
Инструкция по использованию на medium.com.
У нас был сервис, который требовал отдавать клиенту ответ со стасом ошибка или нет. Если ошибка — код ошибки и сообщение. Иначе — ответ с объектом или результатом.
Возникли приколы с попыткой отдавать изображения. Плюс были приколы с разными типами ошибок. Но все пришло в печаль, когда клиент рос и стал размером в 1000+ методов. Представьте насколько это удобно искать среди кучи методов необходимый Вам? Представили? А теперь добавьте еще 2-3 таких сервиса. Вуаля. Вас ненавидят (но это не точно). Поэтому от OperationId мы отказались. Также при инициализации клиента не заметил использования авторизации. У Вас сервис для внутренного использования или же просто это для теста?
Может, когда у сервиса 1000+ ендпоинтов, то надо их как-то разделить, если не физически (на микросервисы), то логически? И генерировать/писать клиентов типа UserServiceClient, OrderServiceClient и т. п., которые оформлять как отдельные пакеты, и каждое приложение ставит себе только нужные ему, а н еодного клиента, который знает о всех-всех ендпоинтах на проекте, а то и в компании.
Также при инициализации клиента не заметил использования авторизации. У Вас сервис для внутренного использования или же просто это для теста?
Мы используем метод transformOptions, который проставляет Authorization заголовок в http headers. В статье я не стал описывать этот момент.
Документация на сайте NSWAG
Но все пришло в печаль, когда клиент рос и стал размером в 1000+ методов. Представьте насколько это удобно искать среди кучи методов необходимый Вам? Представили?
Это печально конечно иметь сервис с 1000+ ендпоинтов, но мне кажется это вопрос организации кода и общего взаимодействия между сервисами и системами.
Я думаю что можно было сделать иначе, кроме как накидать 1000+ ендпоинтов в один микросервис.
Типизация REST API для фронтенд разработчика