Comments 5
tRPC расшифровывается как "TypeScript Remote Procedure Call" и использует возможности TypeScript для обеспечения безопасности типов на границах клиент-сервер.
А trpc - client можно сгенерировать на основе openAPI спеки ?
Я использую в проекте swagger client который генерирует апи на основе спеки и он так же обеспечивает безопасность типов на границах клиент-сервер.
У нас openAPI спека является обязательной для бэкенда.
На бэкенде пока node.js не используется, но даже если будет, что мешает его написать с использованием typeScript ? При этом оставив на клиенте swagger client на основе openAPI спеки, которая в любом случае будет составляться.
Мне хочется понять, в чем плюсы использования tRPC. Например я захочу его использовать. В чём я могу выиграть ?
Мне нравится swagger client потому что
1. Он экономит очень время. За счет автоматической генерации слиента.
2. Есть валидация запросов. Обеспечение безопасности типов на границах клиент-сервер.
3. Есть версионирование api на клиенте относительно спеки, которая используется на бэкенде в данный момент. Не возникает проблем при разработке в расхождении в запросах.
4. нет привязки к TypeScript. Если надо он используется, если нет то не используется. Например, на бэкенде может потребоваться AssemblyScript, тогда может быть будет актуально написать остальную часть сервера на js.
Мне хочется понять, в чем плюсы использования tRPC. Например я захочу его использовать.
tRPC предназначен и очень удобен в монолитных фулл стак приложениях, например на основе Next.JS. Он позволяет быстро и без лишних действий писать API с проверкой типов с помошью TypeScript. Райнтайм валидацию так же можно использовать, но это не обязательно.
А trpc - client можно сгенерировать на основе openAPI спеки ?
trpc не генерирует никакого клиента. Вернее клиент есть и очень удобный, но весь он существует только в рамках TypeScript.
Простой резолвер выглядит так:
// server side
const test = publicProcedure.query( async () => {
return { string: 'test', number: 123 }
})
export const cart = router({
test,
//...другие роуты
})После этого на клиенте можно сразу писать
const { data } = trpc.cart.test.useQuery()
// TypeScript видит тип возвращаемого значения!
console.log(data?.number, data?.string) Если же на клиенте вызвать отсутствующий роут
const { data } = trpc.cart.test_404_NOT_FOUND.useQuery()То, браузер послушно отправит запрос на /api/trpc/cart.test_RANDOM_STRING. Но TypeScript поймает это в билд тайм и в прод ошибка не уйдёт.
В чём я могу выиграть?
Если у вас фулл стак монолит, то получается все преимущества Swagger со сгенерированным клиентом, только намного удобнее.
Если у вас фулл стак монолит
удобен в монолитных фулл стак приложениях
То же самое что вы описали делается с тем же свагер клиентом, который я описал.
Причем здесь монолит ?
Next.JS
Я правильно понимаю. Эта библиотека именно под next.js тогда в основном и ориентированна ?
Swagger (OpenAPI) это стандарт описания схемы API который позволяет соединять разные системы. В том числе генерировать клиент.
Но часто бывает, что у нас одна кодовая база. Тогда описание схемы Swagger может быть излишним. tRPC решает эту задачу проще и удобнее.
Эта библиотека именно под next.js
Нет, не обязательно. Просто это типичный пример когда бэк и фронт существуют вместе. В одной кодовой базе, на одном языке.
Исследование безопасности tRPC: Охота за уязвимостями в современных API