DEV Community: Smaug#6739

How I made my Vue tree 10x faster without changing the UI

Smaug#6739 — Thu, 09 Jul 2026 13:00:17 +0000

When I started optimizing the frontend of my knowledge base, I assumed tree generation would be the bottleneck.

It wasn't. The trees themselves were fast.

The real culprit? Vue's reactive system was constantly rebuilding them.

By rethinking how data was stored and controlled, I managed to drop the initial tree computation time from 270ms to 27ms (a 10x improvement), without touching a single line of UI code. Here's the architecture that made it possible.

It all started with three tables

It all started with three database tables.

Categories
Documents
Uploads

Each represented a different type of object, each had its own API, and each had its own frontend store.

Everything looked perfectly reasonable... until I looked at the schema more closely.

Despite being different entities, they all had almost the same properties.

id
name
description
parent_id
icon
color
created_timestamp
updated_timestamp
// And more...

The only real difference was what they represented.

I realized that it would be much simpler if all these entities could be combined. This would avoid duplicating code, routes, the store, etc.

From three tables to one graph

Instead of storing categories, documents and uploads separately, I merged everything into a single nodes table.

Every object became a node with a specific type.

At first, the idea felt almost too simple.

Of course, merging several tables into one isn't free. Some columns inevitably become irrelevant for certain node types. For example, a category doesn't have any content, while a document does.

But in practice, this trade-off turned out to be much smaller than I expected. Empty columns take very little space in a relational database, and in return every node shares the same structure, the same API, and the same frontend model.

I also found that using generic field names made the model surprisingly flexible. Instead of having fields like document_content_md or document_content_html, I renamed them to more generic names such as content and content_compiled.

Different node types can then interpret those fields differently while keeping the same underlying schema. For a document, they store the Markdown source and its compiled HTML. For an uploaded image, the very same fields can store the original file URL and its optimized WebP version.

The database schema became less specialized, but the frontend became dramatically simpler because every object follows the same contract.

With this new single-table design, the backend was now sending a flat, unified stream of nodes to the frontend. It was elegant, but it shifted a massive burden onto the client: the frontend now had to organize this raw graph into readable structures.

The real problem wasn't SQL

The UI, however, didn't need one graph.

It needed many different trees.

For example:

the workspace tree
the sidebar hierarchy
search results
filtered views

Each represents the same data from a different perspective.

The obvious solution would have been to build each tree independently.

The graph solved one problem: every object now existed only once.

But the UI still had another requirement.

It wasn't enough to store the data efficiently.

It also had to expose multiple independent tree views, all backed by the same graph and all fully reactive.

That's where the real challenge began.

A graph is only half the solution

At this point I had a nice data model.

Everything was a node.

There was a single source of truth.

The backend was clean.

Unfortunately, the frontend still wasn't.

The problem wasn't building a tree.

Building a tree isn't particularly expensive.

Rebuilding it hundreds of times is.

The real problem was how often those trees were rebuilt.

If every small modification causes reactive computations across the entire application, performance quickly becomes unpredictable.

That completely changed the question I was trying to solve.

Instead of asking:

How can I build trees efficiently?

I started asking:

How can I make sure they are only rebuilt when they actually need to be?

My first implementation

Initially, every node lived inside a simple array.

const nodes: Node[] = [...];

It worked perfectly... Until the project grew.

Every lookup by ID became an O(n) operation:

Finding children
Finding parents
Updating nodes
Checking existence

Many operations slowly became O(n) or even O(n²).

The code stayed simple, but the data structure was no longer appropriate.

The obvious improvement

The next step was replacing the array with a Map.

const nodes: Map<string, Node> = new Map();

Lookups instantly became O(1).

Problem solved?

Not really.

Maps don't preserve a custom sort order, but the UI almost always required sorted nodes.

So the code constantly looked like this:

// Instead of a clean reactive flow, the code was doing this on every render:
Map -> Array -> Sort -> Render

The complexity had simply moved somewhere else.

Instead of paying for lookups, I was now paying for conversions and sorting.

Building an indexed collection

Eventually I realized I didn't actually need another container.

I needed a container that understood my access patterns.

I built a small abstraction that keeps one copy of every node while maintaining lightweight indexes alongside it.

private byParent = new Map<string, string[]>();
private byRole = new Map<number, string[]>();
private sortedArray: Node[] = [];

Notice that the indexes don't duplicate the nodes themselves. They only store IDs.

The actual objects still exist only once.

This turned out to be an important distinction because it keeps memory usage low while allowing different views of the same data.

The real optimization wasn't the indexes

Surprisingly, the biggest performance leap didn't come from faster lookups.

It came from controlling reactivity.

Vue is extremely good at updating the UI.

But if every insertion immediately triggers every dependent computation, even a good data structure becomes inefficient.

Imagine loading a workspace containing 200 nodes.

With a traditional reactive array, inserting those nodes one by one would notify every dependent computed property 200 times.

The tree generation itself isn't expensive.

Rebuilding it hundreds of times unnecessarily is.

Instead of relying solely on Vue's default reactivity, the collection exposes its own lightweight dependency system.

Internally, it tracks consumers using a single shallowRef, and only notifies them when the collection reaches a consistent state.

class IndexedCollection {
  private isBatching = false;
  private _dependents = shallowRef(null);

  private notify() {
    if (!this.isBatching) {
      triggerRef(this._dependents);
    }
  }

  startBulk() {
    this.isBatching = true;
  }
  endBulk() {
    this.isBatching = false;
    this.rebuildSortedArray();
    this.notify();
  }
}

That made it possible to introduce bulk operations.

Begin bulk update

Insert 200 nodes

Update indexes

Notify once

Recompute once

Rather than triggering hundreds of updates during initialization, every dependent tree is rebuilt only once.

The same principle applies throughout the application.

Notifications are only emitted after actual CRUD operations that modify the database state.

As a result, the frontend always stays synchronized with the backend, while avoiding unnecessary reactive work.

The difference becomes obvious during the initial workspace loading.

Looking back, the biggest optimization wasn't algorithmic.

It was architectural: A different way of thinking about reactivity.

Instead of asking "How can I make tree generation faster?", I started asking "How can I make sure it only happens when it's actually needed?"

That single shift in perspective reduced the initial tree computation time from 270 ms to 27 ms, while keeping a single source of truth for the entire application.

If you want to dive deeper into the code, this entire architecture is open-source! You can check out the full implementation inside the Alexandrie project on GitHub: https://github.com/Smaug6739/Alexandrie.

If you found this breakdown helpful, feel free to drop a ⭐️ on the repository or leave a comment below with how you handle complex reactivity bottlenecks in your apps!

Offline PWA with Nuxt: Making an existing Nuxt app work offline without rewriting it

Smaug#6739 — Wed, 08 Jul 2026 14:57:41 +0000

Adding offline support to an existing application always sounded like one of those features that would require rewriting half the codebase.

That was exactly why I kept postponing it.

I imagined I'd have to sprinkle if (online) checks everywhere, duplicate logic in components, keep separate offline states, and generally make the whole application much harder to maintain.

In the end... it turned out to be much simpler than I expected.

The key wasn't a particular library it was keeping the architecture clean.

The goal

I wanted a complete offline mode where users could continue working even without a network connection:

Browse existing data
Create, edit and delete content
Close the application
Come back later Automatically synchronize everything once they're back online

Most importantly, I didn't want my Vue components to know whether they were online or offline.

The architecture

I decided that components should never care where the data comes from.

Instead, everything goes through the stores.

The component simply calls:

await nodesStore.create(node)

Whether that operation goes to the server immediately or is stored locally for later synchronization is entirely the store's responsibility. The API never changes.

Reading data

For reads, I relied on PWA + Workbox.

Requests are intercepted transparently and served from the cache whenever appropriate. When the application starts, previously synchronized data is loaded into the store's cache.

From the store's perspective, nothing changes: it still fetches data exactly as before. If a piece of data isn't available locally, it simply can't be accessed offline.

The components don't know whether the response came from the network or from Workbox. And with this approach we don't have to manage a full cache, the biggest part is handled by workbox, we just manually store content created or updated offline.

Nothing changed in the UI.

Writing data

CRUD operations are handled a little differently.

When online, the store behaves normally.

When offline, instead of calling the API, it stores the operation inside a small local database (IndexedDB, using localForage library) and immediately updates the local state.

Component
     │
     ▼
 Store.create()
     │
Online?
 ├── Yes → API
 └── No  → Queue operation in IndexedDB

Later, when the connection comes back, the queued operations are replayed automatically in the background in the same order.

From the component's perspective, nothing changed.

The biggest benefit

The offline mode itself is nice.

But the real win is that almost none of my components had to change.

The entire application still interacts with the stores exactly the same way.

The complexity stays in one place instead of leaking into every page and every component.

Lessons learned

A few things surprised me while implementing this:

It was much simpler than I expected
I had postponed the feature for months because I thought every component would need special offline logic.
In reality, combining PWA + Workbox for reads with a small local database and adapting the stores was enough.
Keeping components completely unaware of the network state makes the application much easier to maintain.
Good architecture often saves far more time than clever code.

Offline support ended up being one of the features I feared the most, but also one of the cleanest to implement once the architecture was in place.

The complete implementation is part of Alexandrie, an open-source knowledge base built with Nuxt and Go. If you're curious about the full architecture or the implementation details, you can find the project here:

👉 https://github.com/Smaug6739/Alexandrie

Reactive Tree Management in Nuxt 4: How I Modeled Complex Hierarchies with Pinia

Smaug#6739 — Sat, 01 Nov 2025 12:17:22 +0000

When I started building Alexandrie, I just wanted a fast, offline Markdown note-taking app I could rely on daily.
But as the project grew with nested categories, shared workspaces, and access permissions it evolved into something much more: a open-source knowledge management platform powered by Nuxt 4 and Go.

This article walks through one of the toughest challenges I faced: how to model and manage hierarchical data efficiently, from the database to a reactive Pinia store.

1. Unified Data Model: “Nodes” Over Multiple Tables

Early in development, I realized that managing categories, documents, and files as separate entities was becoming painful.

Every new feature especially sharing and permissions required deeper joins and complex recursive queries.

Here’s what the early structure looked like conceptually:

Workspace
 ├── Category A
 │    ├── Document 1
 │    └── Document 2
 └── Category B
      ├── Subcategory
      │    └── Document 3

1.1 The problem with separate tables

Having multiple tables (categories, documents, resources) worked fine until I introduced access control.

At that point, even simple questions like “what can this user see in this subtree?” required multiple recursive joins.

Performance and maintainability started to suffer.

1.2 The unified “nodes” approach

The solution was to merge everything into a single table a unified model where everything is a node.

nodes (
  id BIGINT PK,
  user_id BIGINT,
  parent_id BIGINT NULL,
  role SMALLINT,  // workspace=1, category=2, document=3, resource=4
  name VARCHAR,
  content LONGTEXT NULL,
  content_compiled LONGTEXT NULL,
  order INT,
  created_at TIMESTAMP,
  updated_at TIMESTAMP
)

With this model, every element document, folder, file became a node.
This made the hierarchy recursive but uniform, enabling simple queries like:

“What can user X access in this subtree?”

Now, permission propagation and tree traversal both use a single recursive CTE or indexed path column, drastically improving maintainability and speed.

2. Scalable Permission System

Building permissions on top of the nodes table required careful thought. I adopted a hybrid approach:

A separate permissions table maps user_id, node_id, permission_level.

On access checks, the system checks:

If the user owns the target node
If a direct permission exists
If any ancestor node grants sufficient permission

This balances fine-grained control and inheritance users get access to everything under a node they’ve been granted permission for, without repeated recursive checks.

3. Backend Stack: Go + REST + Modular Design

Language & framework: Go (Gin) lightweight and performant for API endpoints.

Language: Go (Gin) for its simplicity, performance, and clean REST design.
Database: MySQL (or compatible) raw SQL for critical queries like subtree retrieval.
File storage: S3-compatible (MinIO, RustFS) abstracted via a pluggable service for self-hosted setups.

The API uses a flat structure (/nodes, /permissions, /users) simple, predictable, and easy to version.

I separated business logic from data access (DAO layer) to keep the backend maintainable and extensible.
This paid off when refactoring: new storage backends or permission engines can now be added with minimal changes.

4. Frontend Architecture: Data management

Surprisingly, the hardest part of building Alexandrie’s frontend wasn’t the UI it was the data layer.
Representing thousands of interlinked notes in a reactive, permission-aware tree required careful design.

In Alexandrie, everything is a Node.
A node can be a workspace, category, document, or resource and each can contain others.
That means infinite nesting, partial hydration, and live updates when any part of the tree changes.

The Challenge

In Alexandrie, everything is a Node.
Each node can be a workspace, category, document, or resource, and every node can contain others effectively forming a tree structure that must remain reactive, searchable, and permission-aware across the app.

The main challenges:

Nested data: Users can nest documents/categories/resources infinitely deep.
Partial hydration: Nodes are often fetched lazily or shared publicly, so the store must handle both partial and fully-hydrated nodes.
Permission inheritance: Access rights propagate through parent nodes.
Real-time reactivity: Any node update must immediately reflect across trees, search results, and UI components.
Performance: Traversing large trees shouldn’t cause noticeable slowdowns.

The Solution

I built a dedicated Pinia store (useNodesStore) combined with a TreeStructure utility that keeps all nodes in a flat Collection (essentially a reactive Map), and reconstructs the hierarchical tree on demand.

export const useNodesStore = defineStore('nodes', {
  state: () => ({
    nodes: new Collection<string, Node>(),
    allTags: [] as string[],
    isFetching: false,
  }),
  getters: {
    getById: state => (id: string) => state.nodes.get(id),
    getChilds: state => (id: string) => state.nodes.filter(c => c.parent_id === id),
    getAllChildrens: state => (id: string) => { /* recursive logic */ },
  },
  actions: {
    async fetch() { /* lazy hydration of nodes */ },
    async update(node) { /* merges partial and full states */ },
    async delete(id) { /* removes entire subtree */ }
  }
});

Then, a dedicated TreeStructure class handles building the actual trees efficiently:

export class TreeStructure {
  private itemMap = new Map<string, Item>();
  private childrenMap = new Map<string, Item[]>();

  constructor(items: Item[]) {
    for (const item of items) {
      if (!this.childrenMap.has(item.parent_id || ''))
        this.childrenMap.set(item.parent_id || '', []);
      this.childrenMap.get(item.parent_id!)!.push(item);
      this.itemMap.set(item.id, item);
    }
  }

  public generateTree(): Item[] {
    return this.items
      .filter(item => !item.parent_id)
      .map(root => this.buildTree(root, new Set()));
  }
}

This approach gives:

O(1) access to any node via itemMap
Efficient subtree generation (only rebuild what’s needed)
A clean way to filter, search, or recompute derived data (tags, permissions, etc.)
Integration with Pinia’s reactivity: the entire graph updates live when a node changes.

Lessons & Trade-offs

Here are some high-level takeaways:

Unify your data model early. Splitting multiple tables will bite you when adding features like permissions and sharing.
Favor simplicity in API contracts. Flat endpoints scale better than deeply nested resource structures.
Design for extensibility, not just immediate features. Adding plugin-like syntax blocks or alternate storage later becomes much easier.

Permissions and hierarchy are hard. Caching accessible node sets and flattening ancestors helps avoid recursive query bottlenecks.

What’s Next & How to Contribute

Alexandrie is open-source and welcomes contributors. Areas where help is most welcome:

UI/UX improvements
Implement full offline support
Add some cool new features

If you’re interested in self-hosted knowledge tools or modern note apps, feel free to star or contribute!

GitHub: https://github.com/Smaug6739/Alexandrie

I built a Markdown note-taking app for students and creators — and I’d love your feedback

Smaug#6739 — Mon, 28 Jul 2025 11:51:27 +0000

Hi👋

Over the past few years, I’ve been working on a personal side project that turned into something I now use every day: Alexandrie — a note-taking app built with students, developers, and content creators in mind.

I’m publishing this not as a product pitch, but as an open invitation to explore, test, break, and maybe even contribute to the app — especially if you're interested in performance-focused web apps, offline-first design, and clean UI/UX.

✨ What is Alexandrie?

Alexandrie is a web-based Markdown note-taking app designed to be:

✍️ Minimal and elegant — because tools should get out of your way
⚡ Lightweight and fast — built for speed, even with hundreds of documents
🌐 Offline-friendly — your notes stay available even without a connection
🛠️ Custom productivity features — snippets, keyboard shortcuts, instant formatting

It’s designed first and foremost for students (like myself when I started it), but also fits the needs of developers and creators who want a frictionless writing and organization tool.

🧠 The Philosophy Behind It
I’ve tried tools like Notion, Obsidian, and many others. While they’re great, I often found them too heavy, too slow, or visually cluttered for daily academic or technical writing. And plain Markdown editors often lack structure and comfort.

I wanted a tool that:

Is visually pleasant (especially for long writing sessions)
Respects performance and runs well even on modest devices
Works offline by default (ideal in classrooms, on trains, in bad Wi-Fi)
Handles hundreds of notes without slowing down
Supports shortcuts, snippets, and fast navigation

🧰 Tech Stack
Alexandrie is built with:

Frontend: Vue.js + Nuxt 3 (SSR, PWA-ready)
Backend: Go, REST API, simple auth system
Storage: MinIO for file/media uploads (e.g. images in notes)
Database: MySQL, with raw SQL queries separated from business logic
Offline mode: Service Workers for seamless note access

🧪 Things I’m still improving

Better search and filtering
Better UI and UX with animations etc
Full PWA installation support
User settings & themes

💡 Want to contribute ?

If you’re interested in open source, Alexandrie is a great playground for:

Vue/Nuxt 3 devs who like clean UIs and components

Go backend developers who care about simplicity and performance

People who love improving documentation or writing tutorials

UX enthusiasts with ideas on improving offline-first apps

You can also just drop feedback, file bugs, or suggest features — I read everything!

🔗 GitHub: https://github.com/Smaug6739/Alexandrie

Some app features images