DEV Community: Thomi Jasir

I Built a Production-Ready Rust Web API Starter Kit (axum-starter)

Thomi Jasir — Sat, 07 Mar 2026 01:49:46 +0000

After 2 years of learning Rust, I finally shipped my first public project.

It's a boilerplate starter kit for building Web API with Rust. The architecture is inspired by NestJS, Spring Boot, and Laravel. I took the best patterns from those and adapted them to work properly in Rust.

GitHub: https://github.com/thomijasir/axum-starter

The Stack

Layer	Technology
Web Framework	Axum 0.8
ORM	Diesel 2.3 (SQLite dev / PostgreSQL prod)
Auth	JWT + Argon2
Docs	OpenAPI / Swagger (dev only)
Logging	Tracing (structured JSON)
IDs	Snowflake (distributed-safe)

Architecture pattern: Controller → Service → Repository. Strict unidirectional. Nothing leaks between layers.

Get Running in 30 Seconds

git clone https://github.com/thomijasir/axum-starter
cd axum-starter
./run.sh dev

Server starts at http://localhost:3099. Swagger UI at http://localhost:3099/spec.

Note: run.sh is the task runner. It auto-loads the correct .env file per environment so you don't set variables manually.

Sample Endpoints Already Wired Up

POST /auth/register
POST /auth/login
POST /auth/refresh
GET  /user/profile
POST /attachment   (file upload with MIME validation)
GET  /spec         (Swagger UI, dev only)

These are sample endpoints. Remove what you don't need, add what you do.

Why I Built This

When I started learning Rust for web API development, there was no solid reference I could follow. Most tutorials stop at "hello world." Nobody shows you how to structure a real project with auth, file uploads, migrations, and proper layering all working together.

So I built the reference I wish I had.

This project is not perfect. I'm sharing it because I need feedback from real developers. If you spot something wrong or something that could be better, please open an issue or PR. I'll be happy to review it.

Full Article

The full breakdown with architecture deep dive, project structure explanation, environment setup, and documentation guide is on my website.

Read the full article here

If this is useful, a on GitHub would help a lot. Once it hits 100 stars I'll submit it to Awesome Rust.

Nobody Taught You the Function Philosophy. Let Me Fix That.

Thomi Jasir — Thu, 05 Mar 2026 15:15:29 +0000

I've been writing code for a long time, and the one thing that still separates great developers from average ones isn't the language they use. It's how they think about functions.

Most tutorials give you steps. Nobody talks about the why.
Here is the short version of what I know.

A function is a mini machine with one job. You feed it input, it runs its hidden process, and hands you back a result. That's it. If your function is doing three jobs, you don't have a function. You have chaos with a name.

The argument rule nobody follows: Zero arguments is the ideal. One is clear. Two is acceptable. Three or more? Just trash your function and rethink the design. When arguments pile up, they are telling you something: they want to become a struct or an object.

// Stop doing this
fn create_user(name: &str, email: &str, age: u32, country: &str) -> User { ... }

// Start doing this
fn create_user(params: NewUserParams) -> User { ... }

Single responsibility is not single line. I hear developers repeat this principle like a magic spell and get it completely wrong. One responsibility means one job, not one line of code.

A make_juice function that washes, cuts, and squeezes is still one function. Its job is to make juice. That's fine.

And know when to actually define a function. Not everywhere. Only when you have repetitive code, complex logic that needs a name, or a business concept that deserves to be documented as its own unit.
That's the whole philosophy.

You don't need 10 rules. You need to understand the idea behind the function, and the rules follow naturally.

Check any other sample on how i define function on my original story How to Write a Clean Function

Thats all from my side, hope you enjoy my simple tips and ill bring more tips later Thanks

Stop Shipping Bugs: How Bun + Hono Gave Me Rust-Level Confidence

Thomi Jasir — Tue, 03 Feb 2026 15:11:12 +0000

It’s been a long time since I last wrote an article like this. Since I’m working in a bank as a software engineer, being in a bank environment often makes me feel bored and sometimes, it feels like my skills are slowly becoming outdated.

I have expertise in Rust, and I have used Rust for over 2 years on my personal projects. Working with Rust was a great experience. I never felt this level of discipline in code before, because previously I used JavaScript.

As we know, JavaScript is easy and lives everywhere. One thing that I don’t like about JavaScript is that you can do one thing in many ways. It’s like the paradox of choice, when you have too many options, you get confused.

That’s why I started looking for another programming option, from JavaScript to TypeScript, and from TypeScript to Rust.

The result was amazing. In Rust, everything must be type-safe and super strict. The tooling in Rust for development is very good.

But being too strict makes development slow, because you need to define everything properly.

For critical applications like finance, it’s okay, but what about when we want to develop simple applications like chat apps or simple CRUD systems? I think it’s too much.

Then I started to think, why don’t we combine the strictness rules from Rust but apply them in TypeScript? That way, we can get better code discipline and better code quality, while still being flexible. This idea came to my mind for one week and never left my head.

After some research, I found a solution by combining Bun + Hono + the Rust Configuration Pattern (from my past experience).

Bun is a runtime environment like Node.js, but written in Zig. It has head-to-head performance comparable to Rust and C. For those of you who don’t know, Bun is like a JavaScript/TypeScript runtime that translates your JS code into a native binary.

After development, I built a backend service with predefined rules and strictness like Rust, but flexible like JavaScript. You can find it on my GitHub https://github.com/thomijasir/hono-starter.

Specification Project

Bun as main environment
Hono API Framework
Typescript as main language
Zod for validation in runtime
Barrel Pattern Implementation

Project Structure

src/
├── middlewares/        # Hono middlewares (e.g., auth, logger)
├── modules/            # Feature modules (Domain Driven Design)
│   ├── users/          # Example module: Users
│   │   ├── controller.ts # Request handlers
│   │   ├── service.ts    # Business logic
│   │   ├── model.ts      # Data models/types
│   │   └── index.ts      # Routes definition
│   └── index.ts        # Exports all module routes
├── public/             # Static files (JSON mocks, assets) served by catch-all route
├── utils/              # Shared utilities (helpers, response formats)
├── index.ts            # Entry point
├── routes.ts           # Main application router
├── state.ts            # App state initialization (Config, DB)
└── types.ts            # Global type definition

Conclusion

This Hono starter pack is a work in progress, and I am committed to its continuous improvement. If you have suggestions, please feel free to open an issue. If you would like to contribute to the codebase, your input is highly welcome.

I created this project because I enjoy streamlining workflows and helping fellow developers elevate their code quality. I hope this tool enables you to build high performance, high quality applications with minimal friction.