Damien | Dralix

01 Overview

Dralix is a kanban board for agile task management. It lets you create, edit, and delete tasks across columns, drag cards between columns, estimate story points, and switch between local storage and a database backend.

The project started as a way to force myself to learn JavaScript properly. I'd been learning Python and felt comfortable with the backend, but I hadn't built anything serious with JS. Rather than following a tutorial, I picked a real project with real features and built it until it worked.

02 Why I built it this way

01

No frameworks — vanilla JavaScript only

I deliberately avoided React or any other framework. The point was to understand how the DOM actually works — event listeners, state management, re-rendering — before abstracting any of it away. If you can build it in vanilla JS, you understand what frameworks are actually doing for you.

02

Native HTML5 Drag API instead of a library

Same reasoning — I wanted to understand what drag-and-drop actually involves at the browser level. Using the native Drag API meant working through dragstart, dragover, drop events and understanding how data transfer works between elements.

03

Dual storage modes — local and database

I built support for both localStorage and a MySQL backend so I could understand how frontend state management differs from server-side persistence. Switching between them also gave me a reason to design the frontend code in a way that wasn't tightly coupled to one storage method.

03 Story point estimator

One feature I'm particularly proud of is the story point estimator. When creating a task, you can estimate its complexity across four dimensions: complexity, uncertainty, development time, and testing effort. The estimator applies a weighted calculation across these inputs and suggests a value from the Fibonacci sequence.

The reason for Fibonacci is the same as in real agile teams — the increasing gaps between numbers reflect that estimating large tasks is inherently less precise. The goal is to remove subjective guesswork and keep estimates consistent across the board.

04 The backend API

api/routes.py

@app.route("/api/tasks", methods=["POST"])
def create_task():
    from models import Task
    data = request.get_json()
    task = Task(
        title=data.get("title", "No title"),
        status=data.get("status", "todo"),
        description=data.get("description", ""),
        storypoint=data.get("storyPoint", 1)
    )
    db.session.add(task)
    db.session.commit()
    return jsonify({"message": "Task created"}), 201

The REST API is built with Python and Flask. It exposes endpoints for full CRUD operations on tasks, with SQLAlchemy handling the ORM layer and MySQL storing the data. The API is intentionally separate from the frontend — the kanban board talks to it over HTTP and can fall back to localStorage if the API isn't running.

models.py

class Task(db.Model):
    id          = db.Column(db.Integer, primary_key=True)
    title       = db.Column(db.String(150), nullable=False)
    description = db.Column(db.Text)
    status      = db.Column(db.String(50), default="todo")
    storypoint  = db.Column(db.Integer, default=1)

The Task model defines how data is structured and stored. It enforces consistent formatting between the API and the MySQL database, acting as the core data layer for the whole application.

05 What I learned

How JavaScript event-driven programming actually works — attaching listeners, bubbling, and managing state without a framework.

How the HTML5 Drag API works under the hood and why libraries like SortableJS exist to abstract the rough edges.

How to design a REST API that cleanly separates concerns between frontend and backend.

How SQLAlchemy models map to database tables and why an ORM layer is useful for keeping data consistent.

How to think about dual storage modes — designing code that isn't tightly coupled to one data source.

06 What I'd do differently / what's next

If I were to build Dralix again, I'd probably add user accounts and real-time collaboration features. It would be interesting to implement WebSockets for live updates across clients and see how that changes the architecture. I'd also consider adding more advanced task features like subtasks, attachments, and integrations with calendar apps. I would also use a frontend framework like React or Vue to manage the UI more efficiently. The vanilla JS implementation was a great learning experience, but it would be more maintainable and scalable with a framework.