Комментарии 5
Мне хочется понять, в чем плюсы использования 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 со сгенерированным клиентом, только намного удобнее.
Swagger (OpenAPI) это стандарт описания схемы API который позволяет соединять разные системы. В том числе генерировать клиент.
Но часто бывает, что у нас одна кодовая база. Тогда описание схемы Swagger может быть излишним. tRPC решает эту задачу проще и удобнее.
Эта библиотека именно под next.js
Нет, не обязательно. Просто это типичный пример когда бэк и фронт существуют вместе. В одной кодовой базе, на одном языке.
Исследование безопасности tRPC: Охота за уязвимостями в современных API