DEV Community: Luka Jioshvili

How I Build Vue 3 Applications (Part 4): Where API Logic Belongs

Luka Jioshvili — Sat, 18 Jul 2026 11:47:09 +0000

After deciding where components and composables belong, the next question naturally becomes:

Where should API communication live?

This is one of those decisions that seems unimportant when a project is small.

Fetching data directly inside a component works.

Putting API requests inside composables, stores, or utility files works too.

The problem isn't whether those approaches work.

The problem is consistency.

As an application grows, API requests slowly become scattered throughout the codebase. Some live in components, others in composables, stores, or helper functions. Eventually, finding where a request actually happens becomes harder than writing it.

Over the years, I've settled on one simple principle:

Services own external communication.

Everything else builds on top of that.

In this article, I'll explain why I keep API logic inside services, what I believe belongs there, and how that separation keeps large Vue applications easier to understand, test, and maintain.

Why do API requests become scattered?

Just like components/ and composables/, API communication rarely becomes messy overnight.

It usually starts with a single request inside a component.

Eventually another component needs the same data.

The request gets copied.

Later a composable needs it.

Then a store.

Before long, the same responsibility exists in multiple places.

The problem is that communication no longer has a clear owner.

One endpoint is called from a component.

Another lives inside a composable.

A third is buried inside a store.

Maybe there's even a helper somewhere making requests too.

Finding where a request happens becomes harder than writing it.

Changing an endpoint, updating authentication, or debugging an issue now means searching through the project instead of going directly to one obvious place.

The real problem

This isn't an HTTP problem.

It's an ownership problem.

Just like components and composables, API communication should have one clear owner.

For me, that owner is always the service.

So before I create any new request, I don't ask:

"Where can I call this API?"

Instead, I ask something much more important:

"Who owns communication with this external system?"

That single question determines almost every decision I make.

Instead of thinking about convenience, I think about responsibility.

Every API request should have one clear owner.

For me, that owner is always the service.

Once that responsibility is clear, deciding where a request belongs becomes almost automatic.

Why components shouldn't fetch

A component has one primary responsibility:

Present the UI and respond to user interactions.

Making HTTP requests is a completely different responsibility.

When a component owns both presentation and communication, those concerns become tightly coupled.

Instead of simply describing how the interface behaves, the component now also knows where the data comes from and how to retrieve it.

That might not seem like a problem when there's only one request.

But applications rarely stay that small.

Eventually, another component needs the same data.

Now you have two choices:

duplicate the request
extract it somewhere else

Instead of starting with a clear architecture, you're now refactoring because of duplication.

By keeping API communication inside a service from the beginning, every component talks to the same abstraction.

The component doesn't care whether the data comes from a REST API, GraphQL endpoint, local cache, or something else.

Its job is simply to render the result.

Here's what that separation looks like in practice:

Notice that the component doesn't know anything about endpoints, Axios, authentication, or request configuration.

It simply asks the service for the data it needs.

Why composables shouldn't fetch directly

Unlike components, composables are designed to encapsulate reusable reactive behavior.

Managing state, coordinating multiple pieces of logic, or exposing a reusable API to components are all great reasons to create one.

But making HTTP requests is still a different responsibility.

A composable shouldn't need to know how data is retrieved.

It should only know when it needs data and what to do with it.

Instead of communicating with an API directly, a composable should delegate that responsibility to a service.

The component owns the UI and decides when the data is needed.

The service owns how that data is retrieved.

Each layer stays focused on a single responsibility.

That's exactly the same principle we've followed throughout this series.

The same idea also applies to composables.

Even though they're designed to encapsulate reusable logic, I don't believe they should communicate with APIs directly either.

What belongs in a service?

For me, a service has one responsibility:

Communicate with external systems.

┌────────────────────────────┐    ┌────────────────────────────┐
│       Service Owns.        │    │        Doesn't Own.        │
├────────────────────────────┤    ├────────────────────────────┤
│ HTTP Requests              │    │ ref()                      │
│ Endpoints                  │    │ computed()                 │
│ Query Parameters           │    │ Loading  State             │
│ DTO Mapping                │    │ Dialogs                    │
│ Request Configuration      │    │ Router                     │
│ External Communication     │    │ Notifications              │
└────────────────────────────┘    └────────────────────────────┘

Nothing more.

That includes:

making HTTP requests
defining endpoints
configuring request parameters
transforming responses into application models (or delegating to mappers)
handling request-specific concerns

What doesn't belong in a service is just as important.

A service shouldn't know anything about the user interface.

That means no:

ref()
computed()
loading state
dialogs
notifications
router navigation

Those belong to the layer that's consuming the service.

Keeping that boundary clear makes services reusable from components, composables, stores, or even server-side code without bringing UI concerns along with them.

Services vs Composables

Services and composables solve different problems.

A service answers:

"How do I communicate with an external system?"

A composable answers:

"How do I coordinate reusable reactive behavior?"

A composable may call one or more services.

A service should never know a composable exists.

Think of it this way:

Services communicate.
Composables coordinate.

The architecture in practice

At this point, every layer has a well-defined responsibility.

Components focus on rendering the UI.

Composables coordinate reusable reactive behavior.

Services communicate with external systems.

Each layer builds on top of the one below it without taking over its responsibility.

Instead of every layer knowing how to talk to an API, there is a single, predictable path for data to flow through the application.

That makes the architecture easier to understand, easier to test, and much easier to extend as the project grows.

Components render. Composables coordinate. Services communicate.

One composable may orchestrate multiple services.

A service, however, should never know that a composable exists.

Conclusion

Throughout this series, we've been asking the same question from different angles.

Where should this file live?
Who owns this component?
Who owns this logic?
Who owns API communication?

The answer has always been the same:

Every responsibility should have a clear owner.

When ownership is clear, architecture becomes predictable.

And when architecture is predictable, software becomes easier to build, test, and maintain.

That's the principle I try to follow in every Vue application I build.

How I Build Vue 3 Applications (Part 3): When Logic Belongs in a Composable

Luka Jioshvili — Tue, 14 Jul 2026 17:43:18 +0000

After deciding where components belong, the next question is:

Should this logic become a composable?

Vue makes extracting logic incredibly easy.

Unfortunately, that also makes it easy to extract too much.

Before long, composables/ becomes another dumping ground full of useSomething.ts files with unclear responsibilities.

Over the years, I've settled on a simple decision process that helps me avoid that.

This article isn't about using composables.

It's about knowing when to create one.

Why does `composables/` become a dumping ground?

Just like components/, the composables/ folder usually starts out clean.

A few composables solve obvious problems:

useDebounce
useMediaQuery
useClipboard

Everything feels organized.

As the project grows, though, another pattern starts to appear.

Nothing looks technically wrong.

But eventually, every piece of extracted logic becomes another useSomething.ts.

The folder grows, responsibilities become blurred, and it's no longer obvious what deserves to be a composable.

The problem isn't having a lot of composables.

It's extracting logic without a clear reason.

Many developers start with a simple idea:

"This component is getting big."

So they move code into a composable.

The component becomes shorter.

But the application doesn't necessarily become simpler.

Instead of moving responsibility, they only moved lines of code.

That's an important distinction.

A composable should exist because it owns a single, well-defined behavior, not because the component reached 300 lines.

Every composable should own one clear behavior.

If I can't describe that behavior in a single sentence, it's usually a sign that the composable is doing too much.

So before I extract any logic, I don't ask:

"Can I move this into a composable?"

Instead, I ask something much more important:

"Does this logic have its own responsibility?"

That's the question that drives almost every decision I make.

A composable shouldn't exist simply because a component is getting bigger.

It should exist because it owns one well-defined behavior.

For me, that's where the Single Responsibility Principle naturally applies.

Every composable should be focused, predictable, and easy to describe in a single sentence.

Once I can clearly explain what it owns, deciding whether it deserves its own composable becomes much easier.

That simple shift changes the question from:

"Can I extract this?"

"Should this behavior have its own home?"

What logic should stay inside the component?

Not every piece of logic deserves its own composable.

In fact, most of it doesn't.

A common mistake is assuming that every ref, computed, or watch should be extracted.

I don't see composables as a way to reduce line count.

I see them as a way to separate responsibility.

If the logic only exists to support a single piece of UI, I usually leave it where it is.

For example:

Is a dialog open?
Which tab is selected?
Which row is hovered?
Which accordion is expanded?

The component is the owner of that state.

Here's a typical example:

Those values belong to the component because the component owns that interaction.

They don't have their own responsibility.

They're simply part of how this component behaves.

When does logic deserve a composable?

If the logic shouldn't stay inside the component, I ask another question:

Does this logic have its own responsibility?

This is where I stop thinking about file size.

I start thinking about behavior.

A composable shouldn't exist because the component became bigger.

It should exist because the behavior deserves its own home.

That's the decision process I follow:

The number of lines isn't the deciding factor.

A small piece of logic may deserve a composable if it owns a clear responsibility, while a much larger block of tightly coupled UI logic may still belong inside the component.

The goal isn't to make components shorter.

It's to make responsibilities easier to understand.

Generic vs Feature Composables

Once I've decided that the behavior deserves its own composable, the next question becomes:

Who owns it?

Not every composable has the same owner.

Some are generic and reusable across the entire application.

Others exist because of one specific business feature.

Generic composables

Generic composables are business-agnostic.

They solve reusable technical problems such as:

useDebounce
useClipboard
useMediaQuery
useInterval
useWindowSize

They should be easy to move into another Vue project without changing their behavior.

Feature composables

Feature composables understand one business domain.

Examples include:

useBillingFilters
useInvoiceValidation
useProductSearch
useSessionTimer

They may depend on domain types, services, stores, or business rules because that feature owns them.

The distinction is simple:

Generic composables own reusable behavior.

Feature composables own domain-specific behavior.

Both are valid.

The important part is that their ownership is clear.

Services vs Composables

Creating a composable doesn't mean every piece of logic belongs inside it.

One convention I follow consistently is keeping network requests inside services.

A composable may coordinate reactive state such as loading, errors, or pagination, but the actual request belongs somewhere else.

For example:

┌────────────┬──────────────────────────────────────┐
│ Component  │ Render the UI                        │
├────────────┼──────────────────────────────────────┤
│ Composable │ Manage reactive behaviour            │
├────────────┼──────────────────────────────────────┤
│ Service    │ Perform API / business operations    │
└────────────┴──────────────────────────────────────┘

This keeps responsibilities clear.

Components render the UI.
Composables manage reactive behavior.
Services perform operations.

Knowing where to look for each responsibility makes the codebase much easier to navigate.

Composable or Store?

A question I often ask is:

Does this state belong to one workflow or the entire application?

If the behavior belongs to one component or one feature, a composable is usually enough.

If unrelated parts of the application need to share the same state, it probably belongs in a store.

The distinction isn't about complexity.

It's about ownership.

A composable coordinates behavior.

A store coordinates shared application state.

Conclusion

There isn't a magic number of lines that tells you when to create a composable.

What matters is responsibility.

Some logic belongs inside the component.

Some deserves its own composable.

Some belongs in a service.

Some belongs in a store.

The important part is knowing why.

The goal isn't to create more abstractions.

It's to make every piece of your application have a clear owner.

Extract responsibility, not lines of code.

That's the rule I come back to whenever I'm deciding where new logic belongs.

How I Build Vue 3 Applications (Part 2): How I Decide Where Every Component Belongs

Luka Jioshvili — Fri, 10 Jul 2026 14:31:44 +0000

One of the hardest decisions in a growing Vue application isn't writing components.

It's deciding who owns them.

Most projects don't struggle with this on day one.

They struggle six months later, when hundreds of components exist and every new file raises the same question:

Where should this component live?

Over the years, I've settled on a simple decision process that helps me answer that question consistently.

In this article, I'll walk through the questions I ask before creating any new component and explain how those answers determine where it belongs.

Why does the `components/` folder eventually become a mess?

At the beginning of a project, almost any component organization feels reasonable.

With only a handful of components, it's easy to remember where everything lives because your mental map is still small.

As the application grows, that changes.

New features introduce dialogs, cards, tables, forms, widgets, and other supporting components.

Eventually, the components/ directory becomes a long list of unrelated files.

Nothing is technically wrong.

But every new component becomes a small architectural decision.

The problem isn't the number of components.

It's what happens to your mental model.

Instead of immediately knowing where something belongs, you start relying on search. Related components become scattered, and the business context begins to disappear.

You're no longer thinking:

"I'm working on Billing."

Instead, you're jumping between dialogs, tables, widgets, and cards just to understand a single feature.

As the project grows, understanding the impact of a change becomes harder, making accidental regressions more likely.

For me, this isn't just a folder problem.

It's a cognitive problem.

As I mentioned in Part 1, I want to understand what I'm looking at before opening a file.

The same principle applies to components.

So before I create a new component, I don't ask:

"Which folder should I put this in?"

Instead, I ask:

"Who owns this component?"

Once I can answer that question, choosing where it belongs becomes almost obvious.

What makes a component a UI component?

The first question I ask whenever I create a new component is simple:

Can another feature reuse it?

If the answer is yes, it belongs in components/ui.

UI components are business-agnostic. They shouldn't know anything about billing, users, products, sessions, or any other feature.

Instead, they provide reusable building blocks that every feature can compose.

Common examples include:

Buttons
Inputs
Dialogs
Tooltips
Avatars
Checkboxes
Badges

A good rule of thumb is:

If I could copy this component into another project without changing its behavior, it's probably a UI component.

This is the decision tree I mentally follow whenever I create a component.

Once that decision is made, the folder structure becomes almost obvious.

Here's what that looks like:

Notice that the folders are organized by UI responsibility, not by business domain.

Buttons live together.

Inputs live together.

Dialogs live together.

Icons live together.

Every category answers the same question:

What kind of UI element is this?

The goal isn't to create the perfect hierarchy, it's to make new components obvious to place and existing ones easy to discover.

Feature Components

If the component isn't reusable across the application, I ask another question:

Is it owned by a single business feature?

If the answer is yes, it belongs in components/features.

Feature components represent actual product functionality.

Unlike UI components, they understand the business they're built for.

That means they're free to depend on services, stores, composables, domain models, and business rules, because that feature owns them.

These components aren't designed to be shared across unrelated parts of the application.

They're designed to solve one business problem well.

A good rule I follow is:

If another feature needs this component, I don't immediately move it to ui.

Duplicating a small component is often cheaper than introducing a premature abstraction.

Only after a component proves it's truly shared do I consider promoting it into components/ui.

Layout Components

Not every component belongs to a business feature.

Some components define the application's shell.

Business features live inside them not the other way around.

A simple rule I use is:

If removing every business feature still leaves this component useful, it's probably a layout component.

Here's what that relationship looks like:

Layout components aren't owned by Billing, Products, or Users.

They're owned by the application itself.

Transition Components

Some components exist for one reason only:

Animation.

They shouldn't contain business logic.

They shouldn't know anything about billing, users, products, or sessions.

Their only responsibility is providing reusable animations on top of Vue's <Transition> component.

For example:

FadeTransition
ExpandYTransition
ExpandXTransition

Separating them keeps animations consistent throughout the application while avoiding duplicated transition code.

More importantly, it creates one source of truth for how things move.

I don't want five slightly different fade animations scattered throughout the project.

I want one.

If I decide to tweak the animation timing, easing, or behavior, I change it once and every feature benefits.

Here's what that looks like in practice.

That's why transition components have their own home.

Their responsibility isn't business logic.

It's making the entire application feel consistent.

Conclusion

There is no single "correct" way to organize components.

Every application grows differently, every team develops its own conventions, and every architecture evolves over time.

The approach I've shared isn't about finding the perfect folder structure.

It's about reducing the number of decisions you have to make every day.

For me, that starts with a single question:

Who owns this component?

Once I can answer that, where it belongs is usually obvious.

That simple shift has made my Vue applications easier to navigate, easier to maintain, and easier to scale as they grow.

Like the hybrid folder structure from Part 1, this isn't a universal rule, it's simply the approach I've refined over the years, and it continues to evolve with every project.

How I Build Vue 3 Applications (Part 1): Why I Use a Hybrid Folder Structure

Luka Jioshvili — Mon, 06 Jul 2026 13:05:23 +0000

When a Vue project starts, almost any folder structure works. With only a handful of components and pages, it’s easy to find what you’re looking for.

The challenge begins as the application grows. More features are added, more developers join the project, and suddenly finding the right file takes longer than writing it.

Over the years, I’ve experimented with different ways of organizing Vue applications. Instead of choosing between a responsibility-first structure (components, services, stores…) and a feature-first structure (billing, users, products…), I settled on combining both.

My approach is simple: organize the project by responsibility at the root, then organize business-specific code by feature inside those responsibilities.

I call this a hybrid folder structure, and in this article I’ll explain why it has worked well for me.

The Two Common Approaches

In my experience, most Vue project structures fall into one of two categories.

Some teams organize everything by responsibility (or file type), while others organize everything by feature (or domain). Both approaches have their strengths, and both have trade-offs.

Let's look at each one.

Organizing by Responsibility

A responsibility-first structure groups files by what they do.

This is probably the most common structure you'll see in Vue projects. It's simple, familiar, and easy for new developers to navigate. If you're looking for a component, you open components/. If you need a Pinia store, you know exactly where to find it.

For small and medium-sized projects, this works extremely well.

However, as the application grows, a single feature becomes spread across multiple directories. Implementing or modifying one feature often means jumping between components/, services/, store/, types/, and composables/.

The structure is predictable, but the feature itself becomes fragmented.

💡 Trade-off

Finding a specific type of file is easy.
Working on a specific business feature becomes harder.

Organizing by Feature

A feature-first structure takes the opposite approach.

Everything related to a business feature lives together. Components, composables, services, stores, and types are colocated inside the same directory.

This makes working on a single feature very convenient because almost everything you need is in one place.

However, I personally found that this approach introduces a different challenge. Not everything in an application belongs to a single business feature. Shared UI components, layouts, transitions, global composables, application configuration, and other cross-cutting concerns still need their own place.

For the kinds of applications I build, a purely feature-based structure felt like solving one problem while creating another.

💡 Trade-off

Working on a specific feature is easy.
Organizing shared application code becomes more challenging.

After working with both approaches, I found myself naturally combining them.

I wanted the predictability of a responsibility-first structure while keeping feature-specific code grouped together.

That eventually led me to the hybrid structure I use today.

The Hybrid Structure I Use

My approach follows one simple principle:

Responsibility first. Feature second.

At the root of the project, I organize files by responsibility.

Every top-level folder answers the first question:

What kind of file is this?

For example:

components/ contains UI components.
composables/ contains reusable reactive logic.
services/ contains business operations.
store/ contains Pinia stores.
types/ contains TypeScript contracts.

However, organizing by responsibility only solves half of the problem.

It tells me what a file is, but not which feature it belongs to.

That's where the second part of my approach comes in.

Inside each responsibility, I organize code by feature or business domain.

For example, components related to billing stay together, pricing services stay together, and product composables stay together.

This keeps feature-specific code close together without sacrificing the predictability of the project's top-level structure.

The result is neither a purely responsibility-first nor a purely feature-first architecture.

Instead, it follows one simple principle:

Responsibility first. Feature second.

File Names Are Part of the Architecture

One thing I care about a lot is file naming.

I use suffixes like:

*.service.ts
*.pinia.ts
*.types.ts
*.helper.ts
*.guard.ts
*.vue

This may look like a small detail, but it improves searchability a lot.

When I search for product, I can quickly understand what each file does:

The goal is simple:

I should be able to understand what a file probably does before opening it.

Conclusion

There is no single "correct" way to organize a Vue application.

Every team, product, and codebase has different requirements.

This hybrid approach has worked well for me because it keeps the project predictable while making feature-specific code easy to find and maintain. More importantly, it gives me a simple mental model that scales as the application grows.

This is simply the approach I've refined over the years, and it continues to evolve with every project.

Building Software Beyond the Browser

Luka Jioshvili — Thu, 14 May 2026 07:53:02 +0000

For the last 3 years, most of my work lived inside the browser.

Vue.js SPA development, Nuxt applications, frontend architecture, SEO optimizations the usual frontend ecosystem.

And honestly, after some time, I started feeling limited.

Not because frontend development became bad or boring, but because I felt like I was mostly moving inside the same boundaries over and over again.

The only thing that still looked extremely interesting to me on the frontend side was probably Three.js, but I never really found a practical place where I could meaningfully use it.

At some point, I realized I wanted to build software that could do more than a browser tab allows.

I wanted:

direct operating system interaction
process management
local-first tooling
background tasks
hardware communication
system utilities
applications that continue running outside the browser lifecycle

That curiosity slowly pushed me toward Rust.

The Problem That Started Harbor Sweep

Ironically, Harbor Sweep started because of a very small and annoying workflow issue.

I was dealing with a Windows/JetBrains-related bug where ports sometimes remained occupied even after shutting down services or closing development environments.

Technically, solving it in PowerShell was easy.

But doing it repeatedly every day became annoying enough that I decided to build a small utility for myself.

At first, it was just meant to save me a few seconds.

Nothing more.

But eventually, that small utility became my Rust playground.

I kept adding features, improving workflows, experimenting with architecture, and trying ideas I normally could not explore inside traditional SPA development.

Discovering TUI Applications

Around that same period, I attended my first RustMeet in Gliwice.

That event changed my perspective a lot.

Until then, Rust still felt somewhat “distant” to me interesting, but maybe overhyped.

The meetup made me realize people were actually building real systems, tools, and infrastructure with it.

At that point, Harbor Sweep already had a GUI version.

Then Orhun Parmaksız casually suggested:
“Why not build it as a terminal UI application?”

That idea immediately clicked for me.

So I started experimenting with Ratatui.

And honestly, building terminal applications felt surprisingly refreshing.

You start thinking differently when the entire interface becomes keyboard-driven and event-based.

The focus shifts from visual browser components to:

application state
rendering loops
event handling
terminal constraints
responsiveness
workflow efficiency

It felt much closer to the operating system itself.

Desktop Software Changed My Engineering Mindset

The deeper I went into Rust and desktop development, the more I realized how different the engineering mindset becomes outside the browser.

In frontend development, many low-level details are abstracted away.

With desktop and systems-oriented software, suddenly you start thinking about:

threads
async workflows
long-running processes
local persistence
OS APIs
notifications
background schedulers
process management
direct system interaction

The browser sandbox disappears.

And with that freedom comes a completely different type of responsibility.

What surprised me most is that learning Rust itself was not the hardest part for me.

The documentation is genuinely excellent.

And modern AI tooling helps a lot when you need practical explanations instead of spending hours watching crash courses.

Async Rust is still something I continue learning, but overall, the language itself felt much more approachable than I originally expected.

What Was Actually Hard

The hardest part was not ownership or the borrow checker.

It was shipping software properly.

Packaging, installers, release pipelines, platform-specific behavior, distribution systems like Chocolatey or Snapcraft that was the part that forced me to adjust the most.

Debugging also feels very different outside frontend environments.

In browser development, the tooling is incredibly mature and immediate.

Desktop applications force you to think closer to the operating system itself, and debugging often becomes much more low-level and environment-dependent.

That transition took far more adaptation than the language syntax ever did.

Beyond the Browser

Looking back now, Harbor Sweep started as a lazy workaround for an annoying workflow problem.

But over time, it slowly changed how I think about software engineering entirely.

What originally started as:
“I want to stop manually killing processes.”

Eventually became:
“I want to build software that works closer to the machine.”

And honestly, that journey has been one of the most interesting parts of my engineering career so far.

References & Related Projects

Project List in Linkdin: https://www.linkedin.com/in/luka-jioshvili/details/projects/
Harbor Sweep GUI Version — https://github.com/LazyDoomSlayer/harboor-sweep
Harbor Sweep TUI Version — https://github.com/LazyDoomSlayer/harboor-sweep-tui
Ratatui — https://github.com/ratatui/ratatui
Tauri v2 — https://tauri.app
RustMeet Gliwice — https://www.linkedin.com/company/rustmeet
Orhun Parmaksız — https://github.com/orhun

The 80% You Don’t See: What Tracking My Work Taught Me

Luka Jioshvili — Fri, 24 Apr 2026 07:49:53 +0000

I started tracking my work recently.
Not with some system.
Not with some productivity guru method.

Just… writing things down.

Here’s what came out of it.

It wasn’t some big realization.

More like small things… stacking up.

Q: Why did you start tracking your work in the first place?

A:
I think it’s needed.

You need to appreciate your own progress even if nobody else sees it.
Also, I wanted to understand:

At this pace… where am I actually going?

Q: What did you think you were doing well before tracking?

A:
Nothing specific.

But now I think more.
I compare more.
And that makes it easier to decide what’s actually worth doing.

Q: What did tracking immediately prove wrong?

A:
That tracking is some “online coach” thing.

It’s not.

It’s just:

evaluating your own steps without judging yourself.

Just understanding why you made certain decisions.

Friction & Reality

It started to feel like a 20/80 kind of thing.

You see the 20%.

But most of the work lives in the 80%.

Ever had that feeling?

You think you worked all day…
but can’t explain what you actually did.

Q: When you say “I worked all day” what does that actually mean?

A:
Depends.

Sometimes “all day” == a few hours of real productivity.
Other times, I can go 8 hours straight on my own projects.

So yeah… “all day” doesn’t mean much by itself.

Q: How much of your time is real output?

A:
At work -> a few hours of focused, real output.
On my own stuff -> I can lock in for much longer.

Different energy.

Patterns I Didn’t Expect

Not in a dramatic way.
Just… quietly.

Q: What pattern kept repeating?

A:
I kept asking myself:

“Why am I not exploring things more?”

I do other hobbies gaming, exploring music, random stuff
but sometimes I skip the kind of work I actually enjoy
(side projects, deeper exploration).

Q: What surprised you about your behavior?

A:
I started questioning how I push myself:

“Am I pushing in the right direction… or just pushing?”

Also had this thought:

maybe I could present something at a Rust conference one day.

And these posts… might actually help with that.

Q: What did you not want to admit?

A:
That I actually have experience.

I’m not some “big” developer.
But I do have things worth sharing.

The Quiet Realization

Q: Did tracking ever “hit” you hard?

A:
Not really.

It’s more like a background process.
I don’t think about it daily.

Only when I sit down to reflect like writing this.

What Actually Got Better

Q: What did tracking help you understand?

A:
My habits.

what’s actually bad
what’s just human
what’s needed to not burn out

Not everything unproductive is “wrong”.

Some of it is just… necessary.

Q: Did anything become clearer?

A:
Yes.

I started focusing on things that actually have an effect.

Small things. Real things.

Not “big ideas influenced by media”.

I see people around me chasing huge things.
I’m building something simple but useful.

No AI hype.
Just coding and solving problems.

And honestly… that feels better.

Final Thought

Q: Tracking my work didn’t make me more productive. It made me realize…

A:
…my habits.

My progress.

And that I should actually appreciate my own effort.

Even small wins.
Even messy ones.

Because they add up.

What’s one thing you noticed about yourself?

I Don’t Blog to Teach: I Blog to Track My Own Journey

Luka Jioshvili — Tue, 07 Apr 2026 18:30:41 +0000

You see a lot of advice around blogging as a developer.

Build your personal brand.
Grow an audience.
Share knowledge.

That’s not why I started.

The real reason

I didn’t start blogging because I forget things.
Actually, I don’t.

But that’s not the point.

What I do want is a clear view of my own roadmap, what I learned, when I learned it, and how I was thinking at that moment.

Not just final solutions.

But:

the confusion
the decisions
the small realizations
the progress over time

That’s the part you lose if you don’t write things down.

The question people asked me

When I started posting, some friends asked me:

“Why are you even writing blogs? Are you trying to impress someone?”

And honestly, I get it.

From the outside, it can look like that.

But no.

I’m not trying to impress anyone.

What blogging actually is for me

For me, blogging is simple.

It’s a way to:

track my progress
document how my thinking evolves
keep a record of what I’m building and learning

It’s basically a timeline of my developer journey.

Something I can revisit later and understand:

where I was
what I struggled with
what eventually clicked

Why this matters

As developers, we move fast.

We jump between:

tools
frameworks
problems
ideas

Even if you don’t forget things, you lose context.

You forget:

why you chose a specific approach
what confused you at the time
what changed your understanding

That context is valuable.

And that’s exactly what I want to keep.

Where this will help

Right now, I’m just getting started.

But I already know this will matter when I document things like:

my homelab setup
infrastructure experiments
my shift from frontend (Vue) into Rust and systems

Because later, I won’t just care about what I did.

I’ll care about how I got there.

Finally

So no, I’m not blogging to teach.

I’m blogging to track my own journey.

To see how I evolve over time.

If someone finds it useful along the way, that’s just a bonus.

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

Luka Jioshvili — Fri, 13 Mar 2026 18:46:56 +0000

Hook

After spending several years working primarily with Vue and TypeScript, I started paying closer attention to the tools that power the developer ecosystem.

While exploring modern terminal workflows and developer tooling, I kept encountering the same language again and again: Rust.

Tools like ripgrep (used for fast searching in editors like Neovim), zoxide, exa, terminal applications like lazygit, GPU-accelerated terminals like Alacritty, and TUI frameworks such as Ratatui are all part of the growing Rust ecosystem.

Beyond terminal tools, Rust is also powering projects like the Zed editor, the Biome JavaScript toolchain, and desktop frameworks like Tauri.

Seeing Rust appear across so many modern developer tools made me curious:

What would it be like for a frontend developer to start building tools in Rust?

My Background as a Frontend Developer

My professional work is mostly in the frontend ecosystem. Over the past few years I’ve been working with Vue and TypeScript, building web applications and focusing on the user-facing side of software.

Like many frontend developers, most of my tooling and scripting traditionally lived in the Node.js ecosystem. From build tools to small automation scripts, JavaScript was usually the default choice.

But over time I started becoming more interested in developer tooling itself things like CLI utilities, terminal workflows, and small system-level tools that improve everyday development.

That curiosity is what eventually led me to start exploring Rust.

Why I Decided to Try Rust

My first real reason to try Rust came from experimenting with desktop applications using Tauri.

As someone coming from the frontend world, Tauri felt like a natural bridge. I could still use web technologies for the interface, while Rust handled the system-level parts of the application. That combination made Rust feel much more approachable than jumping straight into systems programming.

After that first step, curiosity started taking over.

I began exploring other areas where Rust is commonly used building CLI tools, experimenting with terminal user interfaces using Ratatui, and generally trying to understand how Rust applications interact more closely with the system.

Several things about Rust were appealing at the same time:

Memory safety without a garbage collector
Performance of compiled binaries
The ability to produce a single standalone executable
And honestly, the challenge of learning something very different from the JavaScript ecosystem

Rust felt like a language that encouraged thinking differently about how software is structured, especially compared to the object-oriented patterns I was used to from other languages.

What Surprised Me When Learning Rust

Starting with Rust was not as smooth as learning another JavaScript framework or library.

Coming from a background where most of my experience was with object-oriented patterns and higher-level abstractions, Rust initially felt very different. Concepts like ownership, borrowing, and strict compile-time checks were confusing at first.

The shift in thinking was probably the biggest challenge. Instead of relying on runtime behavior or flexible patterns, Rust encourages you to be explicit about how data moves through your program.

At the beginning this can feel frustrating, but something interesting happens over time: the compiler starts to feel less like an obstacle and more like a guide.

Rust’s compiler is extremely strict, but it also provides detailed feedback. Many mistakes that would normally show up as runtime bugs are caught much earlier during compilation.

That experience changes how you think about writing software.

When Rust Makes Sense (and When It Doesn't)

One thing I learned while exploring Rust is that it isn’t meant to replace every tool or language in your workflow.

For example, JavaScript and TypeScript are still excellent choices for building web applications, especially when rapid development and a large ecosystem are important. In frontend development, the productivity and flexibility of the JavaScript ecosystem are hard to beat.

Rust, however, shines in slightly different areas.

Because Rust compiles to a standalone binary and focuses heavily on performance and safety, it works extremely well for things like:

CLI tools
terminal applications
developer tooling
system-level utilities
desktop applications with frameworks like Tauri

These kinds of programs often benefit from fast startup times, efficient resource usage, and strong guarantees around memory safety.

For me, Rust didn’t replace the tools I was already using it simply opened a new category of problems that I could explore and build solutions for.

Where My Rust Journey Is Going Next

Learning Rust has changed the way I think about building software.

Even though my primary work is still focused on frontend development with Vue and TypeScript, Rust introduced me to a different layer of the software stack one that is closer to the system and focused on performance, reliability, and tooling.

Right now I’m continuing to experiment with Rust by building small tools, exploring Tauri for desktop applications, and learning more about terminal user interfaces using Ratatui.

For a frontend developer, Rust might feel unfamiliar at first, but that unfamiliarity is exactly what makes the journey interesting.

Stay Rusty 🦀

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

Luka Jioshvili — Thu, 12 Mar 2026 10:40:29 +0000

TL;DR
In this final post, I’ll show you how to take my Ubuntu WSL bootstrap and make it your own.

Whether you want to add dotfiles, set up Git identity, or install completely different tools, this structure makes it easy to fork, extend, and personalize.

Why Customization Matters

This project works for me, but you should own your environment.

My goal from the beginning was to make this:

Modular (each tool gets its own script)
Transparent (readable Bash, no black-box logic)
Easy to tweak (just edit configs or scripts)

This isn’t a framework, it’s a blueprint.

1. Add or Remove Packages

You can edit packages.conf to:

Add tools you always install (e.g. jq, htop, gh)
Remove things you don’t use (e.g. yazi, btop)

SYSTEM_UTILS_APT=(
  wget curl jq htop
)

DEV_TOOLS_SNAP=(
  nvim
)

These arrays are passed into helper functions from utils.sh, which handle install logic cleanly.

2. Add Your Own Scripts

To add new tooling (like Go, Deno, or Rust), follow this pattern:

Create a new file like go-setup.sh
Add install logic using apt, Snap, curl, or custom methods
Append it to the SCRIPTS=(...) array in run.sh

Example:

readonly SCRIPTS=(
  ...
  "go-setup.sh"
)

3. Include Dotfiles or Shell Config

Want to bootstrap your .bashrc, .tmux.conf, or .gitconfig?

You can:

Clone your dotfiles repo in a new dotfiles-setup.sh
Symlink them or append to existing configs
Set aliases, functions, or themes

This is also a good place to add default Git config, like:

git config --global user.name "Your Name"
git config --global user.email "you@example.com"

4. Handle Secrets and Git Identity

Avoid committing private tokens or configs. Instead:

Keep a local ~/.local-setup.sh script with personal logic
Add .local-setup.sh to your .gitignore
Source it at the end of run.sh (if it exists)

if [ -f "$HOME/.local-setup.sh" ]; then
  echo "Running local custom setup..."
  bash "$HOME/.local-setup.sh"
fi

5. WSL-Specific Optimizations

Some tweaks worth adding if you run WSL full time:

Create a .wslconfig on Windows for better resource limits
Add mounts or performance tweaks in /etc/wsl.conf
Disable unnecessary services that don’t apply in WSL

You can even add a WSL check to run.sh:

grep -qi microsoft /proc/version && echo "Running under WSL"

Fork It, Extend It, Own It

This whole project is meant to be cloned, forked, and hacked.
Start with mine, and make it match your exact stack and preferences.
If you build something cool from this, I’d love to see it.

Final Recap

Over the last 5 posts, you’ve seen how I:

Automated my WSL Ubuntu setup from scratch
Wrote modular Bash scripts with smart defaults
Bootstrapped a full terminal dev stack
Installed Node, Python, and Docker with zero hassle
Built a foundation that anyone can extend

Takeaway?

Automate the boring stuff, personalize the rest, and keep improving it.

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

Luka Jioshvili — Tue, 03 Mar 2026 14:00:56 +0000

TL;DR
This post covers how my WSL bootstrap sets up Node.js, Python, and Docker and the core tools I use for frontend, backend, scripting, and container work.
Each tool has its own setup script, designed to be modular, idempotent, and fast.

Why These Tools?

My day-to-day work (and open source projects) span across:

Frontend apps (Vue, Nuxt, TypeScript)
Scripts, automation, CLI tools (Python)
Testing infrastructure, running services, and debugging (Docker)

So my bootstrap includes all of them by default and no more grabbing install commands from old gists or StackOverflow every time I set up WSL.

Node.js Setup – `node-setup.sh`

I install Node.js LTS (v22) using nvm because it's the most flexible method for switching versions.

What the script does:

Installs or updates NVM
Loads it into the shell
Installs Node.js v22 and sets it as default
Installs global tools: pnpm and yarn
Disables Yarn telemetry

Why this approach?

Versioning via NVM makes switching Node versions trivial
I use pnpm for speed and monorepos, and yarn where needed

nvm install 22
npm install -g pnpm yarn

Output is printed to verify versions and check everything succeeded.

Python Setup – `python-setup.sh`

Python is everywhere and whether I’m scripting quick tools, using CLI apps, or running data scripts.

What this setup covers:

Installs Python via APT
Installs pip, venv, and upgrades setuptools, wheel, etc.
Prepares the environment for creating isolated Python workspaces

This setup is intentionally minimal and just enough to bootstrap Python for development, automation, and further customization.

Docker Setup – `docker-setup.sh`

I use Docker for containers when testing services or building isolated environments.

What the script does:

Installs Docker via APT (using official repo)
Adds the current user to the docker group (so no need for sudo)
Enables the Docker service

Why this matters:

WSL2 supports Docker with great performance
You shouldn’t have to use sudo to run docker in dev environments

Docker is optional, but including it makes the bootstrap future-proof if I need containers down the line.

One Bootstrap to Install Them All

All of these are automatically set up when I run:

./run.sh

I don’t have to worry about:

Which method to use (nvm, APT, Snap, curl?)
Forgetting steps like adding users to Docker groups
Repeating things across different machines

Future Improvements

Things I might add later:

Version pinning via .nvmrc or .tool-versions
Python virtualenv examples (or Poetry setup)
Docker Compose install

Next: Make It Yours

In run.sh Diaries #5, I’ll show you how to:

Add your own scripts
Customize package lists
Include dotfiles or Git config
Extend the bootstrap for your own stack

run.sh Diaries #3: My Terminal Stack – tmux, zoxide, and lazygit

Luka Jioshvili — Tue, 24 Feb 2026 07:45:26 +0000

TL;DR
This post walks through the terminal tools I bootstrap with my WSL setup: tmux for multitasking, zoxide for lightning-fast directory switching, and lazygit for painless Git management.
These aren’t just cool tools and they’re essentials in my terminal-first workflow.

Why a Terminal Stack?

I’ve said it before: I prefer a terminal-first workflow.

Modern IDEs? Too heavy.
GUI Git clients? Slow and mouse-driven.
I want speed, control, and tools that work over SSH, WSL, or raw Linux.

So I built my environment around powerful CLI tools that:

Launch instantly
Don’t eat memory
Let me work efficiently in any shell or session

Let’s break down the tools I install automatically via my bootstrap scripts.

tmux – Terminal Multiplexing

tmux lets me split one terminal into multiple panes and windows. I use it to:

Run multiple shells or logs side-by-side
Persist sessions even after closing the terminal
Combine editor + server + shell in one view

Why I love it:

Clean, scriptable config
Always available in headless setups
Works beautifully with neovim, fzf, and my dotfiles

TPM – Tmux Plugin Manager

My tpm-setup.sh script installs TPM (Tmux Plugin Manager) which makes installing and updating tmux plugins painless. It lives in ~/.tmux/plugins.

`zoxide `– Smarter` cd`

zoxide is a fast, smarter alternative to cd. You just type:

z GitHub
z os-bootstraps

…and it jumps to your most-used directories.

Why I use it:

Tracks recent paths automatically
Works across shells
Insanely efficient once you get used to it

lazygit – Git, But Better

lazygit is a TUI-based Git interface I use daily to:

Switch branches
Stage/commit
Resolve merge conflicts
Review logs and diffs

It’s keyboard-first, extremely fast, and integrates perfectly into a tmux workflow.

All of These Are Auto-Installed

Once I run:

./run.sh

My terminal stack: tmux, zoxide, lazygit, neovim, and more is ready to go. No more downloading, aliasing, or reconfiguring things manually.

Next: Languages and Containers

In run.sh Diaries #4, I’ll walk you through how I set up:

Node.js with NVM
Python environments
Docker with user group access

And how it all ties into real-world frontend + backend dev work.

run.sh Diaries #2: The Bash Behind the Bootstrap

Luka Jioshvili — Tue, 17 Feb 2026 07:54:15 +0000

TL;DR

In this post, I’ll walk through the internal logic of how my WSL bootstrap works and let’s focus on run.sh, utils.sh, and packages.conf. You’ll learn how I made the setup modular, safe to re-run, and easy to extend.

The Big Picture

In Part 1, I talked about why I built this and now let’s explore how it works.

At the heart of it is a simple philosophy:

Don’t repeat yourself.

Don’t install what’s already there.

Keep everything scriptable and modular.

The setup revolves around three key components:

run.sh – the orchestrator
utils.sh – helper functions
packages.conf – what to install

Let’s break each down.

1. `run.sh` – The Orchestrator

This script is the entry point of the whole bootstrap.

Responsibilities:

Define the list of setup scripts to run
Execute them one by one
Log their progress
Fail fast if something breaks

Structure:

readonly SCRIPTS=(
  "node-setup.sh"
  "rust-setup.sh"
  "docker-setup.sh"
  "lazygit-setup.sh"
  "python-setup.sh"
  "zoxide-setup.sh"
  "tmux-config-setup.sh"
  "tpm-setup.sh"
  "nvim-setup.sh"
)

Each script is passed into the run_script() function from utils.sh, which:

Checks if the file exists
Makes it executable
Runs it and logs its completion

2. `utils.sh` – The Bash Toolkit

This file contains reusable helpers that keep the logic clean and DRY.

Key Functions:

`is_installed_apt` / `is_installed_snap`

Check if a package is already installed before trying to install it.

  dpkg-query -W -f='${Status}' "$1" 2>/dev/null | grep -q "install ok installed"

`install_apt_packages` / `install_snap_packages`

Take a list of packages, filter out the ones already installed, and install only what’s needed.

Includes logic to:

Run apt-get update only if required
Handle Snap not being installed
Try both normal and -classic Snap installs

`die`

A simple exit-on-error function to fail cleanly and loudly.

die() {
  echo "ERROR: $*" >&2
  exit 1
}

In the future, I plan to add features like color-coded logging, verbosity levels, timestamps, and WSL detection. But for now, the current setup does exactly what I need: simple, readable, and effective.

3. `packages.conf` – Centralized Package List

This is where all core APT and Snap packages are defined and grouped by category for clarity.

Example:

SYSTEM_UTILS_APT=(
  wget curl fzf build-essential fd-find ripgrep
)

DEV_TOOLS_SNAP=(
  nvim
)

Each package list is passed into the installer functions in utils.sh.

This structure makes it easy to:

Add/remove tools cleanly
See what’s included at a glance
Extend with new categories later

Why This Structure Works

Modularity: each setup script does one job
Reusability: helpers prevent duplication
Clarity: it’s easy to understand what gets installed and how
Safety: checks prevent reinstalling or breaking existing tools

Want to Try It?

⚠️Security Reminder

Never run scripts from the internet — including mine — without reading and understanding them first.
Even if you trust the source, it's good practice to inspect any Bash script before executing it.

I care about security too and my WSL bootstrap project is open source, transparent, and written to be as readable and modular as possible. Fork it, inspect it, tweak it.

git clone https://github.com/LazyDoomSlayer/os-bootstraps
cd os-bootstraps/ubuntu
chmod +x run.sh
./run.sh

Install time: ~5 minutes on a VM with 8GB RAM, 8-core CPU, and 50Mbps connection.

First-time runs may take longer if your system hasn’t been updated with apt-get update && upgrade.

Everything else happens automatically. Grab a coffee. ☕

What’s Next: The CLI Stack

In Part 3, I’ll show you the terminal tools I bootstrap like tmux, zoxide, lazygit, and neovim and how they fit into my daily workflow.

Want to go full terminal-first? This next part is for you.

DEV Community: Luka Jioshvili

How I Build Vue 3 Applications (Part 4): Where API Logic Belongs

Why do API requests become scattered?

The real problem

Why components shouldn't fetch

Why composables shouldn't fetch directly

What belongs in a service?

Services vs Composables

The architecture in practice

Conclusion

How I Build Vue 3 Applications (Part 3): When Logic Belongs in a Composable

Why does composables/ become a dumping ground?

What logic should stay inside the component?

When does logic deserve a composable?

Generic vs Feature Composables

Generic composables

Feature composables

Services vs Composables

Composable or Store?

Conclusion

How I Build Vue 3 Applications (Part 2): How I Decide Where Every Component Belongs

Why does the components/ folder eventually become a mess?

What makes a component a UI component?

Feature Components

Layout Components

Transition Components

Conclusion

How I Build Vue 3 Applications (Part 1): Why I Use a Hybrid Folder Structure

The Two Common Approaches

Organizing by Responsibility

Organizing by Feature

The Hybrid Structure I Use

File Names Are Part of the Architecture

Conclusion

Building Software Beyond the Browser

The Problem That Started Harbor Sweep

Discovering TUI Applications

Desktop Software Changed My Engineering Mindset

What Was Actually Hard

Beyond the Browser

References & Related Projects

The 80% You Don’t See: What Tracking My Work Taught Me

Here’s what came out of it.

Friction & Reality

Patterns I Didn’t Expect

The Quiet Realization

Final Thought

I Don’t Blog to Teach: I Blog to Track My Own Journey

The real reason

The question people asked me

What blogging actually is for me

Why this matters

Where this will help

Finally

From Vue to Rust: Why a Frontend Developer Started Writing Systems Tools

Hook

My Background as a Frontend Developer

Why I Decided to Try Rust

What Surprised Me When Learning Rust

When Rust Makes Sense (and When It Doesn't)

Where My Rust Journey Is Going Next

run.sh Diaries #5: Make It Yours – Forking, Tweaking & Extending the Setup

Why Customization Matters

1. Add or Remove Packages

2. Add Your Own Scripts

3. Include Dotfiles or Shell Config

4. Handle Secrets and Git Identity

5. WSL-Specific Optimizations

Fork It, Extend It, Own It

Final Recap

run.sh Diaries #4: From Zero to Coding-Ready with Node, Python & Docker

Why These Tools?

Node.js Setup – node-setup.sh

What the script does:

Why this approach?

Python Setup – python-setup.sh

What this setup covers:

Docker Setup – docker-setup.sh

What the script does:

Why this matters:

Why does `composables/` become a dumping ground?

Why does the `components/` folder eventually become a mess?

Node.js Setup – `node-setup.sh`

Python Setup – `python-setup.sh`

Docker Setup – `docker-setup.sh`

`zoxide `– Smarter` cd`

1. `run.sh` – The Orchestrator

2. `utils.sh` – The Bash Toolkit

`is_installed_apt` / `is_installed_snap`

`install_apt_packages` / `install_snap_packages`

`die`

3. `packages.conf` – Centralized Package List