I will make a bold claim: there is no reason to build CRUD APIs anymore. You know the kind. API endpoints that just ferry JSON objects into a database to make them queryable by something like /ice-creams/{id}.
Perhaps it's a SQL database. Maybe it's MongoDB. It doesn't matter. Unless you are transforming the incoming request payload, and sometimes not even then, there are few reasons to handwrite API endpoints in 2024.
Honestly, there weren't many reasons to do it in 2017 either.
A few years ago, I was in an interview for a senior back-end software engineering role. The interviewer asked how I would build the back-end for a real-time collaborative word processing app like Google Docs.
"Well, I would start with a reactive database–" I began.
"Well, let's assume we don't have one of those," she said, steering the interview down a different path.
Eventually, we did talk our way through an architecture that satisfied her and I did end up landing the job. Yet I never forgot this experience because it describes a common approach to developing backend systems then and now.
Current State
You've been in meetings that center on building this way. Maybe it's a sprint planning meeting or a call between technical and non-technical business stakeholders. It goes something like this:
"Well, first we need to create a new table in the database."
"Then we'll need to create an endpoint."
"Then we'll need to wire the two together."
"Given what we've got in our backlog already, maybe we can get to this in two or maybe three sprints."
God help you if the endpoint in question has any non-trivial business logic in it.
You'll watch helplessly as the runtime of your meeting grows, threatening to crash into...your next meeting.
If you and your team are changing an existing endpoint, the drama above still unfolds unchanged.
There are good reasons that there's often no escape from this timeless way of building. When reactive databases didn't exist, the three-tier architecture—that is, separating a backend into an API interface, a logic layer, and a persistence layer—made a lot of sense. It allows you to separate the concerns of your application while also providing flexibility for each component in the architecture.
This is a good thing.
But as database solutions matured they also became more convenient. We saw a decrease in the cost of change, which makes re-examining these solutions worthwhile.
Future State
Instead of using a traditional three-tiered architecture, you might use SupaBase or its lightweight cousin PocketBase, both of which provide a REST-like API interface for all your tables and collections out of the box.
If you need to perform business logic on incoming requests, maybe you subscribe to changes on a specific table in PocketBase or SupaBase and transform requests within that subscription, then commit the result of the transformation to the same table or an entirely new one.
If you worry about vendor lock-in, maybe you use a vanilla Postgres database and layer PostgREST on top of it to provide a rich REST-like API interface for all of your SQL tables.
Are there challenges with this architectural approach? Most certainly.
You may be uncomfortable with how this architecture gently pushes you toward an asynchronous message flow rather than request-reply, which is far more straightforward. This can be a paradigm shift that many teams are unprepared for. They may also lack the institutional support from leadership to take even calculated risks with this approach.
Having pieces of business logic spread among many subscriptions and publishers can create code management, organization, and debugging challenges.
Your DevOps or SecOps stakeholders may resist the idea of the database being directly exposed to the public internet this way. While Postgres' Row-Level Security features offer fine-grained control over visibility and access to the database rows and tables, there may be other compelling reasons why this architecture is unsuitable for your organization. It may require a complete reimagining of existing infrastructure components.
Despite these caveats, exploring today's current spate of reactive databases complete with REST APIs out of the box is a business imperative in any organization requiring agility in the face of constant change.
Helpful hint: That's every single organization.
Help Is On the Way
Below, I outline four database solutions that either allow you to transform an existing SQL database into an API or provide a database and an API custom fit for your tables or document collections. Take a look.
is a lightweight, open-source backend solution that combines a real-time database with file storage and authentication services. Its key benefits include simplicity and portability, as it can be run locally or in the cloud without much overhead. Designed to be user-friendly for both small projects and rapid prototyping, Pocketbase makes it easy for developers to quickly deploy applications with built-in user authentication and admin UI for managing data.
is an open-source REST API generator that can automatically create APIs for any database, including SQL, NoSQL or other services. Its benefits include support for multiple databases and third-party integrations, automatic API documentation and flexible API customization options. DreamFactory simplifies the process of creating secure, scalable APIs without requiring manual coding, while supporting authentication, role-based access control and real-time data streaming for diverse backend infrastructures.
I hope you’ll explore some of the solutions outlined above in your next prototypes to see if you’re finally ready to stop building APIs like it’s 1999.
SOCIAL SHARE CARD GENERATOR