This is good feedback that we need to provide more examples starting with OpenAPI instead of with the Fern Definition. For some context, we convert the OpenAPI spec into a Fern definition and then pass that into the code generators.
If you want to see some real world examples, check out these links:
:wave: Hey Mark -- I'm one of the primary contributors to Fern.
+1 to your comment about how needing to support multiple languages results in not being able to leverage certain language specific features. We've tried the best to manage the trade-offs here, but there's a limit to what you can do.
If you have feedback on how we can improve the TypeScript client, feel free to comment here or create an issue on our repo (https://github.com/fern-api/fern)!
@sthuck I'm working on an alternative in this space called Fern. Like gRPC, you define your schema and use it to generate client libraries + server code. Fern integrates with FastAPI/Express/Spring and generates clients in Python, Typescript, and Java.
Got it! Based on your comment / some googling it sounds like the common use case is for managing internal secrets.
Do you think it's a good fit if you want to use it for managing API Keys for your public API (you want your customers to generate a key and use it to call your api)? The 10k parameter limit per AWS account might conflict with that usecase.
It seems like in-house is the way to go since there are no other alternatives.
Things we would have to build:
- Generating API Keys (with expiry)
- Storing API Keys securely
- Revoking API Keys
- Adding metadata to API Keys
It seems like there could be a generic API to power all of that, while still enabling applications to be opinionated about whether the incoming request is authenticated and has the right permissions.
I'm not so much talking about the type of token issued (JWT/Opaque), but more about the service that manages issuing and revoking keys. (i.e. something similar to what Stripe has on their developer portal https://stripe.com/docs/keys).
This is good feedback that we need to provide more examples starting with OpenAPI instead of with the Fern Definition. For some context, we convert the OpenAPI spec into a Fern definition and then pass that into the code generators.
If you want to see some real world examples, check out these links:
- https://github.com/vellum-ai/vellum-client-generator/tree/ma... -> https://github.com/vellum-ai/vellum-client-python
- https://github.com/Squidex/sdk-fern/tree/main/fern/api/opena... -> https://github.com/Squidex/sdk-node
Worth calling out that you can go from the Fern Definition -> OpenAPI anytime to prevent lock in.