Using TypeScript to Define Service APIs
summary
Service-to-service RPC and events move from ad hoc HTTP routes to a generated interface that actually compiles and runs. The team builds philo idl as a tight subset of TypeScript, parses the AST into an interim object, and renders client, server and tests including generated encoders and decoders. Expect concrete migration timing, bugs encountered with protobuf tooling, the parser/refactor effort, test strategy (snapshot plus roundtrip encoding) and how many services migrated.
AI-written summary · about
chapters (22)
- 0:00Intro
- 0:28What was the problem?
- 2:01What is an IDL?
- 2:42What are some benefits for Convoy?
- 3:47What went wrong?
- 4:59What made this a hard decision? (Early 2019)
- 5:46How did we make a decision?
- 6:00Lower the risk of additional blocking issues
- 6:53Focus on ease of migration and current usability
- 7:32Make sure the solution can be changed in the future
- 8:10What decision did we make?
- 8:52How do we know it's right? We don't
- 10:28Filtering
- 11:13Parsers
- 12:53Example: Enum Parser
- 15:58Service Declaration - Piece of Interim Object
- 16:34Rendering Client/Server/Types
- 17:16Testing
- 18:48Filo Successes
- 20:54Discriminated Unions are AMAZINGI!
- 21:53Lessons Learned
- 24:18Commonly Asked Questions
related talks
31mBuilding an OpenAPI from Typescript
24mReliable I/O with the TypeScript Compiler API
33mTypeScript for APIs
33mEnd-to-End Type Safety with Swagger and TypeScript
39mEnd to end typing for web applications
38mScalaJS and Typescript: an unlikely romance
38mPorting 100K lines of code to TypeScript
26mAdopting Typescript at Scale