Англійська для tRPC

Вся ідея tRPC — це одна ідея — безпека типів від початку до кінця без генерації коду — і обговорення цього добре означає, що можна пояснити цю ідею точно, оскільки її легко поєднати з GraphQL або OpenAPI на перший погляд.

Ключовий словник

** Безпека типів від початку до кінця ** — властивість, за якої зміна типу вводу або виводу процедури сервера негайно показує помилку типу у інтерфейсі, без файла схеми, кроку створення коду або окремої клієнтської бібліотеки, які б підтримували синхронізацію. “Ось що люди мають на увазі під безпекою типу end-to-end з tRPC — я змінив тип повернення на процедурі бекенду, і мій редактор негайно позначив код фронтенду, використовуючи його як помилку типу, без кроку генерації коду між ними.”

** Процедура ** — окрема функція сервера, відкрита через tRPC, або запит для читання даних, або мутація для запису, приблизно аналогічна кінцевій точці REST або розв’ язувачу GraphQL, але визначена як простий TypeScript. “Ми додали нову процедуру під назвою getUserSettings — це просто функція TypeScript на маршрутизаторі, але інтерфейс може викликати її безпосередньо з повним виведенням типів, без окремого визначення кінцевої точки.”

** Маршрутизатор ** — збірка пов’ язаних процедур, які можна вкладати разом, щоб впорядкувати API за доменом, і які інтерфейс імпортує за типом, щоб отримати повне автоматичне завершення і перевірку типів.

• “Маршрутизатор користувача групує всі процедури, пов’ язані з користувачем, разом — отримання, оновлення, вилучення — і ми імпортуємо лише його тип у інтерфейс, таким чином клієнт отримує повне автозавершення без імпортування будь- якого коду сервера.” *

** Без генерації коду ** - факт, що tRPC досягає безпеки типів безпосередньо імпортуючи типи TypeScript через кордон клієнт-сервер, на відміну від GraphQL або інструментів, заснованих на OpenAPI, які генерують клієнтський код зі схеми. “На відміну від нашого старого налаштування GraphQL, тут немає кроку генерації коду — ми не виконуємо команду codegen після кожної зміни схеми, тип просто надходить безпосередньо з імпорту типу маршрутизатора backend.”

** Перевірка вводу (через Zod) ** — звичайний шаблон парування процедур tRPC з бібліотекою перевірки схем, на зразок Zod, для перевірки вводу під час виконання, оскільки самі по собі типи TypeScript забезпечують лише безпеку під час компіляції, а не перевірку під час виконання. “Типові типи TypeScript зникають під час виконання, тому нам все ще потрібна перевірка вводу з Zod для цієї процедури — це те, що фактично відкидає неправильно сформований запит під час виконання, тип TypeScript допомагає тільки під час компіляції.”

Звичайні фрази

• «Чи це насправді безпека типу end-to-end, або ми все ще маємо вручну синхронізацію десь?»
• Чи є це новим методом, чи це вже існує в інших країнах?»
• Як ми можемо використовувати ці дані в нашій роботі?»
• Чи потрібно нам тут перевірка вводу, чи ми покладаємося на типи TypeScript окремо під час виконання?»
• «Чи ми впевнені, що немає жодного кроку генерації коду, який ховається десь в цьому налаштуванні?»

Приклади висловлювань

Пояснення основного цінностного пропозиції: “Причина, чому ми обрали tRPC над REST API, полягає в безпеці типу end-to-end — коли форма процедури бекенду змінюється, фронтенд отримує помилку компіляції відразу, замість помилки виконання, яку ми б зафіксували тільки в тестуванні або виробництві.”

Роз’ яснення питання щодо розробки API: “Це, ймовірно, має бути окремою процедурою, а не додатковим параметром існуючої процедури — це справді інша операція, і розділення її зберігає типи вводу і виводу кожної процедури чистими і специфічними.”

Виправлення поширеного нерозуміння: “Типові типи TypeScript не захищають нас під час виконання — хтось все одно може надіслати неправильно сформований JSON до цієї процедури. Нам потрібна реальна перевірка вводу з Zod тут, тип часу компіляції сам по собі не є межею безпеки.”

Професійні поради

• Провід з ** end-to-end тип безпеки **, коли пояснює, чому tRPC було обрано - це єдина особливість, яка найбільше відрізняє його від REST і навіть від GraphQL без codegen.
• Розробляйте кожну ** процедуру ** навколо однієї чіткої операції, замість перевантаження її багатьма параметрами і умовною поведінкою — це збереже зміст типів вводу і виводу.
• Організувати ** маршрутизатори ** за доменом, а не за дієсловом HTTP — групувати всі дії з ресурсом разом, а не розділяти їх за запитом проти мутації у окремих файлах.
• Підкресліть не генерування коду при порівнянні з налаштуваннями GraphQL, які вимагають запуску кроку кодгенерації після кожної зміни схеми — це реальна різниця в досвіді розробника, а не просто маркетинг.
• Ніколи не пропускайте ** перевірку вводу ** лише тому, що існують типи TypeScript — паруйте процедури з Zod або еквівалентним перевіркою схеми для безпеки під час виконання.

Практичні вправи

1. Пояснити, що означає «безпека типу end-to-end» і чому вона не вимагає генерації коду в tRPC.
2. Описати різницю між процедурою і маршрутизатором.
3. Напишіть речення, у якому поясните, чому перевірка введення все ще потрібна навіть у випадку типів TypeScript.

Система управління і управління: основи

Будьмо чесними - вивчення нової технічної області є достатньо складним, не спираючись на нюансове спілкування. Навіть якщо ви розумієте * концепції * tRPC - безпека типу end- to- end, відтворення на стороні сервера і маршрутизатори - вираження ваших ідей чітко англійською мовою в команді розробників може бути складним. Це не просто про те, щоб знати, що означає request; це про те, як ви описуєте його поведінку, запитуєте зміни або пояснюєте обґрунтування за вашими виборами дизайну. Це місце, де професійний англійський словник стає критичним, особливо для носіїв, для яких англійська не є рідною.

Розглянемо наступний сценарій: Ви провели цілий день над реалізацією нової процедури, яка використовує tRPC для автентифікації користувача. Під час перегляду коду ваш колега коментує: « Це виглядає трохи довгим; чи не могли б ми спростити визначення типу »? Просте твердження « це має бути простіше » не допоможе. Натомість, ти повинен відповідати з точністю. Використання таких фраз, як « Я прагнув до максимальної ясності і безпеки друку » або « Я знаю про потенційні наслідки для продуктивності і обрав цей підхід, щоб забезпечити міцний друк протягом всієї процедури », демонструє глибше розуміння і дозволяє вашому колегі конструктивно реагувати. Аналогічно, в Slack, запит на зворотний зв’язок не просто “Чи можете ви подивитися на це?” - це “Чи можете ви надати конкретний зворотній зв’язок щодо обробки помилок в рамках процедури автентифікації? Мене особливо цікавить, чи відповідає поточне впровадження стандартам журналювання помилок нашої команди. ” Ці невеликі зміни у формулюванні значно покращують співпрацю і зменшують непорозуміння.

Інша поширена ситуація виникає під час написання опису запитів на завантаження. Хороший опис це не просто резюме; це переконливий аргумент для змін, які ви зробили. Замість « Виправлено помилку » спробуйте « Впроваджено надійну обробку помилок у процедурі розпізнавання, щоб зменшити потенційні вразливості, пов’ язані з некоректними даними користувача, відповідно до найкращих практик безпеки, описаних у документації нашої команди ». Чим докладніше — і точніше — буде ваше словосполучення, тим краще. Це допомагає рецензентам зрозуміти * чому * за вашою роботою, а не тільки * що *. Спробуйте описати вплив ваших змін і те, як вони впливають на загальну архітектуру системи.

Нарешті, пам’ятайте, що технічні дискусії часто включають дебати про компроміси. Сказати «Це найкращий спосіб» не переконливо; пояснення * чому * це найкращий вибір, заснований на конкретних критеріях - таких як продуктивність, масштабованість або підтримка - демонструє впевнений і професійний підхід.

# Example CLI command for inspecting tRPC route definitions (using a hypothetical tool)
trpc inspect routes --format json

---

** Вміст початкового повідомлення (для контексту — не частина рішення) **

Англійська для tRPC (категорія: Словник)

tRPC набирає популярності в світі веб-розробки, особливо при створенні API, які вимагають сильної безпеки типів і ефективного відтворення на стороні сервера. Це потужна альтернатива REST і GraphQL, але розуміння специфічного словника, що його оточує, може значно поліпшити ваше спілкування з іншими розробниками. У цьому пості буде розглянуто ключові терміни, пов’ язані з tRPC, зосередившись на таких поняттях, як безпека типу end- to- end, процедури, маршрутизатори, і на тому, як вони відрізняються від традиційних підходів.

** Ключові слова: **

• ** Безпека типу End-to-End: ** Це * головна перевага tRPC. Це означає, що типи, визначені у коді вашого сервера, буде суворо дотримуватися під час виконання, запобігаючи багатьом типовим помилка ще до того, як вони дійдуть до клієнта. Думайте про це як про захисну сітку для вашого API.
• ** Процедура: ** У tRPC процедура є окремою функцією або дією на вашому сервері. Це аналогічна кінцева точка HTTP, але з вбудованою перевіркою типу.
• ** Маршрутизатор: ** Маршрутизатор відповідає за призначення вхідних запитів (зазвичай, HTTP- запитів) відповідним процедурам за їх шляхами і методами. Це центральний вузол вашого API tRPC.
• ** Відтворення на стороні сервера (SSR): ** Оскільки tRPC виконує код на сервері, він може створювати HTML безпосередньо, покращуючи швидкість і SEO у порівнянні з відтворенням на стороні клієнта, де переглядачеві потрібно отримувати дані і відтворювати їх.
• ** Серіалізація/ Десеріалізація: ** tRPC обробляє це автоматично за допомогою своєї системи типів, зменшуючи кількість коду і потенційних помилок.

Зрозуміння цих термінів є ключовим для обговорення tRPC з вашою командою, розробки ефективних API і вирішення проблем. Це більше, ніж просто знати слова; це розуміння основних принципів і того, як вони пов’язані один з одним. Цей словник допоможе вам ефективно спілкуватися під час співпраці над проектами tRPC.