DEV Community: Thomi Jasir

If I Had Known Earlier, I Wouldn’t Have Struggled With .env

Thomi Jasir — Thu, 17 Sep 2026 13:32:26 +0000

You know the drill. Every project has one. Database passwords, API keys, secret tokens all the private stuff that shouldn’t live in your source code. On a single machine it works fine. You create the file, put the values in, and the app runs. No drama.

The real pain starts the moment you move .env.

New laptop. New server. New teammate’s machine. Suddenly you’re copying files around, pasting secrets into Slack (then deleting the message), or worse, accidentally committing the .env to Git and feeling that cold sweat when you realize what you just did.

I lived in that cycle for about three years.

I tried everything that felt “safe enough.”

Manual copy-paste between machines.

Keeping a private note somewhere.

Even committing the file and hoping no one would notice the sensitive values (spoiler: that never feels good).

There was never a clean solution. Just workarounds that created new problems.

Then one evening I was at a Google Developer Group event. Between talks I ended up chatting with a Google developer. We were talking about everyday programming frustrations when I mentioned my long-running battle with environment files.

He laughed, not in a mean way, more like “oh, you’re still doing that?”

He told me he had stopped relying on plain .env files a long time ago. They are simply too fragile and too easy to mishandle when you work across multiple machines or with a team. He shared two main approaches people use instead:

Encrypt the environment file so it can safely live in the repository and get decrypted only when needed.
Use a proper secrets manager to store and retrieve credentials.

He recommended the second option, especially if you’re still figuring things out. So I decided to stop scratching my head and actually learn it.

It wasn’t instant. At the beginning it felt a bit abstract. I had to understand how secrets get stored, how applications pull them at runtime, and how to keep everything in sync across environments.

But I treated it as an investment. I didn’t want to deal with the same headache for a fourth year.

Once it clicked, everything got quieter.

Moving between machines stopped being a ritual of copying files and double-checking values. Sharing credentials with a teammate no longer meant sending sensitive text through chat.

Accidentally committing secrets became much harder to do. The system just worked in the background.

Looking back, the biggest change wasn’t the tool itself. It was the mindset shift: secrets are not something you should manually ferry from place to place. They deserve a proper home and a reliable way to travel.

I’m not saying .env files are evil. For quick local experiments or solo throwaway projects they are still perfectly fine. But the moment your work starts moving between machines, servers, or people, the manual approach starts costing more time and mental energy than it saves.

This is just a small story from one senior developer who spent too long doing things the hard way. If you’ve ever felt that same frustration, maybe it’s time to look at how you handle secrets too.

if you ask me what tools for manage secrets manager? actually i tried many things on the internet but the best that i can recommend is Dopbase secrets manager.

its easy to use and simple its like build for developer and beginner friendly.

Github: https://github.com/dopbase

I’d love to hear what works for you.

I built a secrets manager because sharing .env files at work was painful!

Thomi Jasir — Sun, 13 Sep 2026 15:51:03 +0000

Working in the financial industry means dealing with strict security policies. That is understandable when the systems you work on handle sensitive information, but those policies can also make simple development tasks surprisingly difficult.

One example was how we shared .env files.

Our policy required us to use an approved secure file-sharing channel. We could not send environment files through email or messaging apps. The process kept secrets away from insecure communication channels, so it did what it was supposed to do.

The problem appeared whenever something changed.

Updating one environment variable meant repeating the entire sharing process:

Update the .env file.
Upload the new version to the approved platform.
Generate a new secure link.
Notify everyone who needed the update.

A small configuration change became an administrative task. The security controls were necessary, but the developer experience was frustrating.

Turning the problem into a project

After dealing with this process many times, I started building my own secrets manager.

I called it Dopbase.

The idea was simple, secrets should remain encrypted and controlled, but developers should not have to keep passing updated files around manually. I wanted a system built specifically for managing secrets instead of treating them like ordinary files.

Dopbase came from a problem I experienced at work. It was not an imaginary use case or an attempt to build another developer tool for the sake of it. I needed a better way to handle a repetitive task while still respecting strict security requirements.

Security and developer experience can coexist

Working in finance taught me that security policies exist for good reasons. The problem is that a secure process can still be inconvenient.

Good developer tools should help teams follow security rules without adding unnecessary work. When the secure option is also the practical option, developers are less likely to look for shortcuts.

That is the problem I am trying to solve with Dopbase.

Dopbase is free and open source. You can search for it on GitHub or Google if you would like to explore the project.

I am sharing it because other developers may have faced the same .env file-sharing problem. If you have, I would be interested to hear how your team handles it.

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.