Building a File-Based Mock Server in Rust: A Learning Journey

Luís Fernando Vendrame — Thu, 24 Jul 2025 23:32:55 +0000

Every developer has a folder of "side projects." Some are ambitious, world-changing ideas, while others are born from a simple, immediate need. My latest project, rs-mock-server, falls firmly into the second category. I needed a simple mock server for another project, one that didn't require complex configuration files or a steep learning curve. I also wanted to sharpen my Rust skills. Why not kill two birds with one stone?

This journey turned out to be more than just building a tool; it was a deep dive into the heart of Rust's most powerful (and sometimes feared) features.

The Problem: Simple Mocks, No Fuss

For front-end development or testing microservices, you often need a fake API that returns predictable data. I wanted a server that worked directly from the file system. If I need a /users/1 endpoint, I should just have to create a /users/1 file. The folder structure itself should be the API contract.

This idea became the core concept for rs-mock-server: a zero-configuration mock server that maps directories and files directly to API routes.

The Learning Curve: More Than Just a Project

Building this server was the perfect excuse to get my hands dirty and truly grapple with Rust's core concepts. I'll be the first to admit it's a first version with plenty of "horrible" code, but that's a natural part of the learning process! The initial goal was to make it work; now, the journey of improving and refactoring it begins.

🤝 Befriending the Borrow Checker

Ah, the infamous Borrow Checker. Like many, my initial experience with it felt like wrestling with a stubborn compiler. But this project forced me to move beyond just making the errors disappear. I started to think in terms of ownership, lifetimes, and borrowing. Instead of passing values around and hoping for the best, I began to design how data flowed through the application. It was a mindset shift from "fighting the compiler" to "working with the language," and it was gratifying.

🌐 Web Services with Axum

On top of Tokio, I used Axum, a modern and ergonomic web framework. Axum’s extractor pattern is brilliant. It makes pulling data from requests—whether it's a path parameter, a query, or a header—spotless and boilerplate-free. Building the routing logic, which dynamically maps file paths like get{id}.json to routes like /api/users/:id, was a fascinating challenge that Axum made manageable.

The Result: `rs-mock-server`

After navigating these challenges, rs-mock-server was born. It's a lightweight, fast, and incredibly simple tool that does exactly what I set out to create.

A folder at ./mocks/api/users becomes the /api/users route.
A file named get.json inside it responds to GET /api/users.
A file named get{id}.json handles dynamic requests like GET /api/users/123.

It was the perfect project—small enough to finish, but complex enough to teach me valuable lessons.

From Private Tool to Public Crate

Beyond the code itself, a huge desire of mine was to learn the full lifecycle of a public project. It's one thing to build a tool for yourself, but it's another to package and publish it so everyone can use it easily.

Figuring out how to document the project, configure the Cargo.toml metadata, and publish it to crates.io was the final, crucial step. Seeing my project available to anyone with a simple cargo install command was an incredibly rewarding conclusion to this learning journey.

Try It Out!

This journey was a powerful reminder that the best way to learn is by building. I not only solved a practical problem but also came away with a much deeper understanding of the Rust ecosystem.

If you have a similar need or are just curious, I’d love for you to check it out.

Install the crate from crates.io: https://crates.io/crates/rs-mock-server
Explore the code on GitHub: https://github.com/lvendrame/rs-mock-server

Of course, I'm not so good with words, so I used some LLM to improve this text, but it kept the soul.

How to compare the intersection of two intervals

Luís Fernando Vendrame — Wed, 28 Feb 2024 12:50:16 +0000

One of the problems I have often faced is comparing two intervals, whether they are dates or points in space, which, by the way, is what we refer to as a collision in games.

When we stop to analyze the problem at first, it may seem complex, as the natural approach would be to perform 8 comparisons to ensure that a collision occurs.

Let's look at the example below for a better understanding: Suppose meeting A starts at 13:30 and ends at 15:30. Another meeting, B, is being scheduled from 15:00 to 16:00. How do we computationally verify that they do not intersect with each other? In the illustration below, we have all possible intersections that we should check:

A1 = Start of A, A2 = End of A, B1 = Start of B, B2 = End of B
        A1            A2
        |             |
    B1-----B2         |                B1 <= A1 && B2 >= A1
        |             |
    B1-------------------B2            B1 <= A1 && B2 >= A2
        |             |
        |         B1-----B2            B1 <= A2 && B2 >= A2
        |             |
        |  B1-----B2  |                B1 >= A1 && B2 <= A2
        |             |
        |             |

Given the conditions above, our algorithm would look something like this:

const a1 = new Date(2024, 02, 28, 13, 30);
const a2 = new Date(2024, 02, 28, 15, 30);
const b1 = new Date(2024, 02, 28, 15, 00);
const b2 = new Date(2024, 02, 28, 16, 00);

function verifyIntersection(a1, a2, b1, b2) {
    if(b1 <= a1 && b2 >= a1)
        return true;
    if(b1 <= a1 && b2 >= a2)
        return true;
    if(b1 <= a2 && b2 >= a2)
        return true;
    if(b1 >= a1 && b2 <= a2)
        return true;

    return false;
}

const doesIntersectionExist = verifyIntersection(a1, a2, b1, b2);
// true

However, instead of analyzing cases where there is an intersection, we can analyze cases where there is no intersection:

A1 = Start of A, A2 = End of A, B1 = Start of B, B2 = End of B
        A1            A2
        |             |
B1---B2 |             |                B2 < A1
        |             |
        |             | B1---B2        B1 > A2
        |             |

With this new analysis, we can rewrite the algorithm as follows:

const a1 = new Date(2024, 02, 28, 13, 30);
const a2 = new Date(2024, 02, 28, 15, 30);
const b1 = new Date(2024, 02, 28, 15, 00);
const b2 = new Date(2024, 02, 28, 16, 00);

function verifyIntersection(a1, a2, b1, b2) {
    if(b2 < a1)
        return false;
    if(b1 > a2)
        return false;

    return true;
}

const doesIntersectionExist = verifyIntersection(a1, a2, b1, b2);
// true

Notice that with this new perspective on the problem, we've reduced from 8 comparisons to just 2. Also, note that now the return of false for comparisons will occur earlier, unlike the previous algorithm that returned true. Another important point is that each period should be ordered from the lowest to the highest value at the time of comparison.

Although in most applications, this case just simplifies the problem, as this comparison does not occur all the time, in the case of games, it is a significant performance gain, as these comparisons occur in large numbers at each iteration of the main loop, comparing the intervals of objects on the X, Y axes, and in the case of 3D, the Z axis.

Therefore, when faced with such problems, try drawing a diagram with possibilities for both truth and falsehood and see what is most worthwhile to be used in algorithm construction.

DEV Community: Luís Fernando Vendrame