DEV Community: Vinicius Senger

16 Botões, 1 Lâmpada WiFi e um Agente de AI: Projeto de Sexta-Feira

Vinicius Senger — Fri, 01 May 2026 17:54:27 +0000

Como eu combinei uma lâmpada WiFi de $15, uma mesa controladora MIDI de 16 botões coloridos e o Kiro CLI para criar um controlador de cores físico — projeto de sexta-feira para se divertir no fim de semana!

Fala galera! Há 15 anos atrás eu criei o jHome Automation, um sistema de automação residencial baseado em Arduino com Java da época que nem chamávamos de Internet of Things. De lá pra cá, muita coisa mudou. Os módulos WiFi se popularizaram, o preço caiu absurdamente, e a inteligência artificial mudou completamente a velocidade com que a gente consegue hackear as coisas.

Neste post eu vou mostrar em detalhes como combinei uma lâmpada WiFi de $15, uma mesa controladora MIDI com 16 botões coloridos e o Kiro CLI para criar um controlador de cores físico — um projetinho de sexta-feira que você pode replicar no fim de semana.

O Hardware

Kauf Bulb — a lâmpada inteligente de $15

A Kauf Bulb é uma lâmpada WiFi que custa cerca de $15 na Amazon — apenas uns $4 a mais que uma lâmpada WiFi convencional. O diferencial dela é que ela vem com um ESP32 dentro e já roda o firmware ESPHome, o que significa que:

Você consegue controlar via REST na sua rede local (sem nuvem!)
Você pode configurar um broker MQTT e controlar remotamente
Você pode trocar o firmware se quiser customizar ainda mais

Sem depender de app proprietário, sem cloud obrigatório. Conectou na WiFi, já tem uma API REST pronta.

Presonus ATOM — a mesa de 16 pads

A Presonus ATOM (~$136) é uma interface originalmente feita para produção musical / DJ, mas que funciona perfeitamente como interface de controle genérica. Ela tem:

16 pads sensíveis a velocidade com LEDs RGB programáveis
4 knobs rotativos (encoders relativos)
Conectividade USB — plug and play, sem drivers
Comunicação via MIDI — protocolo universal e simples

O que eu fiz com ela: cada pad virou uma cor, e os 4 knobs controlam a intensidade (brightness) e os canais Red, Green e Blue da lâmpada.

Configurando a Lâmpada com ESPHome

A primeira coisa que fiz foi configurar a Kauf Bulb para se conectar ao meu broker MQTT. O ESPHome usa um arquivo YAML de configuração. Basicamente você define:

A rede WiFi
O endereço do broker MQTT
O topic prefix para as mensagens

wifi:
  ssid: "SuaRedeWiFi"
  password: "SuaSenha"

mqtt:
  broker: broker.hivemq.com
  port: 1883
  topic_prefix: playground/bulb1

Com o ESPHome CLI, subi essa configuração para a lâmpada:

esphome run kauf_bulb.yaml

A partir daí, a lâmpada já aceita comandos tanto via REST local quanto via MQTT. A documentação do ESPHome é bem direta, e se tiver qualquer dúvida, o Kiro CLI te ajuda — eu inclusive usei ele para gerar os arquivos de configuração. Pedi "set up my ESPHome MQTT config" e ele já sabia o que fazer.

O Código: Controlando a Lâmpada com Python

A Paleta de 16 Cores

Cada um dos 16 pads tem uma cor atribuída. Defini valores RGB separados para os LEDs dos pads (range 0-127, padrão MIDI) e para a lâmpada (range 0-255):

COLORS = [
    ("Red",         127,   0,   0,   255,   0,   0),
    ("Orange",      127,  40,   0,   255,  80,   0),
    ("Yellow",      127, 127,   0,   255, 255,   0),
    ("Lime",         64, 127,   0,   128, 255,   0),
    ("Green",         0, 127,   0,     0, 255,   0),
    ("Mint",          0, 127,  64,     0, 255, 128),
    ("Cyan",          0, 127, 127,     0, 255, 255),
    ("Sky",           0,  64, 127,     0, 128, 255),
    ("Blue",          0,   0, 127,     0,   0, 255),
    ("Purple",       64,   0, 127,   128,   0, 255),
    ("Magenta",     127,   0, 127,   255,   0, 255),
    ("Pink",        127,   0,  64,   255,   0, 128),
    ("White",       127, 127, 127,   255, 255, 255),
    ("Warm White",  127,  90,  40,   255, 180,  80),
    ("Cool White",   80, 100, 127,   160, 200, 255),
    ("Coral",       127,  50,  40,   255, 100,  80),
]

Quando o programa inicia, todos os pads acendem com suas cores — você tem uma paleta física na sua mesa:

 Red      Orange   Yellow   Lime
 Green    Mint     Cyan     Sky
 Blue     Purple   Magenta  Pink
 White    Warm Wh  Cool Wh  Coral

Apertou um pad, a lâmpada muda pra aquela cor. Simples assim.

Versão REST (Rede Local)

A primeira versão controla a lâmpada via HTTP direto na rede local:

def bulb_color(r, g, b):
    url = f"{BULB}/{LIGHT}/turn_on?r={r}&g={g}&b={b}"
    urllib.request.urlopen(urllib.request.Request(url, method='POST'), timeout=2)

def bulb_brightness(bright):
    url = f"{BULB}/{LIGHT}/turn_on?brightness={bright}"
    urllib.request.urlopen(urllib.request.Request(url, method='POST'), timeout=2)

Funciona muito bem quando a lâmpada e o computador estão na mesma rede. Zero latência perceptível.

Versão MQTT (Controle Remoto)

Depois troquei para MQTT, o que abre possibilidades de controle remoto e integração com outros sistemas:

import paho.mqtt.client as mqtt

MQTT_BROKER = "broker.hivemq.com"
MQTT_PORT = 1883
MQTT_TOPIC = "playground/bulb1/light/kauf_bulb/command"

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

def bulb_color(r, g, b):
    payload = json.dumps({"state": "ON", "color": {"r": r, "g": g, "b": b}})
    client.publish(MQTT_TOPIC, payload)

def bulb_brightness(bright):
    payload = json.dumps({"state": "ON", "brightness": bright})
    client.publish(MQTT_TOPIC, payload)

A mesma interface, os mesmos pads, os mesmos knobs — mas agora os comandos viajam via MQTT. Você pode controlar a lâmpada de qualquer lugar, ter múltiplas lâmpadas no mesmo topic, ou integrar com Home Assistant, Node-RED, etc.

Os Desafios (e como o Kiro resolveu)

Desafio 1: Encoder Relativo vs. Absoluto

O Kiro gerou a primeira versão rapidinho. Funcionou de primeira para as cores dos pads. Mas quando fui controlar a intensidade com o knob, o comportamento era estranho — a intensidade ficava travada em ~50% e parecia invertida.

O problema: o Kiro tratou o knob como um controlador absoluto (valores de 0 a 127), mas a Presonus ATOM usa encoders relativos. Cada tick do knob manda:

value = 1 → sentido horário (aumentar)
value = 65 → sentido anti-horário (diminuir)

A correção foi manter o estado da intensidade manualmente e incrementar/decrementar a cada tick:

brightness = 255  # estado inicial: máximo
STEP = 8

def knob_delta(value):
    if value == 1:
        return STEP      # clockwise → aumenta
    if value == 65:
        return -STEP     # counter-clockwise → diminui
    return 0

# No loop MIDI:
brightness = clamp(brightness + knob_delta(msg.value))

Esse é o tipo de detalhe que só se descobre rodando no hardware real. Expliquei o comportamento pro Kiro e ele corrigiu na hora.

Desafio 2: Debounce — a lâmpada piscando

Com o encoder corrigido, a intensidade funcionava perfeitamente... até eu girar o knob rápido. A lâmpada ficava piscando porque cada tick disparava uma requisição HTTP/MQTT, e a lâmpada não conseguia processar tão rápido.

A solução é uma técnica clássica da eletrônica chamada debounce: ao invés de enviar a cada tick, você espera uns 200ms sem atividade e só então envia. Se o usuário continua girando, o timer reseta.

_brightness_timer = None
_timer_lock = threading.Lock()

def schedule_brightness_update():
    global _brightness_timer
    with _timer_lock:
        if _brightness_timer:
            _brightness_timer.cancel()
        _brightness_timer = threading.Timer(
            0.1, lambda: bulb_brightness(brightness)
        )
        _brightness_timer.daemon = True
        _brightness_timer.start()

O estado atualiza instantaneamente na memória, mas a chamada de rede é coalescida. Resultado: giro suave, sem flicker.

Desafio 3: De REST para MQTT

A primeira versão usava REST direto na rede local. Quando configurei o broker MQTT na lâmpada, precisei trocar o transporte no código Python. Falei pro Kiro: "troca de REST pra MQTT" e ele substituiu as chamadas HTTP por client.publish() mantendo toda a lógica de MIDI e debounce intacta.

O Resultado Final

O programa roda no terminal. Quando inicia:

Conecta ao broker MQTT
Abre a interface MIDI
Acende todos os 16 pads com suas cores
Inicializa a lâmpada em branco, intensidade máxima

A partir daí:

Aperta um pad → lâmpada muda pra aquela cor instantaneamente
Gira o Knob 1 → controla a intensidade (brightness)
Gira o Knob 2 → ajusta o canal Red
Gira o Knob 3 → ajusta o canal Green
Gira o Knob 4 → ajusta o canal Blue

Você pode escolher uma cor base no pad e depois refinar com os knobs. Quer um pink? Aperta o vermelho, depois aumenta um pouco de blue no knob 4. Quer um verde mais escuro? Aperta o green, depois diminui a intensidade no knob 1.

Por que Interfaces Minimalistas?

Eu estou pirando nessa ideia de interfaces minimalistas — e tem um motivo. Com a computação agêntica e AI, a gente vai conseguir comandar computadores com poucos botões. Muitas das operações que hoje exigem mouse, teclado, navegar em menus — acessar conta bancária, ver saldo, abrir aplicativos — o agente de AI já vai fazer pra gente.

Na minha visão, não vamos precisar de computadores completos com teclado e monitor para tudo. Você pode juntar um Raspberry Pi, uma interface dessas, um audiozinho e ter um sistema completo para controlar a automação da sua casa.

O projeto re:Button já faz muito mais do que controlar lâmpada:

Demos de palestra — botão 1 é uma demo, botão 2 é outra, botão 3 toca um áudio, botão 4 roda um vídeo
Atalhos de sistema — volume, screenshots, respostas rápidas em reuniões
Lançar projetos — cada pad abre um workspace diferente no Kiro
Smart home — controlar lâmpadas, ventiladores, cenas

Como Rodar

Dependências

pip install mido python-rtmidi paho-mqtt

Versão REST (rede local)

# Edite o IP da lâmpada no arquivo
python3 rebutton-lamp.py

Versão MQTT

python3 rebutton-lamp-mqtt.py

Não precisa ser uma Presonus ATOM — qualquer controlador MIDI com pads funciona, basta ajustar os números das notas. Não precisa ser uma Kauf Bulb — qualquer lâmpada compatível com ESPHome ou MQTT serve.

O Papel do Kiro CLI

O Kiro CLI foi meu parceiro em todo o processo:

Gerou a primeira versão completa — listener MIDI, chamadas REST, mapeamento de cores, setup dos LEDs dos pads
Ajudou a configurar o ESPHome — gerou os arquivos YAML de configuração do MQTT
Corrigiu o bug do encoder — expliquei o sintoma, ele entendeu e reescreveu a lógica
Implementou o debounce — descrevi o problema do flicker, ele escolheu o padrão correto com threading.Timer
Portou de REST para MQTT — trocou a camada de transporte preservando toda a lógica existente
Adicionou os 4 knobs — generalizou o padrão de um knob para quatro com debounce independente

Nos dias de hoje, a gente consegue fazer as coisas muito rápido. O tempo total de desenvolvimento das quatro versões foi menos de uma hora.

Conclusão

Projetinho de sexta-feira: uma lâmpada WiFi de $15, uma mesa MIDI, Python e o Kiro CLI. O resultado é uma interface física, tátil, colorida, que controla a iluminação da sua casa sem abrir nenhum app.

É o tipo de projeto pra se divertir no fim de semana com a família e transformar a sua casa em um parque tecnológico.

Se você montar o seu, me conta nos comentários!

Adding MCP to a Quarkus App: One Dependency, a Few Annotations, Done

Vinicius Senger — Thu, 23 Apr 2026 04:46:50 +0000

I added MCP (Model Context Protocol) to re:Money — my Quarkus + DynamoDB financial tracking app — in under 30 minutes. One dependency, a few annotations on existing service methods, and my MCP client (Kiro / Claude) could call my actual backend during development. Here's exactly what I did.

New to re:Money? Check out the full tutorial on AWS Community to get started.

The Starting Point

re:Money is a standard three-tier Quarkus app:

Layer	What It Does
Model	`Entry` — accountID, category, amount, balance, date
Service	`EntryService` — business logic and DynamoDB queries
Resource	JAX-RS REST endpoints

The service layer already had methods like findByAccountID(), findByCategory(), listCategories(), getLastBalance(). All I needed was to make them discoverable by AI tools.

Step 1: Add the Dependency

<dependency>
    <groupId>io.quarkiverse.mcp</groupId>
    <artifactId>quarkus-mcp-server-http</artifactId>
    <version>1.10.1</version>
</dependency>

No configuration needed. Quarkus auto-discovers MCP tools and exposes them at /mcp.

Step 2: Annotate Your Service Methods

Add @Tool and @ToolArg to existing methods — no new code:

import io.quarkiverse.mcp.server.Tool;
import io.quarkiverse.mcp.server.ToolArg;

@ApplicationScoped
public class EntryService extends AbstractService {

    @Tool(description = "Find all financial entries for a specific bank account")
    public List<Entry> findByAccountID(
            @ToolArg(description = "The account identifier, e.g. ACC001")
            String accountID) {
        return findAll().stream()
                .filter(e -> e.getAccountID().equals(accountID))
                .collect(Collectors.toList());
    }

    @Tool(description = "Find financial entries by spending category")
    public List<Entry> findByCategory(
            @ToolArg(description = "Category name like Food, Transport, Housing")
            String category) {
        return findAll().stream()
                .filter(e -> category.equals(e.getCategory()))
                .collect(Collectors.toList());
    }

    @Tool(description = "List all available spending categories")
    public List<String> listCategories() {
        return findAll().stream()
                .map(Entry::getCategory)
                .distinct().sorted()
                .collect(Collectors.toList());
    }

    @Tool(description = "List all bank accounts")
    public List<String> listAccounts() { /* ... */ }

    @Tool(description = "Get the last known balance for a bank account")
    public BigDecimal getLastBalance(
            @ToolArg(description = "The account identifier")
            String accountID) { /* ... */ }

    @Tool(description = "Find entries for an account within a date range")
    public List<Entry> findByAccountIDAndDates(
            @ToolArg(description = "Account identifier") String accountID,
            @ToolArg(description = "Start date as epoch millis") Long init,
            @ToolArg(description = "End date as epoch millis") Long end) { /* ... */ }
}

The description fields matter — they're what the AI reads to decide which tool to call. Be specific to your domain.

Step 3: Run It

./mvnw compile quarkus:dev

MCP endpoint is live at http://localhost:8080/mcp.

Step 4: Configure Kiro as MCP Client

With re:Money running, you tell Kiro where to find the MCP server. Create .kiro/settings/mcp.json in your project root:

{
  "mcpServers": {
    "remoney": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

This is a workspace-scoped configuration — it only applies when you're working in this project. You can also set it globally at ~/.kiro/settings/mcp.json if you want it available everywhere.

Another option is to create a dedicated Kiro agent for working with re:Money. Create .kiro/agents/finance-dev.json:

{
  "name": "finance-dev",
  "description": "Development assistant with live access to re:Money",
  "mcpServers": {
    "remoney": {
      "url": "http://localhost:8080/mcp"
    }
  }
}

Once configured, start a Kiro chat session and run /mcp to verify the server is connected and the tools are loaded:

You should see remoney listed with all your @Tool-annotated methods as available tools.

Demo: Kiro Calling re:Money

Once connected, Kiro chat now can reach your financial data and I love it because I can keep coding and using the chat to input data and query my re:Money app in a single place.

One Catch: MCP and Lambda Don't Mix

re:Money deploys to AWS Lambda using Quarkus's Lambda HTTP extension. But MCP requires a persistent HTTP connection — the server needs to stay alive to handle tool calls from the AI client. Lambda's request-response model doesn't support that.

So if your app runs on Lambda (or any short-lived serverless compute), you can't just add MCP to the same module and deploy it. You need to separate the MCP server into its own module and deploy it on a service that keeps a long-running process: ECS, App Runner, EC2, or even a local dev server.

In practice, this means:

Your Lambda module stays as-is — REST API, UI, the production workload
A new MCP module imports your service layer and exposes it via quarkus-mcp-server-http, deployed on ECS/App Runner/EC2

The service layer stays shared. The only difference is how it's exposed and where it runs. This is another reason to keep your business logic in the service layer and out of your REST controllers — it makes splitting modules painless.

For local development, this isn't an issue. ./mvnw quarkus:dev runs a long-lived process and MCP works fine. The separation only matters when you deploy to production.

What I Learned

Your service layer is the API. If your business logic lives in the service layer and not in your REST controllers, adding MCP is almost free.

Descriptions are the real work. The AI picks tools based on descriptions alone. Writing clear, domain-specific descriptions took more thought than any code change.

Start read-only. Expose queries first. Open up writes when you're ready.

Quarkus makes this trivial. One dependency, a few annotations, no config. The Quarkiverse MCP extension handles protocol, discovery, and transport. If you have a Quarkus app with a clean service layer, try it.

Resources

Goodbye localhost, hello AWS: adding security to your Java serveless app

Vinicius Senger — Tue, 14 Apr 2026 18:55:31 +0000

In the first part of this series, we took re:Money from localhost to production with sam build && sam deploy. Two commands, zero servers, and a fully working financial tracking app on AWS Lambda.

But there's a problem: anyone with the URL can see your data.

That API Gateway endpoint we got? It's public. No login, no authentication, no authorization. For a personal finance app, that's not acceptable. Time to fix it.

In this article, we'll add Amazon Cognito with Google sign-in to re:Money — so only you (or people you invite) can access the app.

What We're Building

┌──────────┐     ┌──────────────┐     ┌─────────────┐     ┌────────┐     ┌──────────┐
│  Browser │────▶│ Google Login │────▶│   Cognito   │────▶│  JWT   │     │          │
│          │     │  (OAuth 2.0) │     │  User Pool  │     │ Token  │     │          │
└──────────┘     └──────────────┘     └─────────────┘     └───┬────┘     │          │
                                                              │          │          │
                                                              ▼          │          │
                                                        ┌───────────┐    │          │
                                                        │    API    │──▶ │ Lambda   │──▶ DynamoDB
                                                        │  Gateway  │    │(Quarkus) │
                                                        │ (JWT Auth)│    │          │
                                                        └───────────┘    └──────────┘

We protect re:Money at two layers:

API Gateway JWT authorizer — REST API routes (/entryResource/*, /csv-import/*) require a valid Cognito JWT in the Authorization header. No token? 401 before Lambda even wakes up.
Server-side cookie check — The Qute-rendered UI pages (/ui/*) are public at the gateway level (they have to be — browsers don't send Authorization headers on page navigation). Instead, the Java resource checks for an id_token cookie and redirects to Cognito login if it's missing.

The glue between these two layers is a small JavaScript file (auth.js) that stores the Cognito token in both localStorage (for fetch() calls) and a cookie (for server-side checks).

Step 1: Get Google OAuth Credentials

Before touching AWS, you need a Google OAuth client:

Go to Google Cloud Console → Credentials
Create a new project (or use an existing one)
Click Create Credentials → OAuth 2.0 Client ID
Application type: Web application
Leave the redirect URI blank for now — we'll come back after creating the Cognito domain
Save your Client ID and Client Secret

Step 2: Update template.yaml

Here's the full picture. We add Cognito resources, a JWT authorizer on API Gateway, and split routes into protected (API) and public (UI):

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

Parameters:
  GoogleClientId:
    Type: String
    Description: Google OAuth Client ID
    NoEcho: true
  GoogleClientSecret:
    Type: String
    Description: Google OAuth Client Secret
    NoEcho: true

Globals:
  Function:
    Timeout: 30
    MemorySize: 512
    Runtime: java21
    Environment:
      Variables:
        QUARKUS_PROFILE: prod

Resources:
  # --- Cognito ---
  ReMoneyUserPool:
    Type: AWS::Cognito::UserPool
    Properties:
      UserPoolName: remoney-users
      AutoVerifiedAttributes:
        - email
      Schema:
        - Name: email
          Required: true
          Mutable: true

  ReMoneyUserPoolDomain:
    Type: AWS::Cognito::UserPoolDomain
    Properties:
      Domain: remoney-auth  # Must be globally unique
      UserPoolId: !Ref ReMoneyUserPool

  GoogleIdentityProvider:
    Type: AWS::Cognito::UserPoolIdentityProvider
    Properties:
      UserPoolId: !Ref ReMoneyUserPool
      ProviderName: Google
      ProviderType: Google
      ProviderDetails:
        client_id: !Ref GoogleClientId
        client_secret: !Ref GoogleClientSecret
        authorize_scopes: "openid email profile"
      AttributeMapping:
        email: email
        name: name
        username: sub

  ReMoneyUserPoolClient:
    Type: AWS::Cognito::UserPoolClient
    DependsOn: GoogleIdentityProvider
    Properties:
      ClientName: remoney-web
      UserPoolId: !Ref ReMoneyUserPool
      GenerateSecret: false
      SupportedIdentityProviders:
        - Google
      AllowedOAuthFlows:
        - implicit
      AllowedOAuthScopes:
        - openid
        - email
        - profile
      AllowedOAuthFlowsUserPoolClient: true
      CallbackURLs:
        - https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback
        - https://localhost/ui/callback
      LogoutURLs:
        - https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback
        - https://localhost/ui/callback

Note on CallbackURLs: You can't use !Sub "${ReMoneyHttpApi}" here because it creates a circular dependency — the API references the UserPoolClient for its authorizer, and the client would reference the API for its callback URL. Use https://localhost/ui/callback for the first deploy, then update with the actual API Gateway URL from the stack outputs.

Why /ui/callback and not /ui? This is critical. Cognito's implicit flow returns the token in the URL fragment (#id_token=...). Fragments are client-side only — the server never sees them. If Cognito redirects to /ui, the server-side auth check sees no cookie, and redirects back to Cognito — an infinite loop. The /ui/callback endpoint serves a minimal page with no auth check, giving JavaScript a chance to capture the token and set the cookie before navigating to /ui.

Next, the API Gateway with a JWT authorizer:

  # --- API Gateway with JWT Auth ---
  ReMoneyHttpApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      Auth:
        DefaultAuthorizer: CognitoAuthorizer
        Authorizers:
          CognitoAuthorizer:
            AuthorizationScopes:
              - openid
            IdentitySource: $request.header.Authorization
            JwtConfiguration:
              issuer: !Sub "https://cognito-idp.${AWS::Region}.amazonaws.com/${ReMoneyUserPool}"
              audience:
                - !Ref ReMoneyUserPoolClient

And the Lambda function with split routes — protected API vs public UI:

  # --- Lambda ---
  ReMoneyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: target/function.zip
      Handler: io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest
      MemorySize: 1024
      Events:
        # Protected API routes (JWT required)
        EntryApi:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /entryResource/{proxy+}
            Method: ANY
        CsvImportApi:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /csv-import/{proxy+}
            Method: ANY
        # Public UI routes (no gateway auth — server checks cookie)
        PublicUI:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /ui/{proxy+}
            Method: ANY
            Auth:
              Authorizer: NONE
        PublicUIRoot:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /ui
            Method: ANY
            Auth:
              Authorizer: NONE
        # Static assets
        PublicCss:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /css/{proxy+}
            Method: GET
            Auth:
              Authorizer: NONE
        PublicJs:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /js/{proxy+}
            Method: GET
            Auth:
              Authorizer: NONE

The key insight: /entryResource/* and /csv-import/* use the default JWT authorizer. /ui/*, /css/*, and /js/* override with Authorizer: NONE so the browser can load pages and static assets. The UI pages are protected at the application level instead.

Step 3: Update the Google Redirect URI

After the first deploy, go back to Google Cloud Console and add the Cognito redirect URI:

https://remoney-auth.auth.us-east-1.amazoncognito.com/oauth2/idpresponse

Replace remoney-auth with your domain and us-east-1 with your region.

Step 4: The Auth JavaScript — auth.js

This is the client-side glue. It handles the Cognito OAuth callback, stores the token, and bridges the gap between browser navigation and API calls.

Create src/main/resources/META-INF/resources/js/auth.js:

// re:Money Auth - Cognito + Google sign-in
const AUTH_CONFIG = {
    cognitoDomain: 'remoney-auth.auth.us-east-1.amazoncognito.com',
    clientId: 'YOUR_COGNITO_CLIENT_ID',  // From SAM outputs
    redirectUri: window.location.origin + '/ui/callback',
    provider: 'Google'
};

function remoneyLogin() {
    window.location.href =
        'https://' + AUTH_CONFIG.cognitoDomain + '/oauth2/authorize?' +
        'response_type=token&client_id=' + AUTH_CONFIG.clientId +
        '&redirect_uri=' + encodeURIComponent(AUTH_CONFIG.redirectUri) +
        '&scope=openid+email+profile&identity_provider=' + AUTH_CONFIG.provider;
}

Note the redirectUri points to /ui/callback, not /ui. This is essential to avoid the redirect loop (more on that in the Gotchas section).

Cookie management — this is what makes server-side auth work. After Cognito redirects back with a token in the URL fragment, we store it in both localStorage and a cookie:

function setAuthCookie(token, maxAgeSec) {
    document.cookie = 'id_token=' + token +
        ';path=/;max-age=' + maxAgeSec + ';SameSite=Lax;Secure';
}

function clearAuthCookie() {
    document.cookie = 'id_token=;path=/;max-age=0';
}

function remoneyLogout() {
    localStorage.removeItem('id_token');
    localStorage.removeItem('token_expiry');
    clearAuthCookie();
    window.location.href =
        'https://' + AUTH_CONFIG.cognitoDomain + '/logout?' +
        'client_id=' + AUTH_CONFIG.clientId +
        '&logout_uri=' + encodeURIComponent(AUTH_CONFIG.redirectUri);
}

function getToken() {
    var expiry = localStorage.getItem('token_expiry');
    if (expiry && Date.now() > parseInt(expiry)) {
        localStorage.removeItem('id_token');
        localStorage.removeItem('token_expiry');
        clearAuthCookie();
        return null;
    }
    return localStorage.getItem('id_token');
}

Token capture and redirect — Cognito uses the implicit flow, which puts the token in the URL fragment (#id_token=...). We parse it on the callback page and redirect to the main UI:

(function handleCallback() {
    var hash = window.location.hash.substring(1);
    if (!hash) return;
    var params = new URLSearchParams(hash);
    var token = params.get('id_token');
    var expiresIn = params.get('expires_in');
    if (token) {
        var ttl = expiresIn ? parseInt(expiresIn) : 3600;
        localStorage.setItem('id_token', token);
        localStorage.setItem('token_expiry', String(Date.now() + ttl * 1000));
        setAuthCookie(token, ttl);
        // Redirect to the main UI now that cookie is set
        window.location.href = window.location.origin + '/ui';
        return;
    }
})();

The key line is window.location.href = window.location.origin + '/ui'. After setting the cookie, we navigate to /ui — and this time the server-side check will find the cookie and render the dashboard.

Fetch interceptor — patches window.fetch so every AJAX call includes the Authorization header. This is what protects the /entryResource/* API calls made from the UI:

(function patchFetch() {
    var originalFetch = window.fetch;
    window.fetch = function(url, options) {
        var token = getToken();
        if (token) {
            options = options || {};
            options.headers = Object.assign({}, options.headers, {
                'Authorization': 'Bearer ' + token
            });
        }
        return originalFetch.call(this, url, options);
    };
})();

Auth UI — dynamically adds a login or logout button to the menu bar, and shows the user's email when logged in:

(function renderAuthUI() {
    document.addEventListener('DOMContentLoaded', function() {
        var menuBar = document.querySelector('.menu-bar');
        if (!menuBar) return;

        var token = getToken();
        var el = document.createElement('div');
        el.className = 'menu-separator';
        menuBar.appendChild(el);

        if (token) {
            try {
                var payload = JSON.parse(atob(token.split('.')[1]));
                var userEl = document.createElement('span');
                userEl.className = 'menu-item';
                userEl.style.cursor = 'default';
                userEl.innerHTML = '<span class="menu-icon">👤</span><span class="menu-label">' +
                    (payload.email || 'User') + '</span>';
                menuBar.appendChild(userEl);
            } catch(e) {}

            var logoutEl = document.createElement('a');
            logoutEl.href = '#';
            logoutEl.className = 'menu-item';
            logoutEl.innerHTML = '<span class="menu-icon">🚪</span><span class="menu-label">Logout</span>';
            logoutEl.onclick = function(e) { e.preventDefault(); remoneyLogout(); };
            menuBar.appendChild(logoutEl);
        } else {
            var loginEl = document.createElement('a');
            loginEl.href = '#';
            loginEl.className = 'menu-item';
            loginEl.innerHTML = '<span class="menu-icon">🔐</span><span class="menu-label">Sign in with Google</span>';
            loginEl.onclick = function(e) { e.preventDefault(); remoneyLogin(); };
            menuBar.appendChild(loginEl);
        }
    });
})();

Include it in every Qute template:

<script src="/js/auth.js"></script>

Step 5: Server-Side Auth Check in ExpenseUIResource

Here's the problem with server-rendered pages: when a user navigates to /ui, the browser makes a plain GET request. There's no Authorization header, no way for API Gateway to validate a JWT. That's why /ui/* routes are set to Authorizer: NONE.

But we can't leave them completely unprotected. The solution: check for the id_token cookie that auth.js sets after login. If it's missing, redirect to Cognito.

We also need a callback endpoint — a minimal page with no auth check that loads auth.js so it can capture the token from the URL fragment:

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

    private static final String COGNITO_DOMAIN = "remoney-auth.auth.us-east-1.amazoncognito.com";
    private static final String CLIENT_ID = "YOUR_COGNITO_CLIENT_ID";
    private static final String IDP = "Google";

    @CookieParam("id_token")
    String idToken;

    private Response requireAuth() {
        if (idToken != null && !idToken.isEmpty()) {
            return null; // authenticated
        }
        String redirectUri = "https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback";
        String loginUrl = "https://" + COGNITO_DOMAIN
                + "/oauth2/authorize?response_type=token&client_id=" + CLIENT_ID
                + "&redirect_uri=" + java.net.URLEncoder.encode(
                    redirectUri, java.nio.charset.StandardCharsets.UTF_8)
                + "&scope=openid+email+profile&identity_provider=" + IDP;
        return Response.seeOther(URI.create(loginUrl)).build();
    }

    // OAuth callback — no auth check, just loads auth.js
    @GET
    @Path("/callback")
    @Produces(MediaType.TEXT_HTML)
    public String authCallback() {
        return "<!DOCTYPE html><html><head><meta charset=\"UTF-8\">"
             + "<title>Signing in...</title></head>"
             + "<body><p>Signing in...</p>"
             + "<script src=\"/js/auth.js\"></script></body></html>";
    }

    @GET
    @Produces(MediaType.TEXT_HTML)
    public Object getDashboard(/* ... params ... */) throws Exception {
        Response authRedirect = requireAuth();
        if (authRedirect != null) return authRedirect;

        // ... render dashboard as before ...
    }

    // Same pattern for all other GET endpoints:
    // getCategories(), getAccounts(), getPivotTable(), getCsvImport(), getSetup()
}

Key details:

@CookieParam("id_token") reads the cookie set by auth.js
Return type changes from TemplateInstance to Object so we can return either a template or a redirect Response
requireAuth() returns null if authenticated, or a redirect Response to Cognito login
The redirect_uri points to /ui/callback — not /ui — to avoid the redirect loop
The /ui/callback endpoint has no auth check — it's a bare HTML page that loads auth.js

Why not use uriInfo.getBaseUri()? Inside Lambda behind API Gateway, getBaseUri() returns an internal URL (like http://localhost/), not the actual API Gateway domain. You need to hardcode the API Gateway URL or pass it via an environment variable.

Step 6: The Complete Auth Flow

Here's what happens end-to-end:

1. User opens https://YOUR-API.execute-api.us-east-1.amazonaws.com/ui

2. API Gateway: /ui route has Auth: NONE → passes through to Lambda

3. Lambda (ExpenseUIResource.getDashboard): checks for id_token cookie
   → NOT FOUND → Returns 303 redirect to Cognito

4. Browser redirects to:
   https://remoney-auth.auth.us-east-1.amazoncognito.com/oauth2/authorize?
     response_type=token&client_id=...
     &redirect_uri=.../ui/callback    ← note: /ui/callback, not /ui
     &identity_provider=Google

5. Cognito redirects to Google sign-in

6. User signs in with Google → Google redirects back to Cognito

7. Cognito redirects back to:
   https://YOUR-API.execute-api.us-east-1.amazonaws.com/ui/callback#id_token=eyJ...

8. API Gateway: /ui/callback matches /ui/{proxy+} with Auth: NONE → Lambda

9. Lambda (ExpenseUIResource.authCallback): returns minimal HTML page
   → No auth check — just loads auth.js

10. auth.js runs on the callback page:
    - Parses id_token from URL fragment
    - Stores in localStorage + sets id_token cookie
    - Redirects to /ui

11. Browser navigates to /ui → sends cookie with request

12. Lambda (ExpenseUIResource.getDashboard): checks for id_token cookie
    → FOUND → Renders the dashboard

13. Any fetch() call to /entryResource/* includes Authorization: Bearer header
    → API Gateway validates JWT → Lambda processes request

The callback page is the key piece. It breaks the redirect loop by giving JavaScript a place to run before the server-side auth check kicks in.

Step 7: Deploy

First deploy (with Google credentials):

./build-lambda.sh
sam deploy --parameter-overrides \
    GoogleClientId=your-google-client-id \
    GoogleClientSecret=your-google-client-secret

After the first deploy, note the API Gateway URL from the outputs and update the CallbackURLs in template.yaml to use /ui/callback. Then deploy again:

sam build && sam deploy

For subsequent deploys, SAM remembers the parameters:

./build-lambda.sh && sam deploy

Step 8: Test the Flow

Open your API Gateway URL + /ui
You should be redirected to Google sign-in
Sign in with your Google account
You'll briefly see "Signing in..." on the callback page
You're redirected to re:Money with the dashboard loaded
Check the menu bar — you should see your email and a Logout button
Open browser DevTools → Application → Cookies → verify id_token is set
Open Network tab → verify Authorization: Bearer ... on fetch calls to /entryResource/*

What Changed from Part 1

Before (Part 1)	After (Security Part)
Public API Gateway	JWT-protected API routes
No authentication	Google sign-in via Cognito
Anyone can access data	Cookie check on UI, JWT check on API
No user identity	JWT carries user email
`sam deploy`	`sam deploy --parameter-overrides` (first time)

And what didn't change:

Still two commands to deploy
Still zero servers to manage
Still a single function.zip artifact
Still pay-per-request pricing
No VPC, no security groups, no network config
No new Java dependencies — just @CookieParam and Response.seeOther()

Cost Impact

Service	Cost
Cognito	Free tier: 50,000 MAU (monthly active users)
API Gateway	Same as before — free tier covers it
Lambda	Same as before
DynamoDB	Same as before
Total	Still ~$0/month for personal use

Gotchas We Hit

A few things that tripped us up during implementation:

Redirect loop on /ui — This was the biggest one. Cognito's implicit flow returns the token in the URL fragment (#id_token=...). Fragments are client-side only — the server never sees them. If Cognito redirects back to /ui, the server checks for a cookie, finds nothing, and redirects back to Cognito. Infinite loop. The fix: use a dedicated /ui/callback endpoint that serves a bare HTML page (no auth check) where auth.js can capture the token, set the cookie, and then redirect to /ui.
Circular dependency in CloudFormation — You can't use !Sub "${ReMoneyHttpApi}" in the UserPoolClient's CallbackURLs because the API references the client (for its authorizer) and the client would reference the API. Solution: use https://localhost/ui/callback for the first deploy, then hardcode the actual API Gateway URL after you get it from the stack outputs.
redirect_mismatch error — The redirect_uri in the login request must exactly match one of the CallbackURLs registered in Cognito — character for character. Inside Lambda, uriInfo.getBaseUri() returns an internal URL, not the API Gateway domain. Solution: hardcode the API Gateway URL in the Java resource.
Cookies need Secure flag — API Gateway endpoints are HTTPS, so the cookie must have Secure to be sent back. SameSite=Lax allows the cookie to be sent on top-level navigations (which is what we need for page loads).
build-lambda.sh artifact name — If your Maven artifactId changes, the zip script breaks. Make sure the jar name in the script matches what Maven produces.

What's Next

Your app is now deployed and secured. In the next parts of this series, we could cover:

Custom domain — putting re:Money behind money.yourdomain.com with Route 53 + ACM
Multi-tenancy — using the Cognito user ID to isolate data per user in DynamoDB
CI/CD — automating ./build-lambda.sh && sam deploy with GitHub Actions
Restricting access — adding a Cognito Pre-Sign-Up Lambda trigger to allow only specific email addresses

But for now, you've gone from "anyone can see my bank transactions" to "Google sign-in required" — with auth handled at two layers: API Gateway for REST calls, and a simple cookie check for server-rendered pages. No new dependencies, no auth framework, just Cognito + a cookie + a callback page + 10 lines of Java.

This is Part 2 of the "Goodbye Localhost, Hello AWS" series. Part 1 covers the initial deployment. re:Money is open source as part of the Renascence Computing Project.

Goodbye localhost, hello AWS: adding security to re:Money

Vinicius Senger — Tue, 14 Apr 2026 18:55:30 +0000

In the first part of this series, we took re:Money from localhost to production with sam build && sam deploy. Two commands, zero servers, and a fully working financial tracking app on AWS Lambda.

But there's a problem: anyone with the URL can see your data.

That API Gateway endpoint we got? It's public. No login, no authentication, no authorization. For a personal finance app, that's not acceptable. Time to fix it.

In this article, we'll add Amazon Cognito with Google sign-in to re:Money — so only you (or people you invite) can access the app.

What We're Building

┌──────────┐     ┌──────────────┐     ┌─────────────┐     ┌────────┐     ┌──────────┐
│  Browser │────▶│ Google Login │────▶│   Cognito   │────▶│  JWT   │     │          │
│          │     │  (OAuth 2.0) │     │  User Pool  │     │ Token  │     │          │
└──────────┘     └──────────────┘     └─────────────┘     └───┬────┘     │          │
                                                              │          │          │
                                                              ▼          │          │
                                                        ┌───────────┐    │          │
                                                        │    API    │──▶ │ Lambda   │──▶ DynamoDB
                                                        │  Gateway  │    │(Quarkus) │
                                                        │ (JWT Auth)│    │          │
                                                        └───────────┘    └──────────┘

We protect re:Money at two layers:

API Gateway JWT authorizer — REST API routes (/entryResource/*, /csv-import/*) require a valid Cognito JWT in the Authorization header. No token? 401 before Lambda even wakes up.
Server-side cookie check — The Qute-rendered UI pages (/ui/*) are public at the gateway level (they have to be — browsers don't send Authorization headers on page navigation). Instead, the Java resource checks for an id_token cookie and redirects to Cognito login if it's missing.

The glue between these two layers is a small JavaScript file (auth.js) that stores the Cognito token in both localStorage (for fetch() calls) and a cookie (for server-side checks).

Step 1: Get Google OAuth Credentials

Before touching AWS, you need a Google OAuth client:

Go to Google Cloud Console → Credentials
Create a new project (or use an existing one)
Click Create Credentials → OAuth 2.0 Client ID
Application type: Web application
Leave the redirect URI blank for now — we'll come back after creating the Cognito domain
Save your Client ID and Client Secret

Step 2: Update template.yaml

Here's the full picture. We add Cognito resources, a JWT authorizer on API Gateway, and split routes into protected (API) and public (UI):

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

Parameters:
  GoogleClientId:
    Type: String
    Description: Google OAuth Client ID
    NoEcho: true
  GoogleClientSecret:
    Type: String
    Description: Google OAuth Client Secret
    NoEcho: true

Globals:
  Function:
    Timeout: 30
    MemorySize: 512
    Runtime: java21
    Environment:
      Variables:
        QUARKUS_PROFILE: prod

Resources:
  # --- Cognito ---
  ReMoneyUserPool:
    Type: AWS::Cognito::UserPool
    Properties:
      UserPoolName: remoney-users
      AutoVerifiedAttributes:
        - email
      Schema:
        - Name: email
          Required: true
          Mutable: true

  ReMoneyUserPoolDomain:
    Type: AWS::Cognito::UserPoolDomain
    Properties:
      Domain: remoney-auth  # Must be globally unique
      UserPoolId: !Ref ReMoneyUserPool

  GoogleIdentityProvider:
    Type: AWS::Cognito::UserPoolIdentityProvider
    Properties:
      UserPoolId: !Ref ReMoneyUserPool
      ProviderName: Google
      ProviderType: Google
      ProviderDetails:
        client_id: !Ref GoogleClientId
        client_secret: !Ref GoogleClientSecret
        authorize_scopes: "openid email profile"
      AttributeMapping:
        email: email
        name: name
        username: sub

  ReMoneyUserPoolClient:
    Type: AWS::Cognito::UserPoolClient
    DependsOn: GoogleIdentityProvider
    Properties:
      ClientName: remoney-web
      UserPoolId: !Ref ReMoneyUserPool
      GenerateSecret: false
      SupportedIdentityProviders:
        - Google
      AllowedOAuthFlows:
        - implicit
      AllowedOAuthScopes:
        - openid
        - email
        - profile
      AllowedOAuthFlowsUserPoolClient: true
      CallbackURLs:
        - https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback
        - https://localhost/ui/callback
      LogoutURLs:
        - https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback
        - https://localhost/ui/callback

Note on CallbackURLs: You can't use !Sub "${ReMoneyHttpApi}" here because it creates a circular dependency — the API references the UserPoolClient for its authorizer, and the client would reference the API for its callback URL. Use https://localhost/ui/callback for the first deploy, then update with the actual API Gateway URL from the stack outputs.

Why /ui/callback and not /ui? This is critical. Cognito's implicit flow returns the token in the URL fragment (#id_token=...). Fragments are client-side only — the server never sees them. If Cognito redirects to /ui, the server-side auth check sees no cookie, and redirects back to Cognito — an infinite loop. The /ui/callback endpoint serves a minimal page with no auth check, giving JavaScript a chance to capture the token and set the cookie before navigating to /ui.

Next, the API Gateway with a JWT authorizer:

  # --- API Gateway with JWT Auth ---
  ReMoneyHttpApi:
    Type: AWS::Serverless::HttpApi
    Properties:
      Auth:
        DefaultAuthorizer: CognitoAuthorizer
        Authorizers:
          CognitoAuthorizer:
            AuthorizationScopes:
              - openid
            IdentitySource: $request.header.Authorization
            JwtConfiguration:
              issuer: !Sub "https://cognito-idp.${AWS::Region}.amazonaws.com/${ReMoneyUserPool}"
              audience:
                - !Ref ReMoneyUserPoolClient

And the Lambda function with split routes — protected API vs public UI:

  # --- Lambda ---
  ReMoneyFunction:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: target/function.zip
      Handler: io.quarkus.amazon.lambda.runtime.QuarkusStreamHandler::handleRequest
      MemorySize: 1024
      Events:
        # Protected API routes (JWT required)
        EntryApi:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /entryResource/{proxy+}
            Method: ANY
        CsvImportApi:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /csv-import/{proxy+}
            Method: ANY
        # Public UI routes (no gateway auth — server checks cookie)
        PublicUI:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /ui/{proxy+}
            Method: ANY
            Auth:
              Authorizer: NONE
        PublicUIRoot:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /ui
            Method: ANY
            Auth:
              Authorizer: NONE
        # Static assets
        PublicCss:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /css/{proxy+}
            Method: GET
            Auth:
              Authorizer: NONE
        PublicJs:
          Type: HttpApi
          Properties:
            ApiId: !Ref ReMoneyHttpApi
            Path: /js/{proxy+}
            Method: GET
            Auth:
              Authorizer: NONE

Step 3: Update the Google Redirect URI

After the first deploy, go back to Google Cloud Console and add the Cognito redirect URI:

https://remoney-auth.auth.us-east-1.amazoncognito.com/oauth2/idpresponse

Replace remoney-auth with your domain and us-east-1 with your region.

Step 4: The Auth JavaScript — auth.js

This is the client-side glue. It handles the Cognito OAuth callback, stores the token, and bridges the gap between browser navigation and API calls.

Create src/main/resources/META-INF/resources/js/auth.js:

// re:Money Auth - Cognito + Google sign-in
const AUTH_CONFIG = {
    cognitoDomain: 'remoney-auth.auth.us-east-1.amazoncognito.com',
    clientId: 'YOUR_COGNITO_CLIENT_ID',  // From SAM outputs
    redirectUri: window.location.origin + '/ui/callback',
    provider: 'Google'
};

function remoneyLogin() {
    window.location.href =
        'https://' + AUTH_CONFIG.cognitoDomain + '/oauth2/authorize?' +
        'response_type=token&client_id=' + AUTH_CONFIG.clientId +
        '&redirect_uri=' + encodeURIComponent(AUTH_CONFIG.redirectUri) +
        '&scope=openid+email+profile&identity_provider=' + AUTH_CONFIG.provider;
}

Note the redirectUri points to /ui/callback, not /ui. This is essential to avoid the redirect loop (more on that in the Gotchas section).

Cookie management — this is what makes server-side auth work. After Cognito redirects back with a token in the URL fragment, we store it in both localStorage and a cookie:

function setAuthCookie(token, maxAgeSec) {
    document.cookie = 'id_token=' + token +
        ';path=/;max-age=' + maxAgeSec + ';SameSite=Lax;Secure';
}

function clearAuthCookie() {
    document.cookie = 'id_token=;path=/;max-age=0';
}

function remoneyLogout() {
    localStorage.removeItem('id_token');
    localStorage.removeItem('token_expiry');
    clearAuthCookie();
    window.location.href =
        'https://' + AUTH_CONFIG.cognitoDomain + '/logout?' +
        'client_id=' + AUTH_CONFIG.clientId +
        '&logout_uri=' + encodeURIComponent(AUTH_CONFIG.redirectUri);
}

function getToken() {
    var expiry = localStorage.getItem('token_expiry');
    if (expiry && Date.now() > parseInt(expiry)) {
        localStorage.removeItem('id_token');
        localStorage.removeItem('token_expiry');
        clearAuthCookie();
        return null;
    }
    return localStorage.getItem('id_token');
}

Token capture and redirect — Cognito uses the implicit flow, which puts the token in the URL fragment (#id_token=...). We parse it on the callback page and redirect to the main UI:

(function handleCallback() {
    var hash = window.location.hash.substring(1);
    if (!hash) return;
    var params = new URLSearchParams(hash);
    var token = params.get('id_token');
    var expiresIn = params.get('expires_in');
    if (token) {
        var ttl = expiresIn ? parseInt(expiresIn) : 3600;
        localStorage.setItem('id_token', token);
        localStorage.setItem('token_expiry', String(Date.now() + ttl * 1000));
        setAuthCookie(token, ttl);
        // Redirect to the main UI now that cookie is set
        window.location.href = window.location.origin + '/ui';
        return;
    }
})();

Fetch interceptor — patches window.fetch so every AJAX call includes the Authorization header. This is what protects the /entryResource/* API calls made from the UI:

(function patchFetch() {
    var originalFetch = window.fetch;
    window.fetch = function(url, options) {
        var token = getToken();
        if (token) {
            options = options || {};
            options.headers = Object.assign({}, options.headers, {
                'Authorization': 'Bearer ' + token
            });
        }
        return originalFetch.call(this, url, options);
    };
})();

Auth UI — dynamically adds a login or logout button to the menu bar, and shows the user's email when logged in:

(function renderAuthUI() {
    document.addEventListener('DOMContentLoaded', function() {
        var menuBar = document.querySelector('.menu-bar');
        if (!menuBar) return;

        var token = getToken();
        var el = document.createElement('div');
        el.className = 'menu-separator';
        menuBar.appendChild(el);

        if (token) {
            try {
                var payload = JSON.parse(atob(token.split('.')[1]));
                var userEl = document.createElement('span');
                userEl.className = 'menu-item';
                userEl.style.cursor = 'default';
                userEl.innerHTML = '<span class="menu-icon">👤</span><span class="menu-label">' +
                    (payload.email || 'User') + '</span>';
                menuBar.appendChild(userEl);
            } catch(e) {}

            var logoutEl = document.createElement('a');
            logoutEl.href = '#';
            logoutEl.className = 'menu-item';
            logoutEl.innerHTML = '<span class="menu-icon">🚪</span><span class="menu-label">Logout</span>';
            logoutEl.onclick = function(e) { e.preventDefault(); remoneyLogout(); };
            menuBar.appendChild(logoutEl);
        } else {
            var loginEl = document.createElement('a');
            loginEl.href = '#';
            loginEl.className = 'menu-item';
            loginEl.innerHTML = '<span class="menu-icon">🔐</span><span class="menu-label">Sign in with Google</span>';
            loginEl.onclick = function(e) { e.preventDefault(); remoneyLogin(); };
            menuBar.appendChild(loginEl);
        }
    });
})();

Include it in every Qute template:

<script src="/js/auth.js"></script>

Step 5: Server-Side Auth Check in ExpenseUIResource

But we can't leave them completely unprotected. The solution: check for the id_token cookie that auth.js sets after login. If it's missing, redirect to Cognito.

We also need a callback endpoint — a minimal page with no auth check that loads auth.js so it can capture the token from the URL fragment:

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

    private static final String COGNITO_DOMAIN = "remoney-auth.auth.us-east-1.amazoncognito.com";
    private static final String CLIENT_ID = "YOUR_COGNITO_CLIENT_ID";
    private static final String IDP = "Google";

    @CookieParam("id_token")
    String idToken;

    private Response requireAuth() {
        if (idToken != null && !idToken.isEmpty()) {
            return null; // authenticated
        }
        String redirectUri = "https://YOUR-API-ID.execute-api.us-east-1.amazonaws.com/ui/callback";
        String loginUrl = "https://" + COGNITO_DOMAIN
                + "/oauth2/authorize?response_type=token&client_id=" + CLIENT_ID
                + "&redirect_uri=" + java.net.URLEncoder.encode(
                    redirectUri, java.nio.charset.StandardCharsets.UTF_8)
                + "&scope=openid+email+profile&identity_provider=" + IDP;
        return Response.seeOther(URI.create(loginUrl)).build();
    }

    // OAuth callback — no auth check, just loads auth.js
    @GET
    @Path("/callback")
    @Produces(MediaType.TEXT_HTML)
    public String authCallback() {
        return "<!DOCTYPE html><html><head><meta charset=\"UTF-8\">"
             + "<title>Signing in...</title></head>"
             + "<body><p>Signing in...</p>"
             + "<script src=\"/js/auth.js\"></script></body></html>";
    }

    @GET
    @Produces(MediaType.TEXT_HTML)
    public Object getDashboard(/* ... params ... */) throws Exception {
        Response authRedirect = requireAuth();
        if (authRedirect != null) return authRedirect;

        // ... render dashboard as before ...
    }

    // Same pattern for all other GET endpoints:
    // getCategories(), getAccounts(), getPivotTable(), getCsvImport(), getSetup()
}

Key details:

@CookieParam("id_token") reads the cookie set by auth.js
Return type changes from TemplateInstance to Object so we can return either a template or a redirect Response
requireAuth() returns null if authenticated, or a redirect Response to Cognito login
The redirect_uri points to /ui/callback — not /ui — to avoid the redirect loop
The /ui/callback endpoint has no auth check — it's a bare HTML page that loads auth.js

Why not use uriInfo.getBaseUri()? Inside Lambda behind API Gateway, getBaseUri() returns an internal URL (like http://localhost/), not the actual API Gateway domain. You need to hardcode the API Gateway URL or pass it via an environment variable.

Step 6: The Complete Auth Flow

Here's what happens end-to-end:

1. User opens https://YOUR-API.execute-api.us-east-1.amazonaws.com/ui

2. API Gateway: /ui route has Auth: NONE → passes through to Lambda

3. Lambda (ExpenseUIResource.getDashboard): checks for id_token cookie
   → NOT FOUND → Returns 303 redirect to Cognito

4. Browser redirects to:
   https://remoney-auth.auth.us-east-1.amazoncognito.com/oauth2/authorize?
     response_type=token&client_id=...
     &redirect_uri=.../ui/callback    ← note: /ui/callback, not /ui
     &identity_provider=Google

5. Cognito redirects to Google sign-in

6. User signs in with Google → Google redirects back to Cognito

7. Cognito redirects back to:
   https://YOUR-API.execute-api.us-east-1.amazonaws.com/ui/callback#id_token=eyJ...

8. API Gateway: /ui/callback matches /ui/{proxy+} with Auth: NONE → Lambda

9. Lambda (ExpenseUIResource.authCallback): returns minimal HTML page
   → No auth check — just loads auth.js

10. auth.js runs on the callback page:
    - Parses id_token from URL fragment
    - Stores in localStorage + sets id_token cookie
    - Redirects to /ui

11. Browser navigates to /ui → sends cookie with request

12. Lambda (ExpenseUIResource.getDashboard): checks for id_token cookie
    → FOUND → Renders the dashboard

13. Any fetch() call to /entryResource/* includes Authorization: Bearer header
    → API Gateway validates JWT → Lambda processes request

The callback page is the key piece. It breaks the redirect loop by giving JavaScript a place to run before the server-side auth check kicks in.

Step 7: Deploy

First deploy (with Google credentials):

./build-lambda.sh
sam deploy --parameter-overrides \
    GoogleClientId=your-google-client-id \
    GoogleClientSecret=your-google-client-secret

After the first deploy, note the API Gateway URL from the outputs and update the CallbackURLs in template.yaml to use /ui/callback. Then deploy again:

sam build && sam deploy

For subsequent deploys, SAM remembers the parameters:

./build-lambda.sh && sam deploy

Step 8: Test the Flow

Open your API Gateway URL + /ui
You should be redirected to Google sign-in
Sign in with your Google account
You'll briefly see "Signing in..." on the callback page
You're redirected to re:Money with the dashboard loaded
Check the menu bar — you should see your email and a Logout button
Open browser DevTools → Application → Cookies → verify id_token is set
Open Network tab → verify Authorization: Bearer ... on fetch calls to /entryResource/*

What Changed from Part 1

Before (Part 1)	After (Security Part)
Public API Gateway	JWT-protected API routes
No authentication	Google sign-in via Cognito
Anyone can access data	Cookie check on UI, JWT check on API
No user identity	JWT carries user email
`sam deploy`	`sam deploy --parameter-overrides` (first time)

And what didn't change:

Still two commands to deploy
Still zero servers to manage
Still a single function.zip artifact
Still pay-per-request pricing
No VPC, no security groups, no network config
No new Java dependencies — just @CookieParam and Response.seeOther()

Cost Impact

Service	Cost
Cognito	Free tier: 50,000 MAU (monthly active users)
API Gateway	Same as before — free tier covers it
Lambda	Same as before
DynamoDB	Same as before
Total	Still ~$0/month for personal use

Gotchas We Hit

A few things that tripped us up during implementation:

Redirect loop on /ui — This was the biggest one. Cognito's implicit flow returns the token in the URL fragment (#id_token=...). Fragments are client-side only — the server never sees them. If Cognito redirects back to /ui, the server checks for a cookie, finds nothing, and redirects back to Cognito. Infinite loop. The fix: use a dedicated /ui/callback endpoint that serves a bare HTML page (no auth check) where auth.js can capture the token, set the cookie, and then redirect to /ui.
Circular dependency in CloudFormation — You can't use !Sub "${ReMoneyHttpApi}" in the UserPoolClient's CallbackURLs because the API references the client (for its authorizer) and the client would reference the API. Solution: use https://localhost/ui/callback for the first deploy, then hardcode the actual API Gateway URL after you get it from the stack outputs.
redirect_mismatch error — The redirect_uri in the login request must exactly match one of the CallbackURLs registered in Cognito — character for character. Inside Lambda, uriInfo.getBaseUri() returns an internal URL, not the API Gateway domain. Solution: hardcode the API Gateway URL in the Java resource.
Cookies need Secure flag — API Gateway endpoints are HTTPS, so the cookie must have Secure to be sent back. SameSite=Lax allows the cookie to be sent on top-level navigations (which is what we need for page loads).
build-lambda.sh artifact name — If your Maven artifactId changes, the zip script breaks. Make sure the jar name in the script matches what Maven produces.

What's Next

Your app is now deployed and secured. In the next parts of this series, we could cover:

Custom domain — putting re:Money behind money.yourdomain.com with Route 53 + ACM
Multi-tenancy — using the Cognito user ID to isolate data per user in DynamoDB
CI/CD — automating ./build-lambda.sh && sam deploy with GitHub Actions
Restricting access — adding a Cognito Pre-Sign-Up Lambda trigger to allow only specific email addresses

This is Part 2 of the "Goodbye Localhost, Hello AWS" series. Part 1 covers the initial deployment. re:Money is open source as part of the Renascence Computing Project.

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