Hi HN, this is Danny, Deep, and Zach.
We built Fern after our previous ed tech startup failed. We were frustrated with how much time we spent writing “API code” instead of working on the actual product. We tried to use OpenAPI but we were underwhelmed - the generated code wasn’t idiomatic and it still required manual work (custom templates, scripts, manually publishing SDKs to registries).
The Fern compiler takes your API as input and invokes generators that output things like: SDKs, server code, a Postman collection, and an OpenAPI spec.
Some technical highlights about the compiler + generators:
- The compiler (available as a CLI) handles syntactic + semantic validation. It also includes a linter that encodes best practices. If your API Definition compiles, you can have high confidence that the SDKs will generate correctly.
- After all the parsing and validation, the compiler outputs an intermediate representation that gets handed off to the generators. This prevents each generator from re-implementing the same parsing and validation logic.
- Each generator is implemented in the language it is targeting - e.g. the Python generators are written in Python, the TypeScript generators are written in TS. It makes the SDKs more idiomatic because every programming language generally has the best tooling/libraries for generating code in itself. We also think it’ll make community involvement + contribution easier.
- The generators can output the code to disk, but also push the code to a Github repo and publish the SDK directly to registries (e.g. npm, Maven).
We are looking for devs to use Fern for API development. If you have any feedback about the process, compiler, or the generated code, we’d love to hear it.
"Plant Store" example: https://github.com/fern-api/plantstore-api
Generated repos:
- https://github.com/fern-api/plantstore-node
- https://github.com/fern-api/plantstore-java
- https://github.com/fern-api/plantstore-postman
- https://github.com/fern-api/plantstore-openapi
Reading the https://www.buildwithfern.com/docs/why-fern page, I wonder why not Smithy? They also have 1:1 IDL:AST. Is it too complex for just HTTP-JSON api?
I'm quite inclined to just follow Smithy spec (or subset), they seem to encounter many edge cases e.g. client codegen backward compatibility (https://smithy.io/2.0/spec/type-refinement-traits.html#clien...)
If it is to avoid java based tooling, it is bad to build your-fav-lang tools around its AST? Skipping the IDL + java parser coupling part.
I'm thinking if it's inevitable in this space to always have N+1 standard-ish problem. I found that what I come up with it's pretty close to Smithy.
What do you think why not Smithy?