DEV Community: Jackson Pires

🇺🇸 3 Essential Gems to Eliminate Friction in Your Rails Workflow

Jackson Pires — Thu, 04 Jun 2026 21:48:37 +0000

Anyone who works with Ruby on Rails knows that, despite the framework being incredible for productivity, there are some classic workflow deficiencies that haunt almost every project.

You are focused on writing code, but suddenly you need to open an external tool like Postman to test a route. Then, you run a complex script to generate a static database diagram. And at the end of the day, you still need to manually update the API documentation, which will inevitably become outdated in the next sprint.

This constant context switching and manual maintenance generates enormous friction. To cover these deficiencies, I developed three gems that bring these tools inside your application. They are so practical that they quickly become indispensable in any Rails project. Meet each one of them:

1. `rails-api-docs`: The End of Outdated Documentation]

https://github.com/jacksonpires/rails-api-docs

The deficiency: API documentation always starts with good intentions, but as the system evolves—new routes, parameters, and response fields—it quickly stops representing reality. Keeping this updated manually is repetitive and frustrating work.

The solution: The rails-api-docs gem solves this by leveraging what Rails already knows. It inspects your routes, controllers (via AST analysis using Prism), and the ActiveRecord schema to automatically generate the first draft of your documentation. Everything is saved in a single YAML file (config/rails-api-docs.yml), which serves as the single source of truth.

Why it is indispensable:

Append-only strategy: When adding new routes and running the generator, the gem only appends what's new. Your descriptions, custom examples, and tags are never modified or deleted, making the documentation a living document.
Zero development friction: You edit the YAML in one window and view the updated documentation in the browser at localhost:3000/rails/api-docs instantly, with no build step required. For production, it exports a single static HTML file without any external dependencies.

2. `rails-http-lab`: Your HTTP Client Right in the App

https://github.com/jacksonpires/rails-http-lab

The deficiency: Testing HTTP endpoints usually requires switching to external tools (like Postman or Insomnia) or creating temporary scripts. Besides the loss of focus, these tools live outside your repository and frequently suffer from CORS issues when trying to access internal services.

The solution: The rails-http-lab is a Rails Engine that couples an HTTP request lab inside your own application. By accessing /rails/http-lab, you have a lightweight interface to test methods, headers, and payloads while visualizing the responses directly in the browser.

Why it is indispensable:

Stays in the Repository: Your requests are saved in .bru format (interchangeable with the Bruno desktop app) inside the project's docs/http-lab/ folder. This means your API tests are version-controlled in Git and can be easily reviewed in Pull Requests.
No CORS limits: Since the requests are executed by the Rails server itself, you don't have CORS problems and can reach internal services transparently.

3. `rails-realtime-erd`: Database Diagrams Always in Sync

https://github.com/jacksonpires/rails-realtime-erd

The deficiency: Understanding database relationships in a growing project is difficult. Traditional tools generate static diagrams (ERD) that require manual tasks and quickly become outdated as soon as a new migration is executed.

The solution: The rails-realtime-erd gem mounts a route at /rails/erd that renders your schema diagram in real-time using Mermaid, all processed by Hotwire (Stimulus), without relying on complex JavaScript frameworks.

Why it is indispensable:
You will never again need to run a rake step to generate a static image file. The introspection is done on the fly: if you run a migration, just refresh the page to see the new tables and relationships reflected in the diagram immediately. It is excellent for onboarding new developers and keeping a live documentation of your architecture.

Conclusion

These three tools share the same philosophy: your code already has the necessary knowledge, and the support tools should live as close to it as possible.

Adopting rails-api-docs, rails-http-lab, and rails-realtime-erd drastically reduces daily friction, eliminating external dependencies and manual rework. With simple installation steps, your development environment will become much more productive, robust, and integrated.

🇧🇷 3 Gems Indispensáveis para Eliminar as Deficiências do seu Fluxo de Trabalho no Rails

Jackson Pires — Thu, 04 Jun 2026 21:47:50 +0000

Quem trabalha com Ruby on Rails sabe que, embora o framework seja incrível para a produtividade, existem algumas deficiências clássicas no fluxo de desenvolvimento que assombram quase todo projeto.

Você está focado escrevendo código, mas de repente precisa abrir uma ferramenta externa como o Postman para testar uma rota. Depois, roda um script complexo para gerar um diagrama estático do banco de dados. E, no fim do dia, ainda precisa atualizar manualmente a documentação da API, que fatalmente ficará defasada na próxima sprint.

Essa constante alternância de contexto e manutenção manual geram um enorme atrito. Para cobrir essas deficiências, eu desenvolvi três gems que trazem essas ferramentas para dentro da sua aplicação. Elas são tão práticas que rapidamente se tornam indispensáveis em qualquer projeto Rails. Conheça cada uma delas:

1. `rails-api-docs`: O Fim da Documentação Desatualizada

https://github.com/jacksonpires/rails-api-docs

A deficiência: A documentação de API sempre começa com boas intenções, mas conforme o sistema evolui — novas rotas, parâmetros e campos na resposta —, ela rapidamente deixa de representar a realidade. Manter isso atualizado manualmente é um trabalho repetitivo e frustrante.

A solução: A gem rails-api-docs resolve isso aproveitando o que o Rails já sabe. Ela inspeciona suas rotas, controllers (via análise AST usando Prism) e o schema do ActiveRecord para gerar automaticamente o primeiro rascunho da sua documentação. Tudo é salvo em um único arquivo YAML (config/rails-api-docs.yml), que serve como fonte da verdade.

Por que é indispensável:

Estratégia Append-only: Ao adicionar novas rotas e rodar o gerador, a gem apenas adiciona o que é novo. Suas descrições, exemplos customizados e tags não são apagados, tornando a documentação um documento vivo.
Zero atrito no desenvolvimento: Você edita o YAML de um lado e visualiza a documentação atualizada no navegador em localhost:3000/rails/api-docs instantaneamente, sem etapa de build. Para produção, ela exporta um único arquivo HTML estático, sem dependências externas.

2. `rails-http-lab`: Seu Client HTTP Direto na Aplicação

https://github.com/jacksonpires/rails-http-lab

A deficiência: Testar endpoints HTTP geralmente exige alternar para ferramentas externas (como Postman ou Insomnia) ou criar scripts temporários. Além da perda de foco, essas ferramentas vivem fora do seu repositório e frequentemente sofrem com problemas de CORS ao tentar acessar serviços internos.

A solução: O rails-http-lab é uma Rails Engine que acopla um laboratório de requisições HTTP dentro da sua própria aplicação. Ao acessar /rails/http-lab, você tem uma interface leve para testar métodos, headers e payloads visualizando as respostas diretamente no navegador.

Por que é indispensável:

Fica no Repositório: As suas requisições são salvas no formato .bru (compatível com o aplicativo desktop Bruno) dentro da pasta docs/http-lab/ do projeto. Isso significa que os testes da sua API são versionados no Git e podem ser revisados nos Pull Requests.
Sem limites de CORS: Como as requisições são executadas pelo próprio servidor Rails, você não tem problemas de CORS e pode alcançar serviços internos de forma transparente.

3. `rails-realtime-erd`: Diagramas de Banco de Dados Sempre Sincronizados

https://github.com/jacksonpires/rails-realtime-erd

A deficiência: Entender os relacionamentos do banco de dados em um projeto que está crescendo é difícil. As ferramentas tradicionais geram diagramas estáticos (ERD) que exigem tarefas manuais e rapidamente ficam defasados assim que uma nova migration é executada.

A solução: A gem rails-realtime-erd monta uma rota em /rails/erd que renderiza o diagrama do seu schema em tempo real usando o Mermaid, tudo processado pelo Hotwire (Stimulus), sem depender de frameworks JavaScript complexos.

Por que é indispensável:
Você nunca mais precisará rodar um passo de rake para gerar um arquivo de imagem estático. A introspecção é feita sob demanda: se você rodar uma migration, basta atualizar a página para ver as tabelas e relacionamentos novos refletidos no diagrama imediatamente. É excelente para o onboarding de novos desenvolvedores e documentação viva da arquitetura.

Conclusão

Essas três ferramentas compartilham a mesma filosofia: o seu código já possui o conhecimento necessário, e as ferramentas de apoio devem viver o mais próximo possível dele.

Adotar o rails-api-docs, o rails-http-lab e o rails-realtime-erd reduz drasticamente o atrito no dia a dia, eliminando dependências externas e o retrabalho manual. Com passos simples de instalação (basta adicionar ao Gemfile e rodar um comando), seu ambiente de desenvolvimento se tornará muito mais produtivo, robusto e integrado.

🇺🇸 I Got Tired of Stale API Documentation in Rails — So I Built `rails-api-docs`

Jackson Pires — Wed, 03 Jun 2026 12:25:33 +0000

API documentation always starts with good intentions.

At the beginning of a project, everything is in sync.

Routes match reality.

Examples are accurate.

Parameters make sense.

Responses reflect exactly what the API returns.

But as the system evolves, documentation starts falling behind.

A new route gets added.

A parameter changes.

An endpoint gains authentication.

A response receives new fields.

And before you realize it, the documentation no longer represents reality.

If you've worked with Rails APIs for long enough, you've probably experienced this.

I certainly have.

And it was exactly that frustration that led me to create rails-api-docs.

GitHub: https://github.com/jacksonpires/rails-api-docs

The idea started with a simple question

Your Rails application already knows a lot.

It knows:

your routes
your controllers
your parameters
your models
your database schema
your HTTP verbs

So why should documentation always start from scratch?

Why do we need to manually rewrite information that already exists inside the application?

The idea behind rails-api-docs was to leverage the knowledge Rails already has to generate the first draft of the documentation automatically.

The workflow I wanted didn't exist

I didn't want another tool where the workflow looked like this:

edit documentation
→ generate artifacts
→ rebuild
→ restart server
→ validate changes

I wanted something closer to the typical Rails development experience:

edit
→ refresh browser
→ keep working

That's where the core concept of the gem came from:

A single editable YAML file that powers both development-time documentation and production-ready documentation.

A single source of truth

The entire workflow revolves around a single file:

config/rails-api-docs.yml

This file becomes the source of truth for your documentation.

From it, the gem generates:

live documentation during development
request examples
response examples
documented schemas
static HTML documentation for production

You update one file.

Everything else updates automatically.

How it works

First, generate the initial YAML file:

rails g rails-api-docs:init

The gem automatically inspects:

Rails.application.routes
controllers (via Prism AST analysis)
ActiveRecord schema

And creates an initial documentation structure.

Then start your application:

rails server

And visit:

http://localhost:3000/rails/api-docs

Whenever you modify the YAML file, simply refresh the page.

No build step.

No frontend tooling.

No intermediate process.

Let the code write the first draft

One of the most interesting parts of this project was using Prism to analyze controllers.

For example:

params.require(:user).permit(
  :email,
  :password,
  :role
)

The gem can automatically identify these fields and use them to build the initial documentation structure.

Combined with ActiveRecord schema information, it can also infer:

field types
required attributes
initial examples
schema metadata

The goal was never to replace developers.

The goal was to eliminate repetitive work.

Let the machine handle what it can already discover.

And let humans focus on the important part: explaining the API.

Documentation updates shouldn't destroy your work

This is probably the feature that frustrated me most in existing approaches.

You generate documentation.

Spend time writing descriptions.

Add examples.

Organize sections.

Customize schemas.

Then you run the generator again.

And hope nothing gets overwritten.

rails-api-docs follows an append-only strategy.

When you add new routes to your application, simply run:

rails g rails-api-docs:update

The gem appends only new endpoints.

Everything you've written remains untouched.

That includes:

descriptions
examples
tags
authentication details
schemas
section organization

In practice, the documentation becomes a living document rather than a disposable artifact.

Organizing larger APIs with tags

As APIs grow, navigation becomes increasingly important.

That's why the gem supports tags:

tags:
  - auth
  - public

These tags aren't just labels.

They also become interactive filters in the generated documentation.

Clicking a tag instantly filters the navigation to show only endpoints associated with that category.

This makes large APIs significantly easier to explore.

Production should be simple

Another important goal was making deployment boring.

When you're ready to publish the documentation, simply run:

rake rails-api-docs:build

The result is:

public/api-docs.html

A single HTML file.

Everything embedded.

Inline CSS.

Inline JavaScript.

No external dependencies.

No CDN.

No Asset Pipeline.

No JavaScript runtime.

Just a static file that can be hosted almost anywhere.

I'm not trying to replace OpenAPI

There are excellent OpenAPI and Swagger-based tools available today.

They solve many problems extremely well.

The goal of rails-api-docs is not to replace that ecosystem.

The idea is different.

I wanted a solution that allows developers to:

generate documentation from an existing Rails application
edit everything in YAML
preview changes instantly
export a static HTML file
keep documentation synchronized with minimal effort

That's the workflow I was looking for.

And since I couldn't find exactly what I wanted, I decided to build it.

Final thoughts

API documentation should be easy to create and easy to maintain.

In my experience, generating the first version isn't the hard part.

Keeping it updated over time is.

rails-api-docs was created to reduce that friction.

By inspecting the application to generate a starting point.

By preserving your customizations over time.

And by providing an extremely fast feedback loop during development.

If you'd like to try it out:

⭐ https://github.com/jacksonpires/rails-api-docs

Feedback, suggestions, and contributions are always welcome.

🇧🇷 Eu Cansei de Documentação de API Desatualizada no Rails — Então Criei a Gem `rails-api-docs`

Jackson Pires — Wed, 03 Jun 2026 12:24:43 +0000

Documentação de API sempre começa com boas intenções.

No início do projeto, tudo está sincronizado.

As rotas batem com a aplicação.

Os exemplos estão corretos.

Os parâmetros fazem sentido.

As respostas refletem exatamente o que a API retorna.

Mas conforme o sistema evolui, a documentação começa a ficar para trás.

Uma nova rota é criada.

Um parâmetro muda.

Um endpoint ganha autenticação.

Uma resposta recebe novos campos.

E, sem perceber, a documentação deixa de representar a realidade.

Se você trabalha com APIs em Rails há algum tempo, provavelmente já passou por isso.

Eu certamente já passei.

E foi justamente essa frustração que me levou a criar o rails-api-docs.

GitHub: https://github.com/jacksonpires/rails-api-docs

A ideia surgiu de uma pergunta simples

Sua aplicação Rails já sabe muita coisa.

Ela conhece:

suas rotas
seus controllers
seus parâmetros
seus modelos
seu schema do banco
seus verbos HTTP

Então por que a documentação precisa começar sempre do zero?

Por que precisamos reescrever manualmente informações que já existem dentro da aplicação?

A ideia por trás do rails-api-docs foi justamente aproveitar esse conhecimento que o Rails já possui para gerar um primeiro rascunho da documentação automaticamente.

O workflow que eu queria não existia

Eu não queria mais uma ferramenta onde o fluxo fosse:

editar documentação
→ gerar artefatos
→ rebuild
→ reiniciar servidor
→ validar alterações

Eu queria algo mais próximo do desenvolvimento Rails tradicional:

editar
→ atualizar navegador
→ continuar trabalhando

Foi daí que surgiu o conceito central da gem:

Um único arquivo YAML editável que gera tanto a documentação em desenvolvimento quanto a documentação de produção.

Uma única fonte da verdade

O fluxo da gem gira em torno de apenas um arquivo:

config/rails-api-docs.yml

Esse arquivo é a fonte da verdade para toda a documentação.

A partir dele a gem gera:

visualização em tempo real durante o desenvolvimento
exemplos de requisição
exemplos de resposta
schemas documentados
documentação HTML estática para produção

Você altera um único lugar.

Todo o resto é atualizado automaticamente.

Como funciona

Primeiro você gera o YAML inicial:

rails g rails-api-docs:init

A gem inspeciona automaticamente:

Rails.application.routes
controllers (via análise AST usando Prism)
schema do ActiveRecord

E cria uma estrutura inicial de documentação.

Depois basta subir a aplicação:

rails server

E acessar:

http://localhost:3000/rails/api-docs

Sempre que você alterar o YAML, basta atualizar a página.

Não existe etapa de build durante o desenvolvimento.

Não existe pipeline frontend.

Não existe processo intermediário.

Deixe o código escrever o primeiro rascunho

Uma das partes mais interessantes do projeto foi utilizar o Prism para analisar controllers.

Por exemplo:

params.require(:user).permit(
  :email,
  :password,
  :role
)

A gem consegue identificar automaticamente esses campos e utilizá-los para montar a estrutura inicial da documentação.

Quando combinamos isso com as informações do ActiveRecord, também é possível inferir:

tipos dos campos
obrigatoriedade
exemplos iniciais
informações do schema

O objetivo nunca foi substituir o trabalho do desenvolvedor.

O objetivo foi eliminar tarefas repetitivas.

Deixar a máquina fazer aquilo que ela consegue descobrir sozinha.

E deixar os humanos cuidarem da parte importante: explicar a API.

Atualizações não deveriam apagar seu trabalho

Essa talvez seja a característica que mais me incomodava em algumas abordagens existentes.

Você gera documentação.

Investe tempo escrevendo descrições.

Adiciona exemplos.

Organiza seções.

Personaliza schemas.

Então roda novamente o gerador.

E precisa rezar para não perder nada.

No rails-api-docs o YAML segue uma estratégia append-only.

Quando você adiciona novas rotas à aplicação basta executar:

rails g rails-api-docs:update

A gem adiciona apenas os endpoints novos.

Todo o conteúdo que você escreveu continua intacto.

Isso inclui:

descrições
exemplos
tags
autenticação
schemas
organização das seções

Na prática, a documentação deixa de ser um artefato descartável e passa a ser um documento vivo.

Organizando APIs maiores com Tags

Conforme uma API cresce, navegar pela documentação pode ficar mais difícil.

Por isso a gem possui suporte a tags:

tags:
  - auth
  - public

Essas tags não são apenas informativas.

Elas também funcionam como filtros interativos na documentação gerada.

Ao clicar em uma tag, a navegação passa a exibir apenas os endpoints relacionados àquela categoria.

Isso facilita bastante a exploração de APIs maiores.

Produção deveria ser simples

Outro objetivo importante era simplificar o deploy da documentação.

Quando chega o momento de publicar, basta executar:

rake rails-api-docs:build

O resultado é:

public/api-docs.html

Um único arquivo HTML.

Tudo embutido.

CSS inline.

JavaScript inline.

Sem dependências externas.

Sem CDN.

Sem Asset Pipeline.

Sem runtime JavaScript.

Apenas um arquivo estático que pode ser hospedado praticamente em qualquer lugar.

Não estou tentando substituir OpenAPI

Existem excelentes ferramentas baseadas em OpenAPI e Swagger.

Elas resolvem muito bem diversos cenários.

O objetivo do rails-api-docs não é substituir esse ecossistema.

A proposta é diferente.

Eu queria uma solução que permitisse:

gerar documentação a partir de uma aplicação Rails existente
editar tudo em YAML
visualizar mudanças instantaneamente
exportar um HTML estático
manter a documentação sincronizada com pouco esforço

Era esse workflow que eu procurava.

E como não encontrei exatamente dessa forma, resolvi construir.

Considerações finais

Documentação de API deveria ser simples de criar e simples de manter.

Na minha experiência, o maior problema não é gerar a primeira versão.

O desafio é mantê-la atualizada ao longo do tempo.

O rails-api-docs nasceu justamente para reduzir esse atrito.

Inspecionando a aplicação para gerar um ponto de partida.

Preservando suas customizações ao longo do tempo.

E oferecendo um ciclo de feedback extremamente rápido durante o desenvolvimento.

Se quiser experimentar:

⭐ https://github.com/jacksonpires/rails-api-docs

Feedbacks, sugestões e contribuições são muito bem-vindos.

🇺🇸 Introducing Rails HTTP Lab: Test Your Rails Routes Directly Inside Your Application

Jackson Pires — Fri, 29 May 2026 17:57:35 +0000

When working with Ruby on Rails, testing HTTP endpoints is part of everyday development.

Most of the time, we rely on tools like Postman, Insomnia, curl, or even temporary scripts just to validate requests, headers, payloads, and responses.

But during development, I found myself asking:

What if I could test my Rails routes directly from inside the application itself?

That idea led me to create Rails HTTP Lab.

What is Rails HTTP Lab?

rails-http-lab is a Rails Engine that provides an embedded interface inside your Rails application to test HTTP requests against your own routes.

Think of it as a lightweight HTTP client focused on your Rails app.

With it, you can experiment with your endpoints without constantly switching between your editor, terminal, browser, and external API tools.

Features

Current capabilities include:

Support for common HTTP verbs
Send request parameters and payloads
Inspect responses directly in the browser
Mountable Rails Engine
Seamless integration with your Rails development workflow
Simple setup

Installation

Add the gem to your Gemfile:

gem "rails-http-lab"

Then install it:

bundle install

Now start your Rails server and access:

/rails/http-lab

And you're ready to start testing your routes.

Why build this?

I wanted something that felt more integrated with the Rails developer experience.

External API clients are great, but sometimes you simply want a quick way to:

test an endpoint
tweak parameters
inspect responses
validate controller behavior

…without leaving your application context.

Rails HTTP Lab was created to reduce that friction.

Open Source & Feedback Welcome

The project is open source and still evolving.

If you like the idea, have suggestions, or want to contribute, feel free to check out the repository:

👉 https://github.com/jacksonpires/rails-http-lab

Feedback, issues, PRs, and ideas are very welcome.

Happy hacking 🚀

Special thanks to Vini (https://github.com/viniwenz) and Karine (https://github.com/karinevieira) for helping me with testing!

🇧🇷 Apresentando Rails HTTP Lab: teste rotas Rails diretamente dentro da sua aplicação

Jackson Pires — Fri, 29 May 2026 17:55:55 +0000

Quem trabalha com Ruby on Rails sabe que testar endpoints HTTP faz parte da rotina de desenvolvimento.

Na maioria das vezes usamos ferramentas como Postman, Insomnia, curl ou até scripts temporários apenas para validar requests, headers, payloads e responses.

Mas durante o desenvolvimento eu comecei a me perguntar:

E se fosse possível testar as rotas da própria aplicação Rails diretamente de dentro dela?

Foi dessa ideia que nasceu o Rails HTTP Lab.

O que é o Rails HTTP Lab?

rails-http-lab é uma Rails Engine que adiciona uma interface integrada à sua aplicação para testar requisições HTTP contra as próprias rotas da aplicação.

Pense nele como um cliente HTTP leve, mas focado no seu ambiente Rails.

Com ele você pode experimentar endpoints sem precisar alternar constantemente entre editor, terminal, navegador e ferramentas externas de API.

Funcionalidades

Atualmente a gem oferece:

Suporte aos principais verbos HTTP
Envio de parâmetros e payloads
Visualização das responses diretamente no navegador
Rails Engine mountável
Integração natural com o fluxo de desenvolvimento Rails
Configuração simples

Instalação

Adicione a gem ao seu Gemfile:

gem "rails-http-lab"

Depois instale:

bundle install

Agora basta iniciar o servidor Rails e acessar:

/rails/http-lab

Pronto. Você já pode começar a testar suas rotas.

Por que criar isso?

Eu queria algo mais integrado à experiência de desenvolvimento com Rails.

Ferramentas externas de API são excelentes, mas às vezes você só precisa de uma forma rápida de:

testar um endpoint
ajustar parâmetros
inspecionar responses
validar o comportamento do controller

…sem sair do contexto da própria aplicação.

O Rails HTTP Lab surgiu justamente para reduzir esse atrito.

Open Source e feedback são bem-vindos

O projeto é open source e ainda está evoluindo.

Se a ideia parece interessante, você tem sugestões ou quer contribuir, confira o repositório:

👉 https://github.com/jacksonpires/rails-http-lab

Issues, PRs, feedbacks e ideias são muito bem-vindos.

Happy coding 🚀

Agradecimento especial a Vini (https://github.com/viniwenz) e Karine (https://github.com/karinevieira) que me ajudaram nos testes!

🇺🇸 Rails Realtime ERD: Visualize Your Rails Schema in Real Time

Jackson Pires — Wed, 27 May 2026 13:23:42 +0000

Anyone who works with Ruby on Rails applications knows that, as a project grows, quickly understanding the relationships between models can become increasingly difficult.

Even when using traditional ERD (Entity Relationship Diagram) generation tools, there is usually some friction in the workflow: generating files, manually updating diagrams, or relying on external processes.

With that in mind, I created the Rails Realtime ERD gem.

What is Rails Realtime ERD?

rails-realtime-erd is a Ruby on Rails gem that allows you to visualize your schema ERD diagrams in real time directly inside your application.

The idea is simple:

Install the gem
Add it to your project
Open a route
See your diagram automatically updated

No manual image generation. No intermediate exports. No leaving your application context.

Key Features

✅ Real-time schema visualization
✅ Simple integration with Rails applications
✅ Built on Rails Engine
✅ Automatic updates as your models evolve
✅ Integrated web interface

Perfect for:

Understanding existing architectures
Onboarding new developers
Quickly exploring model relationships
Keeping living documentation of your application's domain

Installation

Add the gem to your Gemfile:

gem "rails-realtime-erd"

Then run:

bundle install

Now simply access:

/rails/erd

in your project to visualize your diagram.

Why create this gem?

During consulting work, training sessions, and Rails application development, I often felt the lack of a more dynamic experience for inspecting an application's domain.

I wanted something closer to the experience we already have with:

/rails/mailers
/sidekiq
internal dashboards
integrated development tools

In other words: open a URL and start exploring immediately.

That's how Rails Realtime ERD was born.

Open Source Project

The gem is open source and available on GitHub:

GitHub:

https://github.com/jacksonpires/rails-realtime-erd

Contributions, feedback, issues, and suggestions are very welcome.

If you work with Rails and enjoy tools that improve productivity and architectural understanding, give it a try.

🇧🇷 Rails Realtime ERD: visualize seu schema Rails em tempo real

Jackson Pires — Wed, 27 May 2026 13:10:31 +0000

Quem trabalha com aplicações Ruby on Rails sabe que, conforme o projeto cresce, entender rapidamente as relações entre modelos pode se tornar cada vez mais difícil.

Mesmo utilizando ferramentas tradicionais de geração de ERD (Entity Relationship Diagram), normalmente existe um pequeno atrito no fluxo: gerar arquivos, atualizar diagramas manualmente ou depender de processos externos.

Pensando nisso, criei a gem Rails Realtime ERD.

O que é o Rails Realtime ERD?

O rails-realtime-erd é uma gem para Ruby on Rails que permite visualizar diagramas ERD do seu schema em tempo real diretamente dentro da aplicação.

A proposta é simples:

Instalar a gem
Montar a engine no projeto
Abrir uma rota
Ver seu diagrama atualizado automaticamente

Sem geração manual de imagens. Sem exportações intermediárias. Sem sair do contexto da aplicação.

Principais recursos

✅ Visualização do schema em tempo real
✅ Integração simples com aplicações Rails
✅ Baseado em Rails Engine
✅ Atualizações automáticas conforme seus models evoluem
✅ Interface web integrada ao projeto

Ideal para:

Entender arquiteturas existentes
Onboarding de novos desenvolvedores
Exploração rápida de relacionamentos entre modelos
Documentação viva do domínio da aplicação

Instalação

Adicione a gem ao seu Gemfile:

gem "rails-realtime-erd"

Depois:

bundle install

Agora basta acessar

/rails/erd

em seu projeto e visualizar seu diagrama.

Por que criar essa gem?

Durante consultorias, cursos e desenvolvimento de aplicações Rails, frequentemente senti falta de uma experiência mais dinâmica para inspeção do domínio da aplicação.

Queria algo próximo da experiência que temos com:

/rails/mailers
/sidekiq
dashboards internos
ferramentas de desenvolvimento integradas

Ou seja: abrir uma URL e começar a explorar imediatamente.

Foi daí que nasceu o Rails Realtime ERD.

Projeto Open Source

A gem é open source e está disponível no GitHub:

GitHub:

https://github.com/jacksonpires/rails-realtime-erd

Contribuições, feedbacks, issues e sugestões são muito bem-vindos.

Se você trabalha com Rails e gosta de ferramentas para melhorar produtividade e entendimento de arquitetura, vale a pena experimentar.

Instalando o PostgreSQL no WSL (Windows Subsystem Linux)

Jackson Pires — Sat, 15 Mar 2025 13:40:55 +0000

Muitos perguntam se é possível usar o PostgreSQL dentro do WSL do Windows para trabalhar com o Rails e a resposta é sim!

Abaixo segue um vídeo onde mostro como fazer esse essa instalação/configuração.

Instalando o VSCode, Rails e testando a instalação (Windows)

Jackson Pires — Sat, 15 Mar 2025 13:24:33 +0000

No vídeo abaixo mostro como instalar o VSCode e Rails no Windows.

Instalando o RVM no WSL

Jackson Pires — Sat, 15 Mar 2025 13:22:52 +0000

Após a instalação do WSL podemos instalar o RVM (Ruby Version Manager) para que possamos gerenciar as versões do Ruby de forma mais fácil.

Abaixo segue um vídeo onde mostro como fazer esse essa instalação/configuração.

Como instalar o WSL no Windows 11

Jackson Pires — Sat, 15 Mar 2025 13:20:25 +0000

É certo que para usarmos o Ruby on Rails é melhor que estejamos em um ambiente *NIX, sendo assim, uma das alternativas para quem usa Windows é instalar o WSL (Windows Subsystem Linux) a fim de desfrutar desse tipo de ambiente.

Abaixo segue um vídeo onde mostro como fazer esse processo que é relativamente simples mas que traz um enorme benefício para quem usa Windows.

DEV Community: Jackson Pires

🇺🇸 3 Essential Gems to Eliminate Friction in Your Rails Workflow

1. rails-api-docs: The End of Outdated Documentation]

2. rails-http-lab: Your HTTP Client Right in the App

3. rails-realtime-erd: Database Diagrams Always in Sync

Conclusion

🇧🇷 3 Gems Indispensáveis para Eliminar as Deficiências do seu Fluxo de Trabalho no Rails

1. rails-api-docs: O Fim da Documentação Desatualizada

2. rails-http-lab: Seu Client HTTP Direto na Aplicação

3. rails-realtime-erd: Diagramas de Banco de Dados Sempre Sincronizados

Conclusão

🇺🇸 I Got Tired of Stale API Documentation in Rails — So I Built `rails-api-docs`

The idea started with a simple question

The workflow I wanted didn't exist

A single source of truth

How it works

Let the code write the first draft

Documentation updates shouldn't destroy your work

Organizing larger APIs with tags

Production should be simple

I'm not trying to replace OpenAPI

Final thoughts

🇧🇷 Eu Cansei de Documentação de API Desatualizada no Rails — Então Criei a Gem `rails-api-docs`

A ideia surgiu de uma pergunta simples

O workflow que eu queria não existia

Uma única fonte da verdade

Como funciona

Deixe o código escrever o primeiro rascunho

Atualizações não deveriam apagar seu trabalho

Organizando APIs maiores com Tags

Produção deveria ser simples

Não estou tentando substituir OpenAPI

Considerações finais

🇺🇸 Introducing Rails HTTP Lab: Test Your Rails Routes Directly Inside Your Application

What is Rails HTTP Lab?

Features

Installation

Why build this?

Open Source & Feedback Welcome

🇧🇷 Apresentando Rails HTTP Lab: teste rotas Rails diretamente dentro da sua aplicação

O que é o Rails HTTP Lab?

Funcionalidades

Instalação

Por que criar isso?

Open Source e feedback são bem-vindos

🇺🇸 Rails Realtime ERD: Visualize Your Rails Schema in Real Time

What is Rails Realtime ERD?

Key Features

Installation

Why create this gem?

Open Source Project

🇧🇷 Rails Realtime ERD: visualize seu schema Rails em tempo real

O que é o Rails Realtime ERD?

Principais recursos

Instalação

Por que criar essa gem?

Projeto Open Source

Instalando o PostgreSQL no WSL (Windows Subsystem Linux)

Instalando o VSCode, Rails e testando a instalação (Windows)

Instalando o RVM no WSL

Como instalar o WSL no Windows 11

1. `rails-api-docs`: The End of Outdated Documentation]

2. `rails-http-lab`: Your HTTP Client Right in the App

3. `rails-realtime-erd`: Database Diagrams Always in Sync

1. `rails-api-docs`: O Fim da Documentação Desatualizada

2. `rails-http-lab`: Seu Client HTTP Direto na Aplicação

3. `rails-realtime-erd`: Diagramas de Banco de Dados Sempre Sincronizados