Como eu "Vibecodei" um Backend (e Frontend) no InterSystems IRIS

Eu queria testar o **vibecoding** em uma configuração real de backend + frontend no InterSystems IRIS, idealmente usando algo realista em vez de um exemplo de brinquedo. O objetivo era simples: pegar um pacote persistente existente e bem conhecido no IRIS e construir rapidamente uma interface de usuário (UI) e uma API utilizáveis ao redor dele — deixando a IA cuidar do máximo possível de código repetitivo (boilerplate). Aqui está o resultado dos experimentos.

Escolhendo o Modelo de Dados

Para este experimento, escolhi o Samples BI Demo. Ele é ótimo para vibecoding pois:

• Contém diversas classes persistentes bem projetadas
• É amplamente conhecido e fácil de instalar
• Já funciona perfeitamente com o IRIS BI

A instalação é trivial usando o IPM:

zpm "install samples-bi-demo"

Uma vez instalado, verifiquei se tudo funcionava corretamente no IRIS BI. Para conveniência e uma melhor experiência de navegação, também instalei o DSW (DeepSee Web) e me certifiquei de que os dados estavam lá e tudo funcionava perfeitamente — aqui está a captura de tela dos dados instalados visualizados pelo DSW:

O Samples BI Demo mostra as vendas de uma empresa imaginária chamada HoleFoods, que produz e vende produtos com "furos" (Holes). A configuração acompanha o pacote HoleFoods de classes persistentes:

• Product (Produto)
• Outlet (Ponto de Venda)
• Country (País)
• Region (Região)
• Transaction (Transação)

Um par perfeito para uma demonstração de CRUD.

Configuração do Vibecoding

Aqui está a minha configuração de "vibecoding com IRIS":

• VS Code
  • Extensão InterSystems ObjectScript
  • Plugin OpenAI Codex
• Docker
• Umtemplate de projeto ObjectScript muito básico do Open Exchange

É isso. Sem estruturas pesadas ou frameworks customizados.

A Receita da UI

A arquitetura que segui é direta e repetível:

1. Uma interface de usuário (UI) frontend
2. Comunicando-se com o IRIS através de uma API REST
3. Definida por uma especificação Swagger (OpenAPI)
4. Implementada nativamente em InterSystems IRIS ObjectScript e IRIS SQL.

Gerando a API Swagger

Nesta abordagem, a especificação OpenAPI ou Swagger é o intermediário que tanto o frontend quanto o IRIS entendem. O IRIS 2025.3 suporta Swagger / OpenAPI 2.0, então pedi ao Codex para gerar uma API de estilo CRUD para uma das classes persistentes — começando por Product. Para facilitar para a IA, exportei o código-fonte das classes persistentes da minha instância local do IRIS e as compartilhei com o Codex.

Decidi começar com um requisito simples:

Uma página para criar, editar, listar e excluir Produtos (Products)

Para suportar isso, pedi ao Codex para:

• Gerar uma definição Swagger em spec.cls
• Fazer a classe Product herdar de %JSON.Adaptor
• Seguir as convenções e preferências descritas no meu arquivo AGENTS.md
  (basicamente a "sabedoria" acumulada de interações anteriores)

Também escolhi um caminho base para a API:

/holefoods/api

O Codex gerou a classe:

Holefoods.api.specApós compilá-la, o IRIS produziu automaticamente duas classes adicionais:

• Holefoods.api.disp
  Sempre gerada pelo IRIS e responsável pelo roteamento dos endpoints e pela infraestrutura de requisição/resposta.
• Holefoods.api.impl
  Onde a lógica de negócio real reside — inicialmente ela vem apenas com os esqueletos (stubs) dos métodos.

Este é um daqueles recursos do IRIS que parece quase mágico quando combinado com o vibecoding. Sendo atencioso (ou talvez cauteloso 😄), o Codex perguntou:

• Se a aplicação web deveria ser registrada no module.xml
• Qual nome de classe de despacho (dispatch) deveria ser usado

Confirmei ambos — o que significa que a API é criada automaticamente quando o IRIS inicia — e ele adicionou a configuração da aplicação web no module.xml, para que a app apareça no IRIS na próxima reconstrução do docker ou carga manual do módulo:

<CSPApplicationUrl="/holefoods/api"DispatchClass="HoleFoods.api.disp"MatchRoles=":{$dbrole}"PasswordAuthEnabled="0"UnauthenticatedEnabled="1"Recurse="1"UseCookies="2"CookiePath="/holefoods/api/"CorsAllowlist="*"CorsCredentialsAllowed="1"CorsHeadersList="Content-Type,Authorization,Accept-Language,X-Requested-With,session"
/>

Configuração de Segurança

Qualquer pessoa que já trabalhou com o IRIS sabe que aplicações web + segurança às vezes podem ser... intensas. Então, pedi explicitamente ao Codex para gerar:

Holefoods.api.security.cls

seguindo as instruções no AGENTS.md.

Esta classe introduziu os ajustes de segurança necessários para permitir que a fase de desenvolvimento da API ocorresse sem problemas, mas também de forma clara e facilmente escalável para qualquer nível de segurança mais alto, focando principalmente em todas as relações de segurança com uma role especial atribuída à aplicação e, assim, projetada para todos os usuários logados nela.

Implementando a API

Próximo passo: implementação.

Pedi ao Codex para implementar totalmente a lógica CRUD dentro de:

Holefoods.api.impl E ele simplesmente fez. A essa altura, tudo estava pronto para testar.

Testando com Swagger UI

Para validar rapidamente a API, instalei o Swagger UI:

zpm "install swagger-ui"

Nota importante (aprendida da maneira difícil anteriormente):
O Swagger UI requer um endpoint _spec, que deve sempre ser implementado na classe impl. Uma vez configurado, o Swagger UI funciona perfeitamente.

Após reiniciar o IRIS, eu pude ver a definição completa da API exposta — e testá-la interativamente.

A requisição:

GET /holefoods/api/products

retornou dados significativos. Nesta fase, o backend estava essencialmente "pronto".

Vibecoding do Frontend

Com uma API funcional e uma especificação Swagger limpa, construir o frontend torna-se trivial. Você tem opções:

• Pedir ao Codex para gerar o frontend
• Usar ferramentas como o Lovable para criar o esqueleto (scaffold) de uma UI diretamente da especificação

Escolhi a última opção — e em minutos tinha uma UI local funcional conectada ao IRIS. Após alguns testes (e a correção de um pequeno problema na exclusão), a experiência completa estava lá: UI → API → IRIS → armazenamento persistente. Aqui está a captura de tela do primeiro resultado (pode ser visualizado localmente em http://localhost:5174/):

Adicionando Testes Unitários (Porque adultos fazem isso)

A última peça que faltava eram os testes unitários. Pedi ao Codex para gerar:

HoleFoods.api.Unittests.cls

cobrindo todos os endpoints definidos na especificação Swagger.

Uma vez gerada, adicionei a classe de teste à configuração do módulo para que os testes pudessem ser executados via IPM com esta linha:

<UnitTestName="/tests"Package="HoleFoods.api.tests"Phase="test"/>

assim, os testes podem ser chamados como:

zpm "test esh-vibe-back-demo" 

E pronto, todos os endpoints da API estavam cobertos e visíveis no portal de testes unitários do IRIS:

Mais tarde, pedi para adicionar o endpoint /transactions e o Codex introduziu o código na classe de especificação, construiu a implementação no impl e introduziu os testes unitários. E construiu uma UI cujo resultado você pode ver aqui:

Considerações Finais

InterSystems IRIS + Swagger + vibecoding parece ser uma combinação poderosa e eficaz.

Sim, o resultado é um protótipo — mas quase real e testável, construído de forma surpreendentemente rápida.

Aqui está o repositório.

Aproveitar o AGENTS.md e conduzir exemplos de código aberto com as melhores práticas ao lidar com o backend IRIS pode impulsionar o uso do IRIS como um backend robusto para aplicações full-stack abrangentes.

A capacidade de geração de código treinável do OpenAI Codex ou Claude Code abre a oportunidade de construir backends de altíssima performance no IRIS, já que a natureza de qualquer SQL no backend IRIS nada mais é do que geração de código sobre o percurso de globals.

P.S.

Este artigo foi escrito por um humano e revisado por IA para um melhor inglês (e português) :)

P.P.S.

E como faixa bônus — construí a UI no Lovable também — para que você possa brincar com a demonstração online: