DEV Community: Jairo Junior

Hello, do you ever think about an other way to organize your applications ? Let's think about it a little, just read my new article to see, how libraries can save your organization, and a few tokens when you work with AI

Jairo Junior — Sun, 07 Jun 2026 23:00:31 +0000

Jairo Junior

Jun 7

Library Oriented Architecture: The Most Interesting Architecture Pattern You've Probably Never Heard About

#ai #programming #backenddevelopment #architecture

Comments

6 min read

Library Oriented Architecture: The Most Interesting Architecture Pattern You've Probably Never Heard About

Jairo Junior — Sun, 07 Jun 2026 22:03:48 +0000

Hello!

I'm Jairo Jr, your favorite Dev.to writter, or something like this 😄.

Over the last few years, I've spent a lot of time studying software architecture. Like most backend engineers, I've gone through the usual journey: Layered Architecture, Clean Architecture, Hexagonal Architecture, Event-Driven Architecture, and Microservices.

While exploring different concepts, I found an architecture style that immediately caught my attention: Library Oriented Architecture (LOA).

I first discovered the term while reading an article by Krystian Kościelniak, and it completely changed how I think about domains and code organization.

The funny thing is that the idea sounds almost too simple.

And if you're a software engineer, you already know that's usually when things get dangerous 😄.

🤔 The Problem Every Growing Application Faces

Have you ever opened a codebase and asked yourself:

Where does one domain end and another begin?

At first, everything seems organized. Then the project grows, new features arrive, more business rules appear, and suddenly billing knows about users, users know about notifications, notifications know about payments, and nobody knows who owns what anymore.

The code still works, but the boundaries become blurry. And blurry boundaries usually create expensive problems.

The problem looks something like this:

As applications grow, ownership becomes harder to understand. A feature that originally belonged to one domain slowly starts leaking into others, creating dependencies that nobody planned and everyone eventually has to maintain.

🧠 Before LOA, We Need to Talk About Ontologies

To understand Library Oriented Architecture, we first need to understand a concept called Ontology.

The word ontology sounds much more complicated than it actually is.

Honestly, the first time I read the word, I thought I was accidentally reading a philosophy book instead of a software architecture article 📖.

In software terms, an ontology is simply a way to describe concepts, relationships, and business rules inside a specific domain.

Think about an e-commerce platform. You have Customers, Orders, Products, and Payments. More importantly, you have rules that connect those concepts together.

For example:

Customers create Orders
Orders contain Products
Payments settle Orders

An ontology defines that language and those relationships. In other words:

An ontology describes the language of a domain.

Visually, it looks something like this:

Once you start thinking about systems as collections of concepts and relationships, LOA begins to make a lot more sense.

📚 The Core Idea Behind LOA

The central idea of Library Oriented Architecture is surprisingly simple:

Each domain becomes a library.

That's it.

No secret framework.

No new runtime.

No AI-powered blockchain-driven microservice mesh 🚀✨😅.

Not a package.

Not a folder.

Not a module hidden inside a monolith.

A real library.

Each library contains everything related to that specific business capability:

Domain concepts
Domain rules
Domain behavior
Domain use cases

For example:

customer-library
payment-library
inventory-library
notification-library

Each one owns its knowledge.

Each one owns its rules.

Each one owns its evolution.

Instead of having a giant application where domains are mixed together, you have independent units with explicit ownership.

The domain stops being a section of the application and becomes a first-class citizen.

🏗️ The Structure

A simplified LOA application usually looks like this:

The architecture can be divided into three major parts: the Application, the Middleware, and the Domain Libraries.

Application

The application is the entry point of the system.

It contains framework integrations, dependency injection, controllers, API endpoints, and infrastructure configuration.

Its responsibility is orchestration.

The application knows how to connect things together, but it does not own domain knowledge.

Middleware

The middleware acts as a bridge between the application and the libraries.

Its responsibility is providing common services such as:

HTTP communication
Caching
Persistence abstractions
Messaging
Shared utilities

The goal is avoiding direct infrastructure coupling inside domain libraries.

Libraries

This is where the business actually lives.

Each library contains:

Business entities
Business rules
Use cases
Domain logic

Ideally, it contains no framework dependencies, no infrastructure concerns, and no knowledge about the application itself.

The library only knows its domain.

And that's powerful.

Another way to visualize it is:

💡 Why I Like This Idea

The biggest thing that attracted me to LOA is clarity.

When a domain becomes a library, ownership becomes explicit. You immediately know where business rules belong, where changes should happen, and who owns a particular piece of functionality.

After working with large codebases for years, I've noticed that many architecture problems aren't technical problems at all.

They're ownership problems.

LOA addresses that challenge directly by making domain boundaries visible and enforceable.

The architecture encourages engineers to think in terms of business capabilities instead of technical layers, which tends to produce cleaner and more maintainable systems over time.

🔍 Isn't This Just a Modular Monolith?

At first glance, it looks very similar.

And honestly, there is some overlap.

If you're thinking:

This sounds suspiciously like a modular monolith.

You're not alone.

I had exactly the same reaction 😅.

Both approaches aim to create strong boundaries and reduce coupling.

The difference is that LOA pushes modularity one step further.

Instead of thinking:

This folder belongs to the payment module.

You start thinking:

This library IS the payment domain.

That subtle difference changes how teams design software.

The domain stops being a folder inside the application and becomes an independent unit with its own lifecycle and ownership.

🤖 The Unexpected Advantage of LOA in the AI Era

One thing I realized while studying LOA is how naturally it fits the world of AI agents.

Which was unexpected. I started reading about architecture and somehow ended up thinking about context windows and token consumption 🤖.

One of the biggest challenges when building AI-powered systems is context management. The more information you provide to an agent, the more expensive, slower, and sometimes less accurate the responses become.

With LOA, domain boundaries naturally become context boundaries.

Instead of giving an agent access to the entire application, you can provide only the library related to the problem being solved.

A Payment Agent only needs payment concepts. An Inventory Agent only needs inventory concepts.

The result is lower token consumption, more focused reasoning, and agents that behave much closer to specialists than generalists.

As AI becomes part of software architecture, this may become one of the most interesting benefits of LOA.

✅ Advantages

After studying the concept, these are the biggest benefits I see.

Clear Domain Boundaries

Every domain has an explicit home. This makes ownership easier to understand and reduces the chances of business rules leaking into unrelated parts of the system.

High Reusability

Because domains are packaged as libraries, they can be reused across multiple applications without bringing the entire codebase with them.

Easier Testing

Domain logic becomes easier to isolate, making unit and integration tests simpler to write and maintain.

Framework Independence

Business rules remain independent from Spring, Express, ASP.NET, or any other framework, reducing long-term coupling.

Better Long-Term Maintainability

Clear boundaries and reduced coupling make the system easier to evolve as business requirements grow.

⚠️ Potential Drawbacks

Of course, no architecture is perfect.

LOA also introduces challenges.

More Initial Design Effort

LOA requires careful thinking about domain boundaries. Poor boundaries can create as many problems as no boundaries at all.

Package Management Complexity

As the number of domains grows, managing versions and dependencies between libraries becomes more challenging.

Not Ideal for Every Project

Smaller applications may not benefit enough from the additional structure to justify the added complexity.

Like most architectural decisions, LOA is a trade-off, not a silver bullet.

🚀 Final Thoughts

What I like most about Library Oriented Architecture isn't the libraries themselves.

It's the mindset.

LOA forces us to think about domains as first-class citizens—not folders, not modules, and not technical layers.

Domains.

Will LOA replace Hexagonal Architecture, Clean Architecture, or Modular Monoliths?

Probably not.

But it offers an interesting perspective:

What if the domain wasn't a part of the application?

What if the application was simply orchestrating a collection of domains?

And that's a question I've been thinking about ever since I discovered this architecture style.

Maybe LOA won't become the next big architecture trend.

But it definitely made me look at domains differently—and for me, that's already a win 🎯.

Hello guys, today I wanna share with you one of the best experiences that I've ever had using a linux distro, gaming is good, coding is incredible, and for the first time, the CODEX don't burned my pc running complex changes. I'm really glad if you read it

Jairo Junior — Wed, 03 Jun 2026 10:44:10 +0000

Jairo Junior

May 30

Why I drop from Fedora to BRGV-OS

#devjournal #linux #opensource #ui

Comments

3 min read

talking a little about this wonderful linux distro

Jairo Junior — Sat, 30 May 2026 05:51:59 +0000

Jairo Junior

May 30

Why I drop from Fedora to BRGV-OS

#devjournal #linux #opensource #ui

Comments

3 min read

Why I drop from Fedora to BRGV-OS

Jairo Junior — Sat, 30 May 2026 05:40:19 +0000

Hello!

I'm Jairo.

This week I found myself doing something that probably every Linux user has done at least once: looking for a new distro even though my current one was working perfectly fine 😅.

I was browsing YouTube, looking for something to distract myself and calm my anxiety a little, when I found a video talking about a Linux distribution that promised three things I care a lot about:

Gaming
Development
A beautiful desktop experience

I'm not going to lie: that last one immediately caught my attention.

The possibility of making my PC look like a MacBook without paying MacBook prices is always tempting.

And that's how I discovered BRGV OS.

Wait... Void Linux?

The first thing that surprised me wasn't BRGV OS itself.

It was its foundation.

BRGV OS is built on top of Void Linux.

And my immediate reaction was:

What is Void Linux?

I've spent most of my Linux journey around Ubuntu, Linux Mint, Fedora, Arch Linux, and CachyOS. Somehow Void Linux had completely escaped my radar.

Coming from Fedora and Debian-based systems, everything felt a little unfamiliar at first. Different package manager, different ecosystem, different philosophy.

And honestly? That's exactly what made it interesting.

Why I Decided to Try It

I have a pretty simple checklist for my daily machine.

I need something that allows me to:

Code all day
Play games at night
Customize everything
Stay fast and responsive

Fedora already does most of that extremely well. In fact, Fedora with GNOME is still one of my favorite Linux experiences ever.

So BRGV OS had a difficult mission: it needed to convince me to leave my comfort zone.

The First Impression

What immediately stood out was how polished everything felt.

Most Linux installations follow a predictable path:

Install Linux
Install your tools
Spend three hours configuring your desktop
Break something
Fix it
Finally enjoy the system

BRGV OS skips a lot of that process.

Out of the box, you already get:

Hyprland
Beautiful theming
Modern desktop layout
Gaming-focused configuration
Developer-friendly environment

It feels much closer to one of those highly customized Linux setups you see on YouTube than a fresh installation.

Performance

This is where Void Linux starts to shine.

The system feels incredibly lightweight. Applications launch quickly, memory usage stays low, and everything feels responsive.

Coming from Fedora, I wasn't expecting such a noticeable difference, but there is definitely a feeling of reduced overhead.

It feels a bit like driving a lightweight sports car instead of a luxury SUV.

Both are fast.

One just feels faster.

Gaming on BRGV OS

Linux gaming has evolved dramatically over the last few years.

Between Steam, Proton, Vulkan, and Wine, gaming on Linux is no longer an experiment. It's a real option.

BRGV OS embraces that reality.

Gaming isn't treated like an afterthought. The distribution clearly targets users who want to code during the day and play during the evening—which, honestly, describes a large percentage of software engineers.

Development Experience

As a backend engineer, my requirements are pretty simple:

Docker
IntelliJ
Git
Multiple terminals
Good performance

BRGV OS handled all of them surprisingly well.

No drama.

No weird workarounds.

No endless troubleshooting sessions.

Which is exactly what I want from my workstation.

The Pros

Things I really liked:

✅ Lightweight and fast

✅ Beautiful out of the box

✅ Highly customizable

✅ Great gaming experience

✅ Excellent for developers

✅ A great opportunity to learn something beyond Debian, Fedora, and Arch

The Cons

No distribution is perfect.

Some trade-offs I noticed:

❌ Smaller community

❌ Less documentation than Ubuntu or Fedora

❌ Fewer tutorials specifically targeting Void Linux

❌ Requires a bit more curiosity and willingness to learn

But honestly, if you're the type of person who installs Linux for fun, that's probably not a problem.

So... Is It Better Than Fedora?

No.

And yes.

Fedora is still one of the best Linux distributions I've ever used.

But BRGV OS offers something different.

It feels fresh.

It feels lightweight.

It feels highly personal.

Most importantly, it reminded me why I started using Linux in the first place.

Not because it's the easiest option.

Not because it's the most popular.

But because there's always something new to learn.

And sometimes that's exactly what we need.

Even if we started looking for it just to calm our anxiety for a few hours 😄.

This is how my linux desktop looks like right now:

You don't know concurrency, and I can prove it!!!

Jairo Junior — Wed, 29 Apr 2026 00:52:51 +0000

Jairo Junior

Apr 26

Know coroutines doesn't mean you know concurrency, read this to know how to understand it.

#kotlin #programming #rust #ai

Comments

3 min read

Know coroutines doesn't mean you know concurrency, read this to know how to understand it.

Jairo Junior — Sun, 26 Apr 2026 21:46:03 +0000

Hello, I’m Jairo 👋

The dev.to writer you love the most.

(Ok… maybe not yet 😅 but let me believe that for a second.)
First of all, thank you for taking the time to read this.

I hope you learn something new — or at least enjoy the journey.

🚀 Why I built a Thread Pool

This week I was looking for projects to improve my software engineering skills — not just frameworks or tools, but the fundamentals.

Lately, I’ve been learning Rust as my “low-level playground” language, building things closer to the system level. My goal is to understand what happens under the hood.

So I started exploring ideas like:

building a Redis-like database from scratch
understanding memory management
working with threads and concurrency

And that’s when I decided:

“Why not build my own thread pool?”

🧠 Why a Thread Pool?

When learning a new language, we usually focus on things like:

strings
collections
classes / structs

But one thing that’s often ignored:

👉 how concurrency actually works

A thread pool solves a very real problem:

❌ One thread per task → high memory usage

✅ Fixed workers → controlled concurrency

Instead of creating a new thread for every job, we:

create a limited number of workers
reuse them
keep them alive
let them consume tasks from a queue

⚙️ How I built it

The idea is simple:

main → pushes jobs → shared queue → workers → results queue

Workers:

stay alive forever
sleep when there’s no work
wake up when a new job arrives
execute the job
store the result

🧩 Core Architecture

Queue (Arc + Mutex + Condvar)

↓

Workers (threads)

↓

Result Queue

🧪 Real code example

Here’s the core of the worker loop:

loop {
    let mut process = shared_queue.get_process();
    let response = process.run();
    result_queue.push(Result::new(response, process.get_id()));
}

Workers:

continuously fetch jobs
execute them
store results

Shared Queue (the heart of everything)

pub struct Queue {
    processes: Arc<(Mutex<VecDeque<Process>>, Condvar)>,
}

Why this?

Arc → shared across threads
Mutex → safe mutation
VecDeque → efficient queue
Condvar → sleep/wake mechanism

Adding a job

pub fn add(&self, process: Process) {
    let (processes, condvar) = &*self.processes;

    processes.lock().unwrap().push_back(process);
    condvar.notify_one();
}

Getting a job (blocking wait)

pub fn get_process(&self) -> Process {
    let (lock, condvar) = &*self.processes;
    let mut processes = lock.lock().unwrap();

    while processes.is_empty() {
        processes = condvar.wait(processes).unwrap();
    }

    processes.pop_front().unwrap()
}

👉 This is where the magic happens:

if no jobs → thread sleeps
when job arrives → thread wakes up

🧠 Arc + Mutex (the big lesson)

This was the hardest part for me.

Arc

Allows multiple threads to own the same data

Mutex

Ensures only one thread mutates at a time

Together:

Arc<Mutex<VecDeque<Process>>>

This gives you:

shared ownership
safe mutation
no race conditions

Important detail

let queue_clone = queue.clone();

This does NOT clone the data.

It creates a new pointer to the same memory.

Mutex lock

let guard = mutex.lock().unwrap();

Means:

“I want exclusive access to this data”

If another thread is using it:

👉 you wait.

😴 Condvar (sleeping workers)

Without this, your workers would:

loop forever → burning CPU

With Condvar:

no job → sleep

new job → wake up

This makes your system:

efficient
responsive
production-like

💡 What I learned

At some point I realized:

I wasn’t just learning Rust…

I was rebuilding what a dispatcher does internally.

Things became much clearer:

how thread pools work
how coroutines are implemented under the hood
how shared memory works
why synchronization matters

🤖 Using AI as a teacher (not a code generator)

One important thing about this project: I didn’t use ChatGPT to generate the solution for me.

Instead, I used it as a teacher.

Whenever I got stuck, I asked things like:

“Why does this break?”
“What is the responsibility of this component?”
“Am I modeling this correctly?”

And then I implemented everything myself.

That made a huge difference.

Because instead of just copying code, I was forced to:

understand the concepts
reason about concurrency
fix my own mistakes

And honestly, that’s where the real learning happens.

📦 The project

You can check the full implementation here:

👉 https://github.com/jairo-dev-junior/thread-pool

🎯 Final thoughts

This project was one of those “click moments”.

Rust forces you to think about:

ownership
memory
concurrency
synchronization

No magic. Just control.

And yeah… I still need to implement a clean shutdown 😅

Thanks for reading until here 🙏

See you in the next article 🚀

Hy guys, I've updated my portfolio, if you want to see it, its here: https://jairo.dev.br/

Jairo Junior — Fri, 27 Mar 2026 18:02:48 +0000

jairo.dev.br

Did you know that your app just need an umbrella, let's talk about it and the impportance of the rate-limiting in your app.

Jairo Junior — Fri, 13 Mar 2026 11:29:41 +0000

Rate Limiting: How to Stop Your API From Drowning in Requests - DEV Community

Hello! I'm Jairo. Your favorite dev.to writer. Just kidding — I know I'm not. Just breaking the ice...

dev.to

Rate Limiting: How to Stop Your API From Drowning in Requests

Jairo Junior — Tue, 10 Mar 2026 18:34:04 +0000

Hello! I'm Jairo.

Your favorite dev.to writer.

Just kidding — I know I'm not. Just breaking the ice 😄

Last week I was reading an excellent book called System Design Interview by Alex Xu. If you work with backend systems and haven't read it yet, you probably should.

One concept from the book reminded me of something interesting about software engineers: we all know rate limiting exists, but very few engineers really understand when to use it, how it works internally, and which strategy to choose.

So today let's talk about one of the most important protections your API can have: rate limiting.

What Is Rate Limiting?

Let’s imagine something simple.

Your application is a person walking in the rain, and every raindrop represents an HTTP request hitting your server.

At first, everything is fine. Then the rain gets heavier. More drops. More requests. Eventually your application becomes completely soaked — CPU usage increases, your database starts struggling, and suddenly your server turns into soup.

Not ideal.

What do we do when it's raining?

We grab an umbrella.

(No, not the evil corporation from Resident Evil — a real umbrella.)

That umbrella represents a rate limiter. It doesn't stop the rain entirely; it simply controls how much rain reaches you. In the same way, a rate limiter allows some requests to pass while blocking the excess ones, protecting your system from overload.

What Happens Without Rate Limiting?

Without rate limiting, a client could send:

10 requests per second
100 requests per second
1000 requests per second

Your application will try to process every request it receives. Eventually this leads to CPU overload, database contention, cascading failures, and sometimes a full system crash.

With rate limiting in place, the server can simply respond with:

HTTP 429 - Too Many Requests

Which is basically your server saying:

"Slow down, my friend."

Common Rate Limiting Algorithms

There are several strategies used to implement rate limiting. Each one has different trade-offs depending on the system requirements.

Let's go through the most common ones.

Token Bucket

The Token Bucket algorithm is one of the most widely used rate limiting strategies.

Imagine a bucket filled with tokens. Every incoming request must take one token to be processed. If the bucket still has tokens, the request is allowed. If the bucket is empty, the request is rejected.

Tokens are added back into the bucket at a fixed rate.

Example configuration:

Bucket capacity: 10 tokens
Refill rate: 1 token per second

This allows the system to support short bursts of traffic, but once all tokens are consumed, incoming requests must wait until new tokens are added.

This algorithm is popular because it supports bursts while still controlling overall traffic.

Leaky Bucket

The Leaky Bucket algorithm works a bit differently.

Imagine a bucket with a small hole at the bottom. Requests enter the bucket like water, but water leaks out at a constant rate.

If too many requests arrive too quickly, the bucket fills up and eventually overflows, causing new requests to be rejected.

This approach forces requests to be processed at a constant and predictable rate, which helps smooth traffic spikes.

The downside is that it doesn't handle bursts as well as the token bucket strategy.

Sliding Window Log

The Sliding Window Log strategy tracks the timestamp of every request.

For example, if your limit is 5 requests per minute, the system checks all requests that happened within the last 60 seconds.

If five requests already exist in that window, the new request is rejected. If not, it is allowed.

This method is very accurate because it always considers the real time window instead of fixed intervals.

However, it requires storing many timestamps, which can become expensive at large scale.

Sliding Window Counter

The Sliding Window Counter is an optimization of the sliding window idea.

Instead of storing every timestamp, it keeps track of only two counters: requests in the current time window and requests in the previous window.

The algorithm then calculates a weighted average between those two counters to estimate the real request rate.

This method dramatically reduces memory usage while still providing good accuracy, which is why it is commonly used in large distributed systems.

Implementing Rate Limiting in Java

Now let's look at a few simple ways to implement rate limiting in Java.

These examples are simplified but illustrate the idea.

Simple In-Memory Rate Limit

import java.util.concurrent.ConcurrentHashMap;

public class SimpleRateLimiter {

    private final ConcurrentHashMap<String, Long> lastRequest = new ConcurrentHashMap<>();

    public boolean allowRequest(String clientId) {
        long now = System.currentTimeMillis();
        Long last = lastRequest.get(clientId);

        if (last == null || now - last > 1000) {
            lastRequest.put(clientId, now);
            return true;
        }

        return false;
    }
}

This example allows one request per second per client.

Token Bucket Implementation

import java.util.concurrent.atomic.AtomicInteger;

public class TokenBucket {

    private final int capacity = 10;
    private final AtomicInteger tokens = new AtomicInteger(capacity);

    public boolean allowRequest() {
        if (tokens.get() > 0) {
            tokens.decrementAndGet();
            return true;
        }
        return false;
    }

    public void refill() {
        if (tokens.get() < capacity) {
            tokens.incrementAndGet();
        }
    }
}

A scheduled task can periodically refill tokens.

Using Resilience4j (Production Approach)

In production systems, engineers often use libraries instead of building rate limiters from scratch.

One popular option is Resilience4j.

RateLimiterConfig config = RateLimiterConfig.custom()
        .limitForPeriod(5)
        .limitRefreshPeriod(Duration.ofSeconds(1))
        .timeoutDuration(Duration.ofMillis(0))
        .build();

RateLimiter rateLimiter = RateLimiter.of("apiLimiter", config);

Supplier<String> decoratedSupplier =
        RateLimiter.decorateSupplier(rateLimiter, () -> "Hello API");

Try.ofSupplier(decoratedSupplier)
        .onFailure(e -> System.out.println("Rate limit exceeded"));

This approach integrates well with Spring Boot and production APIs.

Where Rate Limiting Is Usually Applied

Rate limiting can be implemented in several layers of your architecture.

At the API Gateway, tools like NGINX, Kong, Cloudflare, or AWS API Gateway commonly enforce limits before traffic even reaches your application.

Inside the application layer, libraries like Resilience4j or Bucket4j allow developers to control request flow directly within the service.

For distributed systems, Redis is often used to share rate limit counters across multiple instances.

Final Thoughts

Rate limiting looks simple on the surface. But once your system begins handling real traffic, it quickly becomes clear how important it is.

A well-designed rate limiter protects your:

API
infrastructure
databases
users

And sometimes, the difference between a stable system and an outage is surprisingly simple.

Sometimes your API just needs…

a good umbrella ☔

Stop building a new microservice for every problem. I almost built another backend just to handle personalization logic in my workout app. Instead, I used AI as a controlled decision layer. AI doesn’t replace architecture. It becomes part of it.

Jairo Junior — Tue, 03 Mar 2026 12:14:01 +0000

Replacing a Rule Engine with AI: A Solo Developer Decision - DEV Community

Hello! I’m Jairo Jr. 👋 I hope you’re doing great. I’m a backend software engineer and I’m currently...

dev.to

Replacing a Rule Engine with AI: A Solo Developer Decision

Jairo Junior — Tue, 03 Mar 2026 12:05:40 +0000

Hello! I’m Jairo Jr. 👋
I hope you’re doing great.

I’m a backend software engineer and I’m currently building an app to generate gym workouts for beginners.
And at some point, I hit a very real problem.

I needed the app to create something personalized for each user.

And that’s where things got complicated.

The problem

I started asking myself:

Should I create another backend just for personalization?
Should I build a microservice to handle user profiles and workout rules?
Should I design a full recommendation engine with categories, difficulty levels, and decision trees?

Technically, all of that is possible.

But then reality kicked in.

This is a solo project.
I already have one backend running.
Creating another service just to manage complex workout logic would mean:

more infrastructure cost
more maintenance
more mental overhead
slower development

So I stopped and asked a different question:

Do I really need to build all this logic manually?

The “backend-first” mindset (and why it didn’t make sense)

My first idea was very classic backend thinking:

collect user data (goal, level, duration)
map everything into a workout category tree
choose exercises based on rules
define sets and repetitions programmatically
store and version all of this logic

Basically, build a recommendation engine from scratch.

For a big team? Maybe.
For a solo app? Overkill.

So instead of asking how to build it, I asked:

How can AI help me make this decision — without losing control?

The savior: LangChain + OpenAI

After evaluating complexity and cost, I chose a simpler approach:

a lightweight service that calls OpenAI’s API
structured prompts
strict schema validation
controlled domain data

Instead of building a heavy rule engine, I built an AI-powered decision layer.

And yes… I used TypeScript 😅
(I’m a Java fan, but LangChain is much more mature with TS right now.)

How the AI flow works

The architecture is simple and intentional.

PromptTemplate → ChatOpenAI → StructuredOutputParser

What this means in practice:

The prompt defines the role, business rules, and output format
OpenAI generates the response
StructuredOutputParser forces the output to match a strict Zod schema

No random text.
No broken JSON.
No guessing.

What the model actually sees

The AI receives real context, not just a generic prompt:

user profile (goal, level, duration, etc.)
an explicit catalog of allowed exercises
strict rules like:
- valid exercise IDs
- required YouTube links
- ISO date format
- difficulty and category mapping

The model doesn’t invent workouts.
It chooses from a controlled domain.

That was a key decision.

Why this was cheaper than another backend

Instead of:

building complex domain logic
maintaining rule trees
evolving workout selection algorithms

I delegated the decision-making to AI.

And here’s the interesting part:

As more workouts are generated, I reuse previous context to reduce unnecessary calls to OpenAI.

So the system improves over time:

more workouts → better context
better context → fewer calls
fewer calls → lower cost

In the end, this solution was much cheaper than building and maintaining a full recommendation backend.

What I learned about prompt structure (the hard way)

This only worked because the prompt was treated like code, not text.

What worked well

Low ambiguity output
StructuredOutputParser + format instructions keep responses clean.
Domain control
Allowed exercise catalogs prevent hallucinated IDs.
Functional safety
Constraints and realistic rules are explicit in natural language.
Higher determinism
temperature: 0 makes responses more predictable.

This isn’t “ask AI and hope”.
It’s “ask AI with constraints”.

Problems I found along the way

Not everything was perfect.

Some issues I identified:

some fields were requested in the prompt but overwritten in the backend
difficulty and category were guided, but not strictly validated as enums
the prompt was too large and mixed responsibilities

AI works best with structure — and so does code.

Improvements that made a big difference

split system and user messages using ChatPromptTemplate
validate business rules in code, not only in prompts
remove redundant fields from the prompt
strengthen exercise ID validation
version the prompt (PROMPT_VERSION=v1)

AI doesn’t replace architecture.
It becomes part of it.

Final thoughts

This article isn’t about saying “AI is magic”.

It’s about realizing something important:

Sometimes you don’t need to build a massive system to solve a complex problem.

Sometimes it’s better to:

delegate the decision layer
control the input
validate the output
optimize for cost and simplicity

AI is powerful, but only when you define the boundaries.

You design the contract.
You validate the result.
AI generates the answer.

And that’s the difference between building a product and just writing prompts.