It's a way to build and communicate with web servers using protocol buffers & gRPC on a NodeJS runtime.
Type safe middleware stack.
Heavily inspired based off the work that was done by Kevin with types-first-bff
Why NodeJS?
Asynchrony out of the box.
More importantly async IO.
Most of our micro-services are just shuffling data over the wire
The OS threading model does not scale well for IO bound services.
TCP and Bandwidth
a server can support several tens-of-thousands of concurrent TCP connections
Bandwidth not really problem because we are sending small packets of data over the wire. We are not Netflix.
Memory: How much memory each request consumes.
CPU: Depends on the application logic, but most of our services is are IO intensive and are just stitching data together.
OS
A request runs on a single OS thread to completion, and when it’s done, the web server is free to use that thread to serve other requests. So the number of concurrent request we can handle is also limited by the number of threads the OS can handle
Latency
Little’s law determines the load (request rate) a server can withstand given its (concurrent request) capacity and processing latency.
Why Tfapi?
Typescript is awesome.
Typescript everywhere.
The NodeJS gRPC apis are terrible.
Google wrote it and they do not care about JS.
Type safety
Developer experience
Enforced over the wire contracts and compile time guarantees
