DEV Community: Vinicius Senger

Goodbye localhost: why Quarkus + Vanilla JS + AWS Lambda + DynamoDB Is the Fastest Path from Idea to Production

Vinicius Senger — Tue, 07 Apr 2026 22:29:46 +0000

AI-assisted development has changed everything. You describe what you want, an AI builds it, and in a couple of hours you have a working app on your laptop. I built re:Money — a full financial tracking app with dashboards, pivot tables, CSV import, and a chat interface — using Kiro, and it was genuinely fun.

But here's the pattern I keep seeing: developers build something incredible with AI, demo it on localhost, and then... it stays on localhost. Deploying to production becomes the hard part. Suddenly you need Docker, Kubernetes, a managed database, VPC configs, CI/CD pipelines, and a cloud architecture degree.

It doesn't have to be that way.

The secret isn't just how you code — it's what you choose to build with. re:Money deploys to AWS Lambda with two commands because of four deliberate architectural choices: Quarkus as the framework, vanilla JavaScript for the front-end, AWS Lambda for compute, and DynamoDB for storage. Together, these four pieces made the gap between "works on my machine" and "running in production" almost zero.

But First — What Is "Vanilla JS"?

If you've never heard the term, there's a great backstory. In 2012, a satirical website called Vanilla-JS.com appeared, presenting Vanilla JS as a "fast, lightweight framework" already "used by more websites than jQuery and React combined." When you clicked to "download" the library, you got an empty file — because Vanilla JS is just JavaScript itself. No framework. No dependencies. Just the language your browser already speaks.

That joke carries a real insight: for many applications, plain JavaScript is all you need. And when it comes to deployment, what you don't depend on matters just as much as what you use.

Why This Stack Is a Serverless Superpower

Before we get into the deployment steps, let's talk about why each piece of this stack is uniquely suited for going from idea to production.

Quarkus: One Framework, One Artifact, Zero Friction

Quarkus is the glue that holds everything together. It gives you:

Server-side rendering with Qute — HTML templates that live inside the JAR, no separate front-end build
First-class AWS Lambda support — Quarkus has a dedicated Lambda extension that handles the HTTP adapter for you
Fast startup — designed from the ground up for cloud-native and serverless workloads
Single uber-JAR — your entire app (REST API, templates, CSS, JS) compiles into one artifact
Dev mode with hot reload — ./mvnw quarkus:dev gives you instant feedback during development

With Spring Boot, you'd need extra configuration for Lambda. With Quarkus, it's a dependency and a handler class. Done.

Vanilla JS: No Build Pipeline for the Front-End

With React or Angular, you need Node.js, npm, a bundler (Webpack/Vite), and a separate build step that produces static assets you then have to serve from S3 or CloudFront. With re:Money, the UI is Qute templates + vanilla JS. It's all inside the JAR. One build, one artifact, one deployment.

AWS Lambda: Serverless Compute That Scales to Zero

Lambda means:

No servers to manage — no EC2 instances, no ECS clusters, no Kubernetes
Pay only for what you use — billed per request and compute time, idle = free
Automatic scaling — from zero to thousands of concurrent requests without configuration
SAM makes it declarative — your entire infrastructure is defined in one template.yaml

Lambda is the reason sam build && sam deploy is all you need. No Docker registry, no container orchestration, no load balancers.

DynamoDB: The Only Database That Matches Lambda's Model

This is the big one. If re:Money used PostgreSQL or MySQL, you'd need:

An RDS instance (always running, always billing)
VPC configuration for Lambda to reach the database
Connection pooling (Lambda cold starts + relational DBs = pain)
Database migrations on every deploy

DynamoDB has none of these problems. It's:

Pay-per-request — zero cost when idle
No connections to manage — it's HTTP-based, perfect for Lambda's ephemeral nature
No VPC required — Lambda talks to DynamoDB over the public AWS API
No migrations — schema-free, so your code is your schema
Scales to zero and to infinity — just like Lambda itself

Lambda + DynamoDB is the only truly serverless compute + storage combo on AWS. Everything else requires something running 24/7.

The Four Pieces Working Together

Here's why these four choices compound:

Quarkus bundles your templates and JS into a single JAR → no separate front-end deployment
Vanilla JS means no Node.js build step → that JAR is all you need to build
Lambda runs that JAR serverlessly → no infrastructure to provision
DynamoDB needs no VPC or connections → Lambda talks to it out of the box

Remove any one piece and the deployment story gets harder. Together, they create a frictionless path from git clone to production.

Single Deployable Artifact

re:Money compiles to one function.zip. No Docker images, no container registries, no multi-stage builds. SAM uploads it to S3, Lambda runs it. That's it.

The Cost Equation

For a personal finance app (or any low-to-moderate traffic tool), this architecture can run for pennies per month:

Service	Cost
Lambda	Free tier: 1M requests/month
API Gateway	Free tier: 1M calls/month
DynamoDB	Free tier: 25GB storage, 25 WCU/RCU
Total	~$0/month for personal use

Try getting that with ECS + RDS.

Prerequisites

Before starting, make sure you have:

Java 21+ installed
Maven 3.8+ (or use the included mvnw wrapper)
AWS CLI configured with credentials (aws configure)
AWS SAM CLI installed (install guide)

Step 1: Clone and Build

git clone https://github.com/renascence-computing/reos-money.git
cd reos-money

Build the Lambda-ready artifact:

./build-lambda.sh

This script does three things:

Runs mvn clean package with the uber-jar profile
Renames the runner JAR to function.jar
Zips it into target/function.zip

That's your entire application — backend, front-end, templates, CSS, JavaScript — in one zip file.

Step 2: Review the SAM Template

The template.yaml defines everything Lambda needs:

AWSTemplateFormatVersion: '2010-09-09'
Transform: AWS::Serverless-2016-10-31
Description: re:Money Quarkus Lambda Application

Resources:
  ReMoneyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: target/function.zip
      Handler: io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest
      Runtime: java21
      Timeout: 30
      MemorySize: 1024
      Events:
        ReMoneyApi:
          Type: HttpApi
          Properties:
            Path: /{proxy+}
            Method: ANY
        ReMoneyRoot:
          Type: HttpApi
          Properties:
            Path: /
            Method: ANY
      Policies:
        - DynamoDBCrudPolicy:
            TableName: !Ref EntryTable

  EntryTable:
    Type: AWS::DynamoDB::Table
    Properties:
      TableName: entry
      BillingMode: PAY_PER_REQUEST
      AttributeDefinitions:
        - AttributeName: id
          AttributeType: S
      KeySchema:
        - AttributeName: id
          KeyType: HASH

Key things to notice:

HttpApi (API Gateway v2) — cleaner URLs with no /Prod stage prefix
PAY_PER_REQUEST billing — you only pay for what you use
/{proxy+} catches all routes and forwards them to Quarkus
DynamoDB table is created automatically — no manual setup needed
No VPC, no subnets, no security groups — DynamoDB doesn't need them

Step 3: Deploy with SAM

For your first deployment, run the guided flow:

sam build
sam deploy --guided

SAM will ask you a few questions:

Stack Name [reMoney]: reMoney
AWS Region [us-east-1]: us-east-1
Confirm changes before deploy [y/N]: y
Allow SAM CLI IAM role creation [Y/n]: Y
ReMoneyFunction has no authentication. Is this okay? [y/N]: y
Save arguments to configuration file [Y/n]: Y

This creates a samconfig.toml so future deploys are just:

sam build && sam deploy

That's it. Two commands.

Step 4: Get Your API URL

After deployment, SAM prints your endpoint:

Outputs
---------------------------------------------------------------------------
Key                 ReMoneyApi
Description         API Gateway endpoint URL for re:Money application
Value               https://abc123xyz.execute-api.us-east-1.amazonaws.com/
---------------------------------------------------------------------------

Open that URL in your browser and you'll see re:Money running — dashboard, accounts, categories, pivot tables, everything.

Step 5: Verify It Works

Test the API:

# Get all entries
curl https://abc123xyz.execute-api.us-east-1.amazonaws.com/entryResource/findAll

# List categories
curl https://abc123xyz.execute-api.us-east-1.amazonaws.com/entryResource/listCategories

# Add an entry
curl -X POST https://abc123xyz.execute-api.us-east-1.amazonaws.com/entryResource \
  -H "Content-Type: application/json" \
  -d '{
    "accountID": "checking",
    "description": "Coffee",
    "category": "Food",
    "amount": -4.50,
    "date": "2026-04-06T09:00"
  }'

Open the UI:

open https://abc123xyz.execute-api.us-east-1.amazonaws.com/ui

Step 6: Update and Redeploy

Made changes? Redeploy in under a minute:

./build-lambda.sh
sam build && sam deploy

No Docker push, no CI/CD pipeline required, no container orchestration. Build, deploy, done.

Architecture Overview

Here's what you end up with:

┌──────────┐     ┌─────────────┐     ┌──────────────────┐     ┌──────────┐
│  Browser │────▶│ API Gateway │────▶│ Lambda (Java 21) │────▶│ DynamoDB │
│          │◀────│             │◀────│ Quarkus + Qute   │◀────│          │
└──────────┘     └─────────────┘     └──────────────────┘     └──────────┘
                                            │
                                     ┌──────┴──────┐
                                     │ Single JAR  │
                                     │ - REST API  │
                                     │ - HTML/CSS  │
                                     │ - Vanilla JS│
                                     └─────────────┘

Three managed AWS services. Zero servers. Zero containers. Zero infrastructure to maintain.

Why This Wouldn't Work with a Traditional Stack

Let's compare what deployment looks like with a typical modern stack:

Concern	React + Spring Boot + PostgreSQL	re:Money (Quarkus + Vanilla JS + Lambda + DynamoDB)
Framework	Spring Boot (heavier cold starts)	Quarkus (Lambda-optimized, SnapStart-ready)
Front-end build	`npm install && npm run build`	None (Qute templates + vanilla JS in JAR)
Front-end hosting	S3 + CloudFront	Served by Lambda (bundled in artifact)
Compute	ECS/EKS or Lambda with extra config	Lambda (native Quarkus support)
Database	RDS ($15+/month minimum)	DynamoDB (free tier)
VPC needed?	Yes (for RDS)	No
Connection pooling	Yes (RDS Proxy)	No (HTTP-based)
Cold start impact	High (Spring + DB connections)	Low (Quarkus + SnapStart, no DB pool)
Deploy commands	5-10 steps	`sam build && sam deploy`
Monthly cost (low traffic)	$20-50+	$0-1

The combination of Quarkus + vanilla JS + Lambda + DynamoDB isn't just a preference — it's an architectural decision that eliminates entire categories of deployment complexity.

Bonus: Eliminate Cold Starts with Lambda SnapStart

Java on Lambda has one well-known trade-off: cold starts. The first request after a period of inactivity can take a few seconds while the JVM initializes. Lambda SnapStart solves this.

What SnapStart Does

SnapStart takes a Firecracker microVM snapshot of your function after initialization — the JVM is booted, Quarkus is loaded, DynamoDB clients are ready. When a new invocation arrives, Lambda restores from that snapshot instead of starting from scratch. The result: cold starts drop from seconds to milliseconds.

How to Enable It

Add two lines to your template.yaml function properties:

ReMoneyFunction:
  Type: AWS::Serverless::Function
  Properties:
    # ... existing properties ...
    SnapStart:
      ApplyOn: PublishedVersions
    AutoPublishAlias: live

That's it. SnapStart tells Lambda to snapshot after init, and AutoPublishAlias creates a published version (required — SnapStart only works on published versions, not $LATEST).

You can also add this JVM flag to squeeze out extra startup performance:

Environment:
  Variables:
    JAVA_TOOL_OPTIONS: "-XX:+TieredCompilation -XX:TieredStopAtLevel=1"

Then redeploy:

sam build && sam deploy

Why This Matters

Without SnapStart, Java Lambda cold starts are typically 3-5 seconds for a Quarkus app. With SnapStart, you're looking at ~200-400ms — comparable to Node.js or Python cold starts, but with all the benefits of Java's type safety and Quarkus's performance at steady state.

Combined with DynamoDB (no connection pool to re-establish on restore), SnapStart makes Java on Lambda a genuinely production-ready choice with no latency excuses.

Tips for Production

Custom domain: Add a custom domain via API Gateway custom domain names + Route 53
Authentication: Add Amazon Cognito or a Lambda authorizer to protect your endpoints
Cold starts: Enable SnapStart (see above) — it's the single biggest improvement you can make
Monitoring: CloudWatch Logs are enabled by default — check the Lambda function's log group
Backups: DynamoDB supports on-demand backups and point-in-time recovery — enable PITR for peace of mind

Wrapping Up

AI-assisted development gave us the power to build apps in hours. But the dirty secret is that most of those apps never leave localhost — not because the code is bad, but because the architecture wasn't chosen with deployment in mind.

re:Money works in production because of four choices made before writing a single line of code: Quarkus as the framework, vanilla JS for the front-end, Lambda for compute, and DynamoDB for storage. Those choices eliminated the entire deployment gap.

No node_modules. No database migrations. No VPC. No containers. No orchestration.

Just sam build && sam deploy.

Next time you're building something new with AI, think about where it needs to run — not just where it's being built. The best architecture is the one that makes production feel as easy as localhost.

re:Money was built with Kiro and is open source as part of the Renascence Computing Project. Try it out, deploy it to your own AWS account, and see how far you can go without a framework.

Building a Full-Stack Java App with Quarkus — No React, No Angular, No Problem

Vinicius Senger — Tue, 31 Mar 2026 19:37:16 +0000

You don't need React. You don't need Angular. You don't need Vue, Svelte, or the JavaScript framework that launched last Tuesday.

I built re:Money — a full-stack financial tracking application with a dashboard, pivot tables, CSV import, inline editing, modals, and filtering — using nothing but Quarkus, its built-in Qute template engine, plain CSS, and a sprinkle of vanilla JavaScript. The backend talks to DynamoDB and the whole thing runs as a single JAR.

Let me show you how.

Why Skip the Front-End Framework?

For many internal tools, personal projects, and CRUD apps, a full SPA (single page application) framework adds:

A separate build pipeline (Node, npm, Webpack/Vite)
A JSON API contract you have to maintain
Client-side state management
Hundreds of megabytes of node_modules

With Quarkus + Qute, you get server-side rendering with type-safe templates, hot reload in dev mode, and a single mvn build. Your HTML is your UI. Your Java objects flow directly into your pages. Done.

The Stack

Layer	Technology
Runtime	Java 21
Framework	Quarkus 3.x
Templating	Qute (built into Quarkus)
Styling	Plain CSS
Interactivity	Vanilla JavaScript
Database	Amazon DynamoDB
Build	Maven

One language. One build tool. One deployable artifact.

Project Structure

src/main/java/org/reos/money/
├── model/          # Domain POJOs
├── resource/       # REST + UI endpoints (JAX-RS)
└── service/        # Business logic + DynamoDB access

src/main/resources/
├── templates/      # Qute HTML templates
├── META-INF/resources/css/   # Static CSS
└── application.properties

The key insight: UI endpoints and API endpoints live side by side in the same Quarkus app. No separate front-end project.

Step 1: Add the Dependencies

You only need one extra dependency beyond the standard Quarkus REST setup:

<!-- Qute templating with REST integration -->
<dependency>
    <groupId>io.quarkus</groupId>
    <artifactId>quarkus-rest-qute</artifactId>
</dependency>

That's it. Qute ships with Quarkus — quarkus-rest-qute just wires it into your JAX-RS resources so you can return TemplateInstance from your endpoints.

Step 2: Define Your Model

A plain Java class. No JPA annotations, no ORM magic — just fields and a factory method to map from DynamoDB's AttributeValue maps:

@RegisterForReflection
public class Entry {
    String id;
    public Long timestamp;
    public String accountID;
    public String description;
    public String category;
    public BigDecimal amount;
    public BigDecimal balance;
    public String date;

    public Entry() {
        this.id = UUID.randomUUID().toString();
    }

    public static Entry from(Map<String, AttributeValue> item) {
        Entry entry = new Entry();
        entry.id = item.get("id").s();
        entry.setAccountID(item.get("accountID").s());
        entry.setDescription(item.get("description").s());
        entry.setAmount(new BigDecimal(item.get("amount").n()));
        entry.setBalance(new BigDecimal(item.get("balance").n()));
        entry.setDate(item.get("date").s());
        entry.setTimestamp(Long.parseLong(item.get("timestamp").n()));
        entry.setCategory(item.get("category").s());
        return entry;
    }

    // getters and setters...
}

@RegisterForReflection is there for Quarkus native compilation support. The from() static factory keeps DynamoDB mapping logic close to the model.

Step 3: Build the Service Layer

The service layer handles all DynamoDB operations. A base class encapsulates the repetitive request-building:

public class AbstractService {

    public static final String ENTRY_ID_COL = "id";
    public static final String ENTRY_ACCOUNTID_COL = "accountID";
    // ... other column constants

    @ConfigProperty(name = "dynamodb.table.account.data")
    String tableName;

    protected ScanRequest scanRequest() {
        return ScanRequest.builder()
            .tableName(tableName)
            .attributesToGet(ENTRY_ID_COL, ENTRY_ACCOUNTID_COL, /* ... */)
            .build();
    }

    protected PutItemRequest putRequest(Entry entry) {
        Map<String, AttributeValue> item = new HashMap<>();
        item.put(ENTRY_ID_COL, 
            AttributeValue.builder().s(entry.getId()).build());
        item.put(ENTRY_AMOUNT_COL, 
            AttributeValue.builder().n(entry.getAmount().toString()).build());
        // ... map all fields
        return PutItemRequest.builder()
            .tableName(tableName).item(item).build();
    }

    protected DeleteItemRequest deleteRequest(String id) {
        return DeleteItemRequest.builder()
            .tableName(tableName)
            .key(Map.of(ENTRY_ID_COL, 
                AttributeValue.builder().s(id).build()))
            .build();
    }
}

Then the concrete service adds business logic:

@ApplicationScoped
public class EntryService extends AbstractService {

    @Inject
    DynamoDbClient dynamoDB;

    public List<Entry> findAll() {
        return dynamoDB.scan(scanRequest()).items().stream()
            .map(Entry::from)
            .sorted(Comparator.comparing(Entry::getTimestamp))
            .collect(Collectors.toList());
    }

    public Entry addEntry(Entry entry) {
        dynamoDB.putItem(putRequest(entry));
        return entry;
    }

    public List<Entry> findByFilters(String accountID, String category,
            Long startDate, Long endDate, String sortOrder,
            String excludeCategories, String description) {
        List<Entry> entries = findAll();

        if (accountID != null)
            entries = entries.stream()
                .filter(e -> accountID.equals(e.getAccountID()))
                .collect(Collectors.toList());

        if (category != null)
            entries = entries.stream()
                .filter(e -> category.equals(e.getCategory()))
                .collect(Collectors.toList());

        // ... date range, exclude, description filters

        if ("desc".equalsIgnoreCase(sortOrder))
            entries.sort(Comparator.comparing(Entry::getTimestamp).reversed());
        else
            entries.sort(Comparator.comparing(Entry::getTimestamp));

        return entries;
    }

    // replaceCategory, deleteAccount, recalculateBalances, etc.
}

No Spring Data, no Hibernate — just the AWS SDK DynamoDB client injected by Quarkus.

Step 4: The UI Resource — Where the Magic Happens

This is the core pattern. Instead of returning JSON, your endpoint returns a TemplateInstance:

@Path("/ui")
public class ExpenseUIResource {

    @Inject
    Template dashboard;  // Matches templates/dashboard.html

    @Inject
    EntryService entryService;

    @GET
    @Produces(MediaType.TEXT_HTML)
    public TemplateInstance getDashboard(
            @QueryParam("account") String account,
            @QueryParam("category") String category,
            @QueryParam("startDate") String startDate,
            @QueryParam("endDate") String endDate,
            @QueryParam("sortOrder") String sortOrder) throws Exception {

        // Parse dates, apply filters...
        List<Entry> entries = entryService.findByFilters(
            account, category, start, end, order, null, null);

        return dashboard
            .data("entries", entries)
            .data("accounts", entryService.listAccounts())
            .data("categories", entryService.listCategories())
            .data("selectedAccount", account)
            .data("selectedCategory", category)
            .data("sortOrder", order);
    }
}

When you @Inject Template dashboard, Quarkus automatically looks for src/main/resources/templates/dashboard.html. You pass data with .data("key", value) and Qute renders it server-side. The browser gets plain HTML.

Handling Form Submissions

Forms use standard HTML <form> posts — no fetch(), no JSON serialization:

@POST
@Path("/entry")
@Consumes(MediaType.APPLICATION_FORM_URLENCODED)
public Response addEntry(
        @FormParam("accountID") String accountID,
        @FormParam("description") String description,
        @FormParam("category") String category,
        @FormParam("amount") BigDecimal amount,
        @FormParam("date") String date) throws Exception {

    Entry entry = new Entry();
    entry.setAccountID(accountID);
    entry.setDescription(description);
    entry.setCategory(category);
    entry.setAmount(amount);
    entry.setDate(date);

    entryService.addEntry(entry);

    // Post-Redirect-Get pattern
    return Response.seeOther(URI.create("/ui")).build();
}

The Post-Redirect-Get pattern prevents duplicate submissions on refresh. The browser submits a form, the server processes it, then redirects back to the dashboard. Classic web development — and it works perfectly.

Step 5: Qute Templates — Your View Layer

Qute templates look like HTML with simple expressions. Here's a simplified version of the dashboard:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>re:Money Dashboard</title>
    <link rel="stylesheet" href="/css/app.css">
</head>
<body>
<div class="container">
    <!-- Filter form — plain HTML, no framework -->
    <form method="get" class="filters">
        <select name="account" onchange="this.form.submit()">
            <option value="">All Accounts</option>
            {#for account in accounts}
            <option value="{account}" 
                {#if selectedAccount == account}selected{/if}>
                {account}
            </option>
            {/for}
        </select>

        <select name="category" onchange="this.form.submit()">
            <option value="">All Categories</option>
            {#for category in categories}
            <option value="{category}"
                {#if selectedCategory == category}selected{/if}>
                {category}
            </option>
            {/for}
        </select>

        <input type="datetime-local" name="startDate" 
               value="{selectedStartDate ?: ''}" 
               onchange="this.form.submit()">
    </form>

    <!-- Data table -->
    <table>
        <thead>
            <tr>
                <th>Date</th>
                <th>Description</th>
                <th>Account</th>
                <th>Category</th>
                <th>Amount</th>
            </tr>
        </thead>
        <tbody>
            {#for entry in entries}
            <tr>
                <td>{entry.date}</td>
                <td>{entry.description}</td>
                <td>{entry.accountID}</td>
                <td>{entry.category}</td>
                <td class="{#if entry.amount < 0}negative{#else}positive{/if}">
                    ${entry.amount}
                </td>
            </tr>
            {/for}
        </tbody>
    </table>
</div>
</body>
</html>

Key Qute features used here:

{#for ... in ...} — loops over collections
{#if ...} — conditional rendering
{expression ?: 'default'} — elvis operator for defaults
{entry.amount} — direct property access on Java objects

The onchange="this.form.submit()" on the selects gives you instant filtering without any JavaScript framework. The browser submits the form as a GET request, the server re-renders the page with filtered data. Simple.

Step 6: Adding Interactivity with Vanilla JS

You don't need React for modals, inline editing, or dynamic filters. Here's how re:Money handles it:

Modal for Adding/Editing Entries

<div id="entryModal" class="modal">
    <div class="modal-content">
        <h2 id="modalTitle">Add New Entry</h2>
        <form method="post" action="/ui/entry" id="entryForm">
            <input type="text" name="description" required>
            <input type="number" name="amount" step="0.01" required>
            <input type="datetime-local" name="date" required>
            <button type="submit">Add Entry</button>
        </form>
    </div>
</div>

<script>
function openModal() {
    document.getElementById('entryModal').classList.add('active');
}

function editEntry(id, accountID, description, category, amount, date) {
    document.getElementById('modalTitle').textContent = 'Edit Entry';
    document.getElementById('entryForm').action = '/ui/entry/' + id + '/update';
    document.getElementById('descriptionUI').value = description;
    document.getElementById('amountUI').value = amount;
    document.getElementById('dateUI').value = date;
    document.getElementById('entryModal').classList.add('active');
}
</script>

The modal is pure CSS (.modal.active { display: flex; }). The form posts to the server. No state management library needed.

Inline Category Editing

<td>
    <span class="category-display" id="category-display-{entry.id}">
        {entry.category}
    </span>
    <select class="category-edit" id="category-edit-{entry.id}" 
            style="display: none;"
            onchange="updateCategory('{entry.id}', this.value)">
        {#for cat in categories}
        <option value="{cat}" {#if entry.category == cat}selected{/if}>
            {cat}
        </option>
        {/for}
    </select>
    <button onclick="toggleCategoryEdit('{entry.id}')">✏️</button>
</td>

Click the pencil, the span hides, the select shows. Pick a new category, a small fetch() call updates it server-side. This is the only place we use fetch() — for a better UX on a single field update. Everything else is plain form submissions.

Step 7: DynamoDB Setup

Create the table:

aws dynamodb create-table \
    --table-name entry \
    --attribute-definitions AttributeName=id,AttributeType=S \
    --key-schema AttributeName=id,KeyType=HASH \
    --billing-mode PAY_PER_REQUEST \
    --region us-east-1

For local development, add --endpoint-url http://localhost:8000 and configure Quarkus:

%dev.quarkus.dynamodb.endpoint-override=http://localhost:8000
dynamodb.table.account.data=entry

The %dev. prefix means this config only applies in dev mode. In production, Quarkus uses your default AWS credentials.

Step 8: Run It

./mvnw compile quarkus:dev

Open http://localhost:8080/ui and you have a full working app. Quarkus dev mode gives you:

Live reload — edit a Java file or a template, save, refresh the browser
Dev UI at /q/dev/ — inspect beans, config, endpoints
Zero restart — changes apply instantly

The Result

With this approach, re:Money has:

📊 Dashboard with multi-criteria filtering and sorting
➕ Add/Edit/Delete entries via modal forms
🗂️ Category management — rename, delete, inline edit
🏦 Account management — rename, delete, recalculate balances
📈 Pivot tables — cross-account category analysis
📁 CSV import — bulk data loading
💬 Chat interface — natural language queries (via Bedrock)

All in a single Quarkus application. No npm install. No package.json. No webpack config. No CORS issues. No separate deployment for the front-end.

When Should You Use This Approach?

✅ Good fit:

Internal tools and admin panels
Personal projects and prototypes
CRUD-heavy applications
Small team projects where everyone knows Java
Apps where SEO matters (server-rendered HTML)

❌ Consider a SPA when:

You need rich real-time interactivity (collaborative editing, drag-and-drop)
Your front-end team is specialized in JavaScript/TypeScript
You're building a complex single-page experience with heavy client-side state

Key Takeaways

Qute is underrated. It's type-safe, fast, and integrates seamlessly with Quarkus CDI. Just @Inject Template myPage and you're rendering HTML.
HTML forms still work. The Post-Redirect-Get pattern handles 90% of CRUD interactions without any JavaScript.
Vanilla JS is enough. Modals, toggles, inline edits — you don't need 200KB of framework for this.
One deployable artifact. Your UI, API, and business logic ship as a single JAR. Deploy it anywhere Java runs.
DynamoDB + Quarkus is a clean combo. The Quarkiverse extension handles client configuration. You write putItem / scan / deleteItem and move on.

The web platform is more capable than we give it credit for. Sometimes the best front-end framework is no framework at all.

Get re:Money

Want to try it yourself or use it as a starting point for your own project?

📖 re:Money — Personal Financial Management Re-imagined with AI — full project overview on AWS Community
💻 Source code on GitHub

Clone it, run ./mvnw compile quarkus:dev, and you're up in seconds.

Building Your Own AI-Powered StreamDeck with re:Button

Vinicius Senger — Sat, 28 Feb 2026 04:42:39 +0000

Physical Computing Meets AI!

Imagine creating your own keyboard but instead of regular keys, it triggers smart shortcuts in your computer that helps you to operate your life. That's the re:Button project: it transforms any physical MIDI controllers into intelligent command centers for your digital life, similar to StreamDeck, but open-source, DIY and much more simple and powerful.

In this post I will show how I built my own re:Button "StreamDeck" device using a Presonus ATOM (US$ 136) but you can use any other MIDI device, including a regular musical keyboard.

AWS DeepComposer Compatible

If you own a DeepComposer keyboard you can convert it TODAY in a re:Button device and creating a cool StreamDeck device with it! Just need to change the key codes...

What You Can Do with re:Button

Here are some real examples from my setup:

Press a button to hear your bank balance via text-to-speech
Turn a knob to control system volume
Launch projects in Kiro with dedicated buttons for each workspace
Control Spotify (play, pause, next track) without leaving your keyboard
Trigger workflows like taking a photo, checking calendar, or sending MQTT commands to smart home devices
Type common responses ("yes", "no", "thanks") with a single button press

The possibilities are endless because you can map any button to any shell command, AppleScript, or Python script.

Check the running demo in this video:

Step-by-Step: Building Your re:Button

1. Get Your MIDI Controller

I chose the Presonus ATOM because it has:

16 velocity-sensitive pads
8 knobs for continuous control
20 additional buttons
USB connectivity (no drivers needed)
Solid build quality

But you can use any MIDI controller: a $30 USB keyboard, a DJ controller, or even build your own with Arduino.

2. Plug in the USB Device

Connect your MIDI controller via USB. On macOS and Linux, it should work immediately. On Windows, you might need to install drivers (check your device manufacturer's website).

To verify it's working, you can list MIDI devices:

python3 -c "import mido; print(mido.get_input_names())"

You should see your device listed.

3. Using Kiro CLI to Create the First App

I used Kiro CLI, an AI-powered development assistant, to help build the initial version. Here's how:

kiro-cli chat

Then I asked:

"Help me create a Python script that listens to MIDI input and publishes the events to MQTT. I want to see the note number, velocity, and event type for each button press."

Kiro generated the first version of rebutton-mqtt.py:

#!/usr/bin/env python3
import mido
import paho.mqtt.client as mqtt
import json

MQTT_BROKER = "localhost"
MQTT_PORT = 1883
MQTT_TOPIC = "reos/key/atom"

def on_connect(client, userdata, flags, rc):
    print(f"Connected to MQTT broker: {rc}")

client = mqtt.Client()
client.on_connect = on_connect
client.connect(MQTT_BROKER, MQTT_PORT)
client.loop_start()

midi_port = mido.open_input(mido.get_input_names()[0])
print(f"Listening on {midi_port.name}...")

for msg in midi_port:
    if msg.type == "aftertouch" or msg.type == "polytouch":
        continue
    payload = json.dumps({
        "type": msg.type,
        "note": getattr(msg, 'note', None),
        "velocity": getattr(msg, 'velocity', None),
        "control": getattr(msg, 'control', None),
        "value": getattr(msg, 'value', None)
    })
    client.publish(MQTT_TOPIC, payload)
    print(f"Sent: {payload}")

4. The MQTT Version Came First

Why MQTT? It gave me two benefits:

Discovery: I could see exactly what MIDI events my controller was sending
Integration: I could trigger actions from other systems (Node-RED, Home Assistant, etc.)

Running this script, I pressed each button and noted the MIDI note numbers:

{"type": "note_on", "note": 96, "velocity": 127}
{"type": "control_change", "control": 14, "value": 64}

This told me that pad #1 sends note 96, and knob #1 sends control change 14.

5. Mapping Buttons and Actions with a Markdown File

Instead of hardcoding mappings in Python, I created a simple markdown configuration file: rebutton-config.md

# re:button Config

## Quick Responses
- 109[control_change]=osascript -e 'tell application "System Events" to keystroke "y"'
- 107[control_change]=osascript -e 'tell application "System Events" to keystroke "n"'

## System Control
- 14[control_change]=osascript -e "set volume output volume $value"

## Launch Apps
- 96[note_on]=/Applications/Kiro.app/Contents/MacOS/Electron /Users/vsenger/code/renascence/reos-core
- 97[note_on]=/Applications/Kiro.app/Contents/MacOS/Electron /Users/vsenger/code/renascence/reos-money
- 92[note_on]=open -a "Microsoft PowerPoint"
- 93[note_on]=open -a Firefox

## Media Control
- 86[note_on]=open -a Spotify && osascript -e 'tell application "Spotify" to play'
- 87[note_on]=open -a Spotify && osascript -e 'tell application "Spotify" to pause'

## Smart Shortcuts
- 112[note_on]=balance=$(curl -s http://localhost:8080/entryResource/balance/BofA | jq -r '.balance'); python3 text_to_speech.py "Your balance is $balance"

The format is simple: note_number[event_type]=command

Variables like $value and $velocity get replaced with actual MIDI values.

6. The Main Script: rebutton.py

Again, I used Kiro to generate the parser and executor:

#!/usr/bin/env python3
import mido
import re
import subprocess

def parse_config(filename):
    config = {}
    with open(filename) as f:
        for line in f:
            match = re.match(r'^-\s*(\d+)\[(\w+)\]=(.+)$', line.strip())
            if match:
                note, event_type, command = match.groups()
                config[(int(note), event_type)] = command.strip()
    return config

config = parse_config("rebutton-config.md")
midi_port = mido.open_input(mido.get_input_names()[0])
print(f"Listening on {midi_port.name}...")

for msg in midi_port:
    key = (getattr(msg, 'note', None) or getattr(msg, 'control', None), msg.type)
    if key in config and config[key]:
        command = config[key]
        command = command.replace('$value', str(getattr(msg, 'value', '')))
        command = command.replace('$velocity', str(getattr(msg, 'velocity', '')))
        print(f"Executing: {command}")
        subprocess.Popen(command, shell=True)

That's it! Less than 30 lines of Python.

7. Using Kiro CLI Agent to Improve

The real power comes from using AI to enhance your setup. Here's how I use Kiro:

Discovering new commands:

> "Create a command that takes a screenshot and saves it to my Desktop"

Building complex workflows:

> "Help me create a script that checks my calendar for the next meeting 
   and speaks the meeting title and time"

Optimizing button layouts:

> "I have 16 pads. Suggest an ergonomic layout for: 
   4 project launchers, 4 media controls, 4 quick responses, 
   and 4 smart shortcuts"

Generating API integrations:

> "Write a curl command to get my bank balance from my re:Money API 
   and format it for text-to-speech"

Kiro understands context, so you can iterate quickly:

> "Make that command shorter"
> "Add error handling"
> "Now create a version for my credit card balance"

Installation & Setup

Requirements

pip install mido python-rtmidi paho-mqtt

On macOS, you might also need:

brew install portmidi

Quick Start

Clone or download the re:Button files
Connect your MIDI controller
Run the MQTT version to discover your button numbers:

   python3 rebutton-mqtt.py

Create your rebutton-config.md file
Run the main script:

   python3 rebutton.py

Real-World Usage

After using re:Button for a few weeks, here's what I've learned:

Most-used buttons:

Project launchers (I have 4 different workspaces)
Volume control knob (so much better than keyboard shortcuts)
"Yes/No/Thanks" quick responses (saves typing in meetings)

Surprising use cases:

Taking quick photos with Photo Booth for video calls
Checking bank balance without opening apps
Controlling smart home devices via MQTT

What I'd improve:

Add visual feedback (LEDs on the pads)
Create profiles for different contexts (work, home, creative)
Build a web UI for easier configuration

Why This Matters

re:Button is part of a larger vision called Renascence Computing—rethinking how we interact with computers to serve our lives, not the other way around.

Physical buttons create a tangible interface to your digital life. Instead of context-switching between apps and memorizing shortcuts, you have dedicated controls for what matters most.

Combined with AI (via Kiro), you can rapidly prototype and evolve your interface. The barrier between "I wish I could..." and "Done!" shrinks to minutes.

Get Started

Code: GitHub - re:button
Kiro CLI: kiro.dev
Community: Join the Renascence Computing community

What Will You Build?

The beauty of re:Button is that it's infinitely customizable. Your button layout will be completely different from mine because your life and workflows are different.

What would you put on your buttons? Share in the comments!

This is part of the Renascence Computing project—a movement to rebuild our relationship with technology. Learn more at Renascence Github Repositoy