Building a 'Backend-less' Blog Site : My Journey with Coffee Chronicle

Source: Dev.to

coffeechronicle.aniruddhagawali.dev

The Idea: Why Go “Backend‑less”?

The inspiration for Coffee Chronicle was to see how much logic a modern database could handle. Traditionally, the database is a passive storage layer while the backend performs authentication, validation, and business logic. I wanted to flip that script.

Note: This architecture is an experimental learning project. It demonstrates database‑driven development but isn’t necessarily recommended for large‑scale production where dedicated backend services provide better observability and middleware flexibility.

Why PostgreSQL?

PostgreSQL was chosen not only for reliability but also for its programmable environment:

• PL/pgSQL – write complex procedural logic directly in the database.
• Native JSON support – ideal for dynamic content from rich‑text editors.
• Extension ecosystem – adds capabilities such as cryptography and specialized data types.

Connecting the Frontend Directly to the DB

In Coffee Chronicle the “backend” consists of stored procedures and functions inside PostgreSQL. The Next.js frontend calls these via Server Actions.

Instead of embedding SELECT or INSERT statements in the application code, the frontend invokes a function, e.g.:

SELECT create_blog(...);

This keeps schema logic encapsulated within the database and eliminates most glue code between API endpoints and queries.

Authentication Inside the Database

All authentication flows are handled inside PostgreSQL, without external providers:

• User registration – a stored procedure inserts credentials.
• JWT management – PostgreSQL extensions generate and verify JSON Web Tokens. On login, the DB validates credentials and returns a signed token.
• Session integrity – only valid, non‑expired tokens are accepted for data‑modifying operations.

Security Through Row‑Level Security (RLS)

Without a traditional backend, security is enforced at the row level using RLS policies:

• Public access – anyone can read published blogs.
• Private ownership – only the author can edit or delete their posts, enforced with a policy such as USING (auth.uid() = author_id).
• Isolation – users cannot access another user’s draft content, even if they know the blog ID.

Challenges and Lessons Learned

Creating a backend‑less app introduced several hurdles:

• Security and debugging – loss of conventional stack traces required disciplined SQL error handling and logging.
• JWT secret management – ensuring the secret is securely accessible to the database for signing.
• Input validation – every function must rigorously prevent SQL injection and maintain data integrity, as the DB is the final gatekeeper.

Final Thoughts

Building Coffee Chronicle showed that PostgreSQL is far more than a table store; it’s a sophisticated runtime environment. While I may revert to traditional backends for complex production systems, I now have a deeper appreciation for the power of the database. If you want to understand how data, security, and identity intertwine, try “deleting your backend” and let the database do the talking.