At Fern, we're creating the modern developer experience platform. We work with developer-focused companies to generate SDKs & API documentation. We're looking for a Founding Backend Engineer with 4+ years of experience to help us scale with our users. You'll join a small team (3 of us) and will be a product owner who designs, builds, and ships weekly.
Learn more at https://www.buildwithfern.com/careers
Apply by emailing careers [at] buildwithfern.com with your resume/LinkedIn and why this opportunity interests you
Fern (YC W23) | Founding Engineer | New York City | $130k-$160k + 0.5-1.0% equity | Full Time | Open Source | https://buildwithfern.com
REST APIs underpin the internet but are still painful to work with. They are often untyped, unstandardized, and out-of-sync across multiple sources of truth. With Fern, we aim to bring great developer experiences to REST APIs.
Our stack is Next.js + Vercel, Express (Node.js) + FastAPI (Python), Postgres DB + Prisma ORM, and AWS CDK. We're open source: https://www.github.com/fern-api/fern
We closed a Seed this year from top-tier US investors, including Y Combinator, Abhinav Asthana (Postman CEO), Arash Ferdowsi (Dropbox co-founder), and Ian McCrystal (Stripe's Head of Docs).
I too am inspired by Stripe's API documentation. Specifically, I like that it:
1. shows the API reference alongside the requests and responses
2. gives code examples of how to use the client libraries (e.g. python, node.js, go, java)
3. is one, continuously scrolling page
---
We built Fern Docs so that for $150/month you can get Stripe-like documentation. You can get started for free. Pay only when you need a custom domain (e.g. your-site.com/docs).
You're right that four companies are going after SDK and Docs generation. After seeing enterprises like AWS, Stripe, Twilio, Palantir, Dropbox, and many more build codegen for REST APIs in-house, it seems like a no-brainer that they'll be a solution that serves the millions of developers out there working with REST APIs.
We're seeing a new category getting created before our eyes! I could see it being defined as "Developer Experience Infrastructure", "API Management", or "API Operations". Time will tell.
Fern (YC W23) | Founding Engineer | New York City | $125k-$175k + equity | Full Time | Open Source | https://buildwithfern.com
REST APIs underpin the internet but are still painful to work with. They are often untyped, unstandardized, and out-of-sync across multiple sources of truth. With Fern, we aim to bring great developer experiences to REST APIs.
Our stack is Next.js + Vercel, Express (Node.js) + FastAPI (Python), Postgres DB + Prisma ORM, and AWS CDK.
We closed a Seed this year from top-tier US investors, including Y Combinator, Abhinav Asthana (Postman CEO), Arash Ferdowsi (Dropbox co-founder), and Ian McCrystal (Stripe's Head of Docs).
Yeah, there are many projects for client generation from OpenAPI, and the number keeps growing. Make sure to add your tool to https://tools.openapis.org/ !
> Why don't more companies publish either a specification for their API or an API client on a website like GitHub?
Being API-first and caring about the developer experience (DX) is still a new phenomenon. Companies like Twilio and Stripe differentiated in DX. Now there's a whole category of API-first startups like seam.co (API for IoT devices), merge.dev (unified API for 180+ integrations), and stytch.com (API for authentication) who publish API clients in major languages like Node.js, Python, Java, and Go. They also publish their OpenAPI specs in case you use a long-tail language and want to generate a client yourself.
IMO, in the next 5 years, it'll become the norm to offer clients if you have a public REST API.
I'm one of the builders of an open source project (https://buildwithfern.com/docs) to improve API codegen. We built Fern as an alternative to OpenAPI, but of course we're fully compatible with it.
We rewrote the code generators from scratch in the language that they generate code in (e.g., the python generator is written in python). We shied away from templating - it's easier but the generated code feels less human.
I think it's worth pointing out that a lot (most?) of Fern's complaints against OpenAPI are really complaints against JSON Schema. There have been talks before about allowing other schema systems in OpenAPI - I wouldn't be incredibly surprised to see such things come up for Moonwalk. JSON Schema is not not a type definition system https://modern-json-schema.com/json-schema-is-a-constraint-s....
It's also worth noting that most JSON Schema replacements I've seen that prioritize code generation are far less powerful in terms of runtime validation (I have not examined Fern's proposal in detail, so I do not know if this is true for them).
The ideal system, to me (speaking as the most prolific contributor to JSON Schema drafts-07 through 2020-12), would have clearly defined code generation and runtime validation features that did not get in each other's way. Keywords like "anyOf" and "not" are very useful for runtime validation but should be excluded from type definition / code generation semantics.
This would also help balance the needs of strongly typed languages vs dynamically typed languages. Most JSON Schema replacements-for-code-generation I've seen discard tons of functionality that is immensely useful for other JSON Schema use cases (again, I have not deeply examined Fern).
Just wanted to chime in and say we are a big fan of Fern! It makes developing our APIs 10x easier as we get full end-to-end type safety and code completion, but the really great part is we get idiomatic client and server SDKs as well as OpenAPI output that we use to autogen documentation. Our small team of two engineers are able to ship multiple client facing SDKs because we are built on Fern!
Speed of development on these guys is huge, and have enjoyed using their SDKs. Community is getting involved in building things like auto-retry with backoff and other pretty helpful features in SDKs. Big fan of these guys!
I feel like this line in the Moonwalk proposal was written for you! "Deep nesting can become unnecessarily cumbersome for reading and writing OpenAPI descriptions."
SEO is important to us and right now we’re happy with the quality score we’re seeing there