menu

No Code in the Database... Right?

posted 2 min read

"No code in the database" is a mantra instilled in developers from computer science school onward. It's a fundamental principle of traditional database design aimed at separation of concerns and maintainability.

But what if your database IS your code? What if the data store not only saves your state but actively manages your business logic, acts as your API, and functions as your message bus?

The Traditional Problem: Framework Ownership

When you start a project using a traditional SQL database, frameworks like Django, Laravel, or Rails become the central authority.

These frameworks effectively "own" the database. They manage the schema through migrations and use an Object-Relational Mapping (ORM) layer to perform queries. This is why mixing major frameworks that touch the same core data is heavily discouraged—each framework wants to be the single source of truth for the database schema and application logic.

The ThingsDB Shift: The Database as the Hub

With a database like ThingsDB, the model fundamentally changes. Here, the database is your runtime environment, blurring the line between data storage and application logic.

This architecture is especially powerful if your project involves:

  • Polyglot Microservices: Using many different components or services, possibly written in different programming languages.
  • Decentralized Access: Needing all components to access the same, unified data source and logic hub.

ThingsDB steps into the role of the Data API and Message Bus, centralizing data management and coordination.

Guaranteeing Data State and Event-Driven Architecture

This integrated approach offers powerful mechanisms to guarantee data integrity and build truly reactive applications:

  1. Strict Data Integrity with Typed Collections and Procedures: By defining procedures with strict input restrictions and leveraging fully typed collections, you guarantee the validity and consistent state of your data. The data cannot be modified in an inconsistent way because the logic lives right alongside it.
  2. No More Polling with Rooms and Events: ThingsDB removes the need for wasteful polling across your services. Instead, you build truly event-driven applications using Rooms and Events. When data changes, all subscribing components are immediately notified, allowing your application to react instantly.

In short, while frameworks like Django and Laravel are perfect for applications where they serve as the central brain, ThingsDB enables a modern, event-driven architecture where the database is a powerful, active participant in your business logic, simplifying communication and guaranteeing data consistency across diverse application components. Choose the tool that best aligns with your project's long-term complexity and inter-service communication needs.

1 Comment

•

Interesting take on letting the database run the show instead of the framework. Nice point about how event driven behavior feels way cleaner than constant polling. Makes me wonder in what ways this approach could simplify messy microservice setups.

1 vote
•

It is useful if you have many micro-services or want to use event driven data flow. For example, at InfraSonar we have a simple procedure which set's the theme for a user (this procedure accepts a user_id and the theme). If this procedure is executed, the new theme is automatically stored and all browsers instantly change theme as the change is pushed as an event to the listeners. (of course, the user listens to his/her own channel). Using ThingsDB this is implemented with just a few lines of code, no extra message hub, database or anything else is required. This is the code:

new_procedure('set_user_theme', |user_id, theme| {
    user = User(user_id);
    user.theme = theme;
    .event_root_app.emit('set-theme', user.wrap('_User'));
});

In this code, User is the type, and _User is a type where we defined the schema which we return with an event.

0
•

@[Peter Jones] I've created a new blog entry featuring a small, practical example that illustrates how to establish a collection under complete API control. This post details the necessary steps for securing the ThingsDB collection by using a typed collection and funneling all external writes through validated procedures. See: https://coderlegion.com/8421/schema-first-approach-with-thingsdb

0

More Posts

TypeScript Complexity Has Finally Reached the Point of Total Absurdity

Karol Modelskiverified - Apr 23

Your Tech Stack Isn’t Your Ceiling. Your Story Is

Karol Modelskiverified - Apr 9

I’m a Senior Dev and I’ve Forgotten How to Think Without a Prompt

Karol Modelskiverified - Mar 19

The Hidden Program Behind Every SQL Statement

lovestaco - Apr 11

Tuesday Coding Tip 02 - Template with type-specific API

Jakub Neruda - Mar 10
chevron_left

More From joente

Distributed Locking in Python

Optimizing ThingsDB: Speeding up with Type Indexes

Understanding the core mechanics of ThingsDB

Related Jobs

View all jobs →

Commenters (This Week)

1 comment
1 comment

Contribute meaningful comments to climb the leaderboard and earn badges!