Would you use an API Builder?
The problem:
I've been writing a lot of API specs lately using the OpenAPI spec and GraphQL SDL. The tools for creating these specs have come a long way since I first tried using them and it was a really enjoyable experience.
Unfortunately there is a gap between designing the API and building it. Frequently developers take the API documentation and start coding from scratch. Developing the API becomes slow and it's error prone with deviations between the spec and the implementation.
Code generators can build API's from the spec but tend to be very limited. A simple CRUD backend for example. Once you start customizing the generated code it becomes impossible to generate updated code.
The solution:
I'm interested in bridging the divide between writing the spec and building the API. What I have in mind is something that allows developers to seamlessly switch between designing the API as a spec and writing code to implement the API.
What will set this apart from other tools is the focus on the developer experience. Instead of being a one directional code generator it will aim to assist the developer allowing them to switch between "code" and "design" modes.
What has your experience building API's been like?
Would something like this help you and provide enough value that you would pay for it?
Hey Rich,
I'm a product manager for APIs at a fintech and I agree wholeheartedly with this problem. Unlike UI design and development, it's hard to render designs of APIs at low fidelity and high fidelity using the available tools. OpenAPI et. al. are more for "finished" APIs than those still in the design stage. So people tend to use docs, wikis or other unstructured formats for communicating requirements at a high level. But because these formats are unstructured there's no tooling support.
If you go the OpenAPI route, it kind of solidifies the design at a point when you might not want it to be solidified. So as you say it becomes hard to switch between code and design mode.
I'm building Criteria.sh to approach this problem from the very specific angle of writing API test suites from product requirements. If you can define API requirements in a declarative manner (as opposed to prose or imperative code), then that unlocks a whole bunch of possibilities and an ecosystem of tooling. You can transform the data, export it, sync it, etc.
I think what you are looking for is something to help build the API itself, not just test it. There is definitely a large opportunity here my opinion.
I hadn't considered all of the conversations that take place before and during the API design. That's a really interesting point. Thanks.
https://supabase.io/ solved most it for me.
Also using Fastify which is pretty good and comes with docs for all endpoints etc which is amazing.
While I love backend as a service for some things I find they can become very limiting. With this idea I wasn't thinking about building one of those. The feedback has helped me think more about my audience and it's probably more corporate API developers who need more than a layer on top of a database.
Supabase core is https://postgrest.org/en/v8.0/
Can literally plug it into a postgres DB and get endpoints.
"I find they can become very limiting."
I would follow Supabase more. I don't usually hype tech but it a game changer.
This is exactly my point. Your API backend is Postgres. What happens when you need API's that require complex business logic or need to interact with third party/microservice API's? That's where I find these tools becoming limiting.
They're about to solve that with functions.
Most of my endpoints are basic CRUD so automating that helps a lot.
There are tons of existing projects in this vein -- you pointed out code generators, but there are also some data-first approaches. Two off the top of my head are Postgraphile (generate an entire GraphQL server from a PostgreSQL instance) and Hasura (similar, can connect to more data sources, OSS with a managed solution). There are also the reverse, projects like Gin Fizz (for golang) that generate the server spec from the running server. So you'd need to figure out a way to differentiate yourself from all the free ways that this is done. I'm 100% sure that there are more approaches, and that reusing these approaches could work, but you'd need to really figure out your approach, and figure out a business plan in an area where so many people give away services for free.
Building a solution that ties the API to the database is something I absolutely want to avoid. In my experience using these tools tend to result in API's that match your data model and changing the data model later becomes difficult.
I also want to be able to build API's that do more than just map data to/from the database.
The feedback here has been gold. It's given me a lot to think about in terms of who my target audience is/isn't and alternative ways to look at the product.