4 ms·

Fern: A cross-language alternative to tRPC

5 points by zachkirsch 4y ago

zachkirsch 4y ago
_Showing is better than telling:_ Here's a Loom if you want to see a demo of using Fern + Express: https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba Hi HN, I'm a huge tRPC fan because it subtly forces you to practice schema driven API development. You start by defining your API (using zod), and as a result, you get awesome autocomplete in your IDE. However, there are a few things about tRPC I don't particularly like: 1. It's for TypeScript backends only! Sometimes I want the same value prop as tRPC but I need to write the backend in python (e.g. for ML applications). 2. It's for TypeScript frontends only! tRPC gives you a TypeScript client out of the box, but no other languages. You can go tRPC -> OpenAPI, but the OpenAPI-generated clients are pretty bad - definitely not up to the bar of what I'd show to a customer. 3. The wire format of tRPC's requests are pretty bonkers. They eschew normal REST conventions, so it's pretty painful to interact with tRPC from curl, Postman, and other languages besides TypeScript. Fern is similar to tRPC but for cross-language development: 1. Define your API in a simple format - similar to OpenAPI but much easier to read and write. 2. Generate server boilerplate - very similar to the tRPC experience, but we support Express, FastAPI, and Java Spring. Here's a Loom if you want to see a demo of using Fern + Express: https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba 3. Generate client SDKs that are actually good. The initial spec is purpose-built for code generation, so the resulting SDKs are actually production quality - e.g. FlatFile uses Fern for their Node SDK! https://github.com/FlatFilers/flatfile-node https://github.com/FlatFilers/flatfile-node. 4. Work with your favorite tools! You can easily generate an OpenAPI spec and Postman collection as well.

5 points by zachkirsch 4y ago

_Showing is better than telling:_ Here's a Loom if you want to see a demo of using Fern + Express: https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba Hi HN, I'm a huge tRPC fan because it subtly forces you to practice schema driven API development. You start by defining your API (using zod), and as a result, you get awesome autocomplete in your IDE. However, there are a few things about tRPC I don't particularly like: 1. It's for TypeScript backends only! Sometimes I want the same value prop as tRPC but I need to write the backend in python (e.g. for ML applications). 2. It's for TypeScript frontends only! tRPC gives you a TypeScript client out of the box, but no other languages. You can go tRPC -> OpenAPI, but the OpenAPI-generated clients are pretty bad - definitely not up to the bar of what I'd show to a customer. 3. The wire format of tRPC's requests are pretty bonkers. They eschew normal REST conventions, so it's pretty painful to interact with tRPC from curl, Postman, and other languages besides TypeScript. Fern is similar to tRPC but for cross-language development: 1. Define your API in a simple format - similar to OpenAPI but much easier to read and write. 2. Generate server boilerplate - very similar to the tRPC experience, but we support Express, FastAPI, and Java Spring. Here's a Loom if you want to see a demo of using Fern + Express: https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba https://www.loom.com/share/31f4243c4d824c54938bdc4840fbb8ba 3. Generate client SDKs that are actually good. The initial spec is purpose-built for code generation, so the resulting SDKs are actually production quality - e.g. FlatFile uses Fern for their Node SDK! https://github.com/FlatFilers/flatfile-node https://github.com/FlatFilers/flatfile-node. 4. Work with your favorite tools! You can easily generate an OpenAPI spec and Postman collection as well.