Мне хочется понять, в чем плюсы использования 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 со сгенерированным клиентом, только намного удобнее.
Мы изучали вопрос переезда, так как у нас почти целиком не интерактивный контент рендерится. Но отсутствие Context API ломает основаный на нём React Query и CSS-in-JS, так что объём работы получился огромный.
Если у вас много данных __NEXT_DATA__ для гидрации и большой Total Blocking Time в Lighthouse для ре-рендера, то серверные компоненты могут с этим помочь.
Регистрация проекта состоит из двух простых шагов:
1) Авторизация через GitHub
2) Выбор проекта из списка доступных и заполнение данных кошелька для приема средств.
А можно наоборот? Я указываю проект, issue и перевожу деньги. Разработчик может их забрать после регистрации.
Несколько месяцев назад участвовал в отрисовке города Mamou. Всё что можно увидеть по ссылке появилось примерно за сутки с чистого листа.
Однако названиями улиц карту так никто и не дополнил…
Nominatim выделяет номер дома из поискового запроса и что-то с ним делает отдельно, понимает некоторые запросы на «естественном языке» (pubs in dublin).
От поиска в osm я жду скрипта формирования БД от ErshKUS :)
Swagger (OpenAPI) это стандарт описания схемы API который позволяет соединять разные системы. В том числе генерировать клиент.
Но часто бывает, что у нас одна кодовая база. Тогда описание схемы Swagger может быть излишним. tRPC решает эту задачу проще и удобнее.
Нет, не обязательно. Просто это типичный пример когда бэк и фронт существуют вместе. В одной кодовой базе, на одном языке.
tRPC предназначен и очень удобен в монолитных фулл стак приложениях, например на основе Next.JS. Он позволяет быстро и без лишних действий писать API с проверкой типов с помошью TypeScript. Райнтайм валидацию так же можно использовать, но это не обязательно.
trpc не генерирует никакого клиента. Вернее клиент есть и очень удобный, но весь он существует только в рамках TypeScript.
Простой резолвер выглядит так:
После этого на клиенте можно сразу писать
Если же на клиенте вызвать отсутствующий роут
То, браузер послушно отправит запрос на
/api/trpc/cart.test_RANDOM_STRING. Но TypeScript поймает это в билд тайм и в прод ошибка не уйдёт.Если у вас фулл стак монолит, то получается все преимущества Swagger со сгенерированным клиентом, только намного удобнее.
Метрики я указал.
Мы изучали вопрос переезда, так как у нас почти целиком не интерактивный контент рендерится. Но отсутствие Context API ломает основаный на нём React Query и CSS-in-JS, так что объём работы получился огромный.
Для новых проектов я бы рассматривал RSC, да.
Если у вас много данных __NEXT_DATA__ для гидрации и большой Total Blocking Time в Lighthouse для ре-рендера, то серверные компоненты могут с этим помочь.
Для интерактивного UI необходим JS и исходные данные. RSC на выходе имеет только HTML и не содержит ни JS, ни данных.
В данном случае нужно использовать обычный клиентский компонент. Он может быть пререндерен на сервере при необходимости.
Если интересно развиваться дальше как программист, то стоит продолжить улучшать эту программу. Это хороший тренировачный полигон.
ООП штука хорошая, но слишком большая. Советую для начала посмотреть что такое dataclass, а потом, перечитав тему Функции, переделать код ещё раз:
1. Нужно разделить всё на две части - одна исключительно рисует форму и получае данные, а другая считает площадь и стоимость.
2. Взаимодействие между ними должно сводиться к одной строчке: estimate = cost_out(order). 3. Ключеное слово global не использовать.
4. В рассчётной части не должно быть ни одной русской буквы, кроме комментариев.
Changes requested :-)
В Python нет goto
Tools->Disk Usage
А можно наоборот? Я указываю проект, issue и перевожу деньги. Разработчик может их забрать после регистрации.
Однако названиями улиц карту так никто и не дополнил…
От поиска в osm я жду скрипта формирования БД от ErshKUS :)
Можно каждый день.