DEV Community: Lucas Vilaboim

O Descompasso entre Frontend e Backend: Por que suas Rotas Devem Ser RESTful

Lucas Vilaboim — Thu, 11 Sep 2025 14:21:46 +0000

Sabe quando você está construindo uma aplicação e de repente percebe que as URLs que o usuário navega na tela não têm muita conexão com as rotas da sua API? Por exemplo, o usuário acessa meusite.com/listar-artigos e, por baixo dos panos, o seu código faz uma requisição para a API em api.meusite.com/posts. A aplicação funciona, claro, mas essa pequena diferença esconde uma oportunidade enorme de deixar o seu código mais limpo e intuitivo.

Aqui vamos explorar a ideia de alinhar a arquitetura de rotas do seu frontend com os princípios RESTful do backend. Não é uma regra rígida, mas uma abordagem que traz mais consistência, previsibilidade e, no fim das contas, facilita a vida de quem precisa dar manutenção no projeto.

O Que é RESTful, de Fato?
Se você já trabalhou com APIs, é provável que já tenha ouvido falar em REST, ou mais especificamente, em RESTful. De forma bem simples, pense em um sistema RESTful como um conjunto de regras que guiam a comunicação entre o seu frontend e o backend. O ponto principal é que tudo é tratado como um recurso, e as ações que você pode fazer com esses recursos são definidas por verbos HTTP.

Não precisa de muita teoria. A regra de ouro é: uma URL deve identificar um recurso, e o verbo HTTP diz o que você quer fazer com ele. Por exemplo, em um blog:

GET /posts: Pede para "obter" (GET) a lista de todos os "posts".
GET /posts/123: Pede para "obter" (GET) um "post" específico (o de ID 123).
POST /posts: Pede para "criar" (POST) um novo "post".
DELETE /posts/123: Pede para "deletar" (DELETE) o "post" de ID 123.

Essa organização é o que nos permite ter rotas previsíveis no backend, algo que podemos e devemos espelhar no frontend.

A Relação Direta: Sua URL no Navegador
A grande sacada aqui é a seguinte: a URL que o seu usuário vê no navegador, a URL que aparece na barra de endereços, pode — e deveria — ser um espelho da rota da API que está sendo consumida.

Pense na experiência do usuário e na sua própria como desenvolvedor. Quando você vê a URL meublog.com/posts/123, o que você espera que aconteça? Você espera ver o post com o ID 123. E, por trás dessa interface, a sua aplicação de frontend pode estar fazendo uma requisição GET para a rota /posts/123 na sua API.

Outro exemplo: quando você está em uma página de criação e a URL é meublog.com/posts/new, a ação esperada é criar um novo post. Por baixo dos panos, a sua aplicação provavelmente enviará uma requisição POST para a rota /posts.

Essa não é uma coincidência; é uma prática de design intencional que traz clareza para todos os envolvidos. O usuário tem uma URL intuitiva e limpa, e o desenvolvedor tem uma rota no frontend que faz sentido e se alinha com o "contrato" da API. Essa previsibilidade é o que simplifica a vida de todo mundo.

Por que isso é uma Boa Ideia? Onde o "ganho" acontece?
Você pode estar se perguntando: "Ok, entendi o conceito, mas por que eu deveria me preocupar em fazer isso?". A resposta é simples: previsibilidade e clareza. Seguir esse padrão não é só uma questão de estética; é uma decisão de arquitetura que traz ganhos reais para o seu projeto e sua equipe.

1. Facilidade de Manutenção e Leitura
Ao alinhar as rotas do frontend com a API, você torna o seu código mais legível e intuitivo. Um novo desenvolvedor que entra no projeto e vê uma rota como /posts/:id no código do frontend já consegue deduzir imediatamente que ela está consumindo a API de GET /posts/:id. Essa clareza reduz a curva de aprendizado e minimiza a chance de erros.

2. Simplificação da Comunicação
Quando a rota do frontend espelha a da API, o "contrato" entre o front-end e o back-end se torna explícito. A URL do navegador é a documentação. Isso elimina a necessidade de longas reuniões ou documentos complexos para explicar como uma determinada tela se conecta com o servidor. A comunicação entre as equipes se torna mais fluida e natural.

3. Consistência e Previsibilidade
Pense em um Design System, mas para as URLs. Quando você segue um padrão, o comportamento do sistema se torna previsível. Você sabe que a rota para listar um recurso será sempre a sua URL no plural (/recursos), e a para ver o detalhe será com um identificador (/recursos/123). Essa consistência reduz o atrito e permite que a equipe se concentre em problemas mais complexos.

Exemplos Práticos: Da Teoria à Prática
Para visualizar como essa ideia funciona na prática, vamos voltar ao nosso exemplo do blog. Veja como a URL no navegador se alinha diretamente com a rota da API, tornando a comunicação e o entendimento do sistema muito mais fáceis.

Listar todos os posts:
- URL no navegador: meublog.com/posts
- Requisição à API: GET /posts
Visualizar um post específico:
- URL no navegador: meublog.com/posts/123
- Requisição à API: GET /posts/123
Listar posts de um autor específico, ordenados do mais antigo para o mais novo:
- URL no navegador: meublog.com/posts?author=vilaboim&order=older
- Requisição à API: GET /posts?author=vilaboim&order=older

Percebe como a consistência simplifica o processo? Ao ver a URL no navegador, você já sabe exatamente qual requisição a sua aplicação de frontend precisa fazer para interagir com o backend.

Conclusão: Um Pequeno Passo para uma Grande Melhoria
Alinhar as rotas do seu frontend com a arquitetura RESTful do backend pode parecer um detalhe pequeno, quase uma formalidade. Mas, como vimos, essa simples prática tem um impacto significativo na saúde do seu projeto.

Não é seguir regras por seguir, mas construir sistemas mais previsíveis, fáceis de entender e, consequentemente, mais fáceis de manter. Quando as URLs no navegador fazem sentido e espelham a API, você está criando um "contrato" de navegação intuitivo, simplificando a vida de quem usa e, principalmente, de quem desenvolve.

Da próxima vez que você for criar as rotas para o seu projeto, pense nisso. Esse pequeno ajuste de arquitetura pode fazer uma grande diferença na colaboração da sua equipe e na longevidade do seu código.

Guide to using Slack in remote work

Lucas Vilaboim — Sat, 24 Feb 2024 00:54:13 +0000

📸 by Pavan Trikutam

The secret is asynchronous communication

Asynchronous communication is when you communicate without expecting an immediate response. And this allows you to do your work in a more concentrated manner and with fewer interruptions, which is very important in remote work.

The aim of this guide is for you to interrupt less and be less interrupted in the remote work environment, and it starts from the principle that all communication can and should be asynchronous.

How do I do this?

Could this meeting be an email, a message, an audio, a video? Yes.
And using one of these options, would the problem be solved quickly and effectively? Yes.
So I'll use one of the aforementioned substitutions.

How to make your conversations asynchronous

Can your message be understood with just text? Send a message.
Is it more complex and requires more context? Send an audio.
Is there a need to present a screen? Send a video.
Need a deeper discussion with exchange of ideas? Then a meeting can be useful.

💡Tip: don't just send Hi, how are you?, complement with what you need;
💡Tip 2: if you received the Hi, how are you? I need X, assume the good intention of the person who sent you this beautiful asynchronous message;
💡Tip 3: if sending audio or video, also send a title so the person can search in the future.

`@channel` and `@here`

Using channels in Slack reduces noise and communicates a lot of people at once, but a communication error in a channel, involving many people, can cause a lot of embarrassment.

Imagine you work in a room with over 20 people, and you need to pass on a message. You could stand in front of the door and get everyone's attention, when everyone looks, you speak. But imagine if this repeats several times a week, or even in one day, it would be impractical to stop everyone every time; in such a situation, I would simply put a notice on the door, and whoever passes by will see it and eventually comment to other colleagues.

And the remote environment works similarly, when we tag a message with @here we notify everyone who is online on Slack, and with @channel it's worse because we notify even those who are offline - people on vacation, on leave, getting married - and if people respond in the thread it's a notification for each message.

I follow these rules:

Does everyone need to read the message at the moment it will be sent? If the answer is no, I do not use @here or @channel;
Okay, the message is very important and immediate, but will only benefit or help those who are online? I send an @here.
And as a last resort, when I couldn't find a justification not to notify everyone, I review my life choices, but never send @channel.

You can learn more about notifications here.

Direct Messages vs Group Messages vs Channels

Slack allows you to chat with one or more people in three ways:

A conversation between 2 people, which is a direct message;
A conversation between 3 or more people through a channel;
And a conversation between 3 or more people through a group direct message;

When to use a direct message

Want to talk to just one person and the subject doesn't need to involve more people? Send a direct message.

When to use a group direct message

Does this conversation have between 3 and 9 people?
Does it have a deadline to finish? Is it a specific topic?
Will no one else be added to the conversation?
Answered Yes to all questions? Use the group direct message.

When to use channels?

Does this conversation have more than 9 people?
Will new people be added over time?
Is it a subject that will be prolonged or revisited several times?
Answered Yes to any of these questions? Create a channel.

Here you'll find more information about direct messages, and here about channels.

Threads

Channels are great for sharing conversations, but when a discussion extends too much, it becomes almost impossible to know when it starts or ends.

For those familiar with Twitter, Slack threads are quite similar; for those who don't, it's more or less like this:

There's the timeline of messages, whether in direct messages or channels, with the entire history of messages sent there; a thread is a way to organize only the responses related to a specific message.

Let's look at an example: I send a message about the company website not working, immediately after my message someone asks how to access a certain database, and after this message someone else responds to my message, asking for more details of my problem, and with a few more messages the conversations get mixed up and it's difficult to follow and know where one starts and the other ends.

And now this same situation with threads: I send my message, someone sends another about a different topic, a third person asks me for more details, but this time within the thread of my message, and so the two subjects evolve, each in its thread, without cluttering the original timeline and facilitating future search.

💡Tip: need to send a message in an old thread and want new people (besides those who responded to the thread) to know? Check the box below the message and send it to the channel or group direct message.

More information about threads here.

Audios and Huddles

When we have a very complex concept or problem to be sent and solved via text, we resort to a meeting with too many people, without purpose, and that only generates another meeting. We can simplify this flow with Slack audios and huddles, with these conditions:

When to send an audio

Do you just need to communicate (without the need for discussion) something more complex?
Do you just need to explain a concept or problem to one or more people?
Answered Yes to any of these questions? Send an audio.

When to create a huddle

Do you need to discuss an idea, a concept, or outline a strategy with one or more people? Answered Yes, create a huddle.

💡Tip: remember, a good meeting is a meeting with a goal; if you need to create a huddle, have a goal and an end time for the meeting, and take the lead in the discussion to ensure that both points will be achieved: solving the issue within the set time.

Here is Slack's documentation on audio and video.

Basic guide to code review

Lucas Vilaboim — Sat, 24 Feb 2024 00:09:03 +0000

A software developer will have their code reviewed and will review others' code practically every day, and even with this repetition, sometimes we forget a point or two.

This is a guide with basic points to be checked in a code review, feel free to use/modify/improve it, in your company or open-source project.

For the requester

Write good commit messages (following the Conventional Commits is a good start);
Review your pull request before opening it, make sure you haven't forgotten any debugger or typing error;
Keep your pull request small, this makes it easy to review and less harmful to the business;
Ensure that your pull request passes tests, linters, and builds, and has no conflicts;
Write a good description;
Comment on your own pull request if any piece of code is not obvious;
Wait for the reviewer to finish before starting to fix;
Choose the right reviewers (example: someone who has already worked on the same part of the code);

For the reviewer

Be kind;
Be a thorough person (this document can help you);
Seek context. Read the pull request description, the ticket, even check the screens (if any);
Make sure you've set aside the necessary time to understand and make the best code review you can;
Respect the context. If a pull request fixes a bug, don't ask the developer to refactor the entire component, this can be addressed in the future;
Make it clear that you are doing the review, comment Reviewing when starting, and Reviewed when finished.

This guide is constantly evolving 😊

Guia de uso do Slack no trabalho remoto

Lucas Vilaboim — Wed, 29 Nov 2023 12:10:10 +0000

📸 por Pavan Trikutam

O segredo é a comunicação assíncrona

Comunicação assíncrona é quando se comunica sem esperar resposta imediata. E isso te possibilita fazer seu trabalho de forma mais concentrada e sem muitas interrupções, o que é muito importante no trabalho remoto.

O objetivo deste guia é que você interrompa menos e seja menos interrompido no ambiente de trabalho remoto, e ele parte do princípio de que toda comunicação pode e deve ser assíncrona.

Como faço isso?

Essa reunião poderia ser um e-mail, uma mensagem, um áudio, um vídeo? Sim.
E usando uma dessas opções o problema seria resolvido de forma rápida e efetiva? Sim.
Então usarei uma das substituições acima mencionadas.

Como tornar as suas conversas assíncronas

Sua mensagem pode ser compreendida apenas com texto? Mande uma mensagem.
Ela é mais complexa e necessita de mais contexto? Mande um áudio.
Há a necessidade de apresentar alguma tela? Mande um vídeo.
Precisa de uma discussão mais aprofundada com troca de ideias? Aí sim uma reunião pode ser útil.

💡Dica: não mande apenas Oi, tudo bem?, complemente com o que você precisa;
💡Dica 2: você que recebeu o Oi, tudo bem? Preciso de X, assuma a boa intenção de quem te enviou essa bela mensagem assíncrona;
💡Dica 3: se for mandar áudio ou vídeo envie também um título para a pessoa poder fazer uma busca no futuro.

@canal and @aqui

O uso de canais no Slack diminui ruídos e comunica muita gente de uma vez só, mas um erro de comunicação em um canal, por envolver muitas pessoas, pode causar muitos constrangimentos.

Imagine que você trabalhe presencialmente em uma sala com mais 20 pessoas, e você precisa dar um recado. Você pode parar na frente da porta e chamar a atenção de todos, quando todas as pessoas olharem, você fala. Mas imagine que isso se repete algumas vezes na semana, ou em um só dia, ficaria inviável parar todo mundo todas essas vezes, se eu estivesse nessa situação apenas colocaria um aviso na porta e quem passar por ali verá e acabará comentando com outros colegas.

E o ambiente remoto funciona de forma parecida, quando marcamos uma mensagem com @aqui notificamos todas as pessoas que estão on-line no Slack, e com o @canal é pior, pois notificamos até quem não está on-line - pessoas de férias, de licença, que estão se casando - e se pessoas respondem na thread é uma notificação para cada mensagem.

Eu sigo as seguintes regras:

Todo mundo precisa ler a mensagem no momento que ela será enviada? Se a resposta for não, eu não uso @aqui ou @canal;
Ok, a mensagem é muito importante e imediata, mas só fará proveito ou poderá me ajudar quem estiver on-line? Mando um @aqui.
E em último caso, quando eu não consegui achar uma justificativa para não avisar todo mundo, eu revejo minhas escolhas de vida, mas nunca mando @canal.

Você pode aprender mais sobre notificações aqui.

Mensagens diretas vs mensagens em grupo vs canais

O Slack te permite conversar com uma ou mais pessoas de três maneiras:

A conversa entre 2 pessoas, que é uma mensagem direta;
A conversa entre 3 ou mais pessoas por um canal;
E a conversa entre 3 ou mais pessoas por uma mensagem direta em grupo;

Quando usar uma mensagem direta

Quer conversar com apenas uma pessoa e o assunto não precisa ser tratado por mais pessoas? Mande uma mensagem direta.

Quando usar uma mensagem direta em grupo

Esta conversa tem entre 3 e 9 pessoas?
Ela tem prazo para se encerrar? É um assunto pontual?
Mais ninguém será adicionado à conversa?
Respondeu Sim a todas as perguntas? Use a mensagem direta em grupo.

Quando usar canais?

Esta conversa tem mais de 9 pessoas?
Novas pessoas serão adicionadas com o tempo?
É um assunto que se prolongará ou será retomado várias vezes?
Respondeu Sim a alguma dessas perguntas? Crie um canal.

Aqui você encontra mais informações sobre mensagens diretas, e aqui sobre canais.

Threads

Canais são ótimos para compartilhar conversas, mas quando uma discussão rende muito assunto fica quase impossível saber quando ela começa ou termina.

Para você que conhece o Twitter, as threads do Slack são bem parecidas, para quem não conhece, é mais ou menos assim:

Existe a timeline de mensagens, seja em mensagens diretas ou canais, com todo histórico de mensagens enviadas ali, uma thread é uma forma de organizar somente as respostas relativas a uma determinada mensagem.

Vamos a um exemplo: eu mando uma mensagem sobre o site da empresa não estar funcionando, imediatamente após minha mensagem alguém pergunta como acessar um determinado banco de dados, e depois desta mensagem outro alguém responde a minha mensagem, perguntando por mais detalhes do meu problema, e com mais algumas mensagens as conversas se misturam e fica difícil acompanhar e saber onde uma começa e a outra termina.

E agora essa mesma situação com threads: eu mando minha mensagem, alguém manda outra sobre outro assunto, uma terceira pessoa me pede mais detalhes, mas desta vez dentro da thread da minha mensagem, e assim os dois assuntos evoluem, cada uma na sua thread, sem sujar a timeline original e facilitando a busca no futuro.

💡Dica: precisa mandar mensagem numa thread antiga e quer que novas pessoas (além de quem respondeu à thread) saibam? Marque a caixa abaixo da mensagem e envie-a ao canal ou mensagem direta em grupo.

Mais informações sobre threads aqui.

Áudios e Círculos

Quando temos um conceito ou problema muito complexo para ser enviado e resolvido via texto apelamos para uma reunião com gente demais, sem objetivo e que só gera outra reunião. Podemos simplificar esse fluxo com os áudios e círculos (huddles) do Slack, com essas condições:

Quando enviar um áudio

Precisa apenas comunicar (sem a necessidade de discussão) algo mais complexo?
Precisa apenas explicar um conceito ou problema para uma ou mais pessoas?
Respondeu Sim a alguma dessas perguntas? Envie um áudio.

Quando criar um círculo

Precisa discutir uma ideia, um conceito ou traçar uma estratégia com uma ou mais pessoas? Respondeu Sim, crie um círculo.

💡Dica: lembre-se, reunião boa é reunião com objetivo, se precisar criar um círculo tenha um objetivo e um horário de fim da reunião, e tome a frente da discussão para garantir que os dois pontos serão alcançados: resolver a questão dentro do tempo determinado.

Aqui está a documentação do Slack sobre áudio e vídeo.

Cuidado com o margin collapse

Lucas Vilaboim — Thu, 28 Sep 2023 18:05:25 +0000

tldr: Use margens em uma só direção, de preferência, para baixo.

Em elementos em sequência a margin-bottom do primeiro elemento e a margin-top do segundo elemento se colapsam e o menor valor é ignorado. Se você tem margin-bottom: 10px e margin-top: 5px isso não resultará em 15px de distância entre os elementos, mas sim 10px.

Resolver isso uma vez ou outra é tranquilo, mas pense em várias telas, com tabelas, listas, menus, etc.

Usando as margens sempre em uma direção você elimina esse problema e ainda facilita a manutenção e integração com outros elementos do código.

Dê uma olhada no exemplo abaixo.

Se quiser mais detalhes confira o artigo no MDN.

Guia básico da revisão de código

Lucas Vilaboim — Mon, 18 Sep 2023 21:41:12 +0000

Uma pessoa que desenvolve software terá o seu código revisado e revisará o de outras pessoas praticamente todos os dias, e mesmo com essa repetição às vezes esquecemos um ponto ou outro.
Este é um guia com pontos básicos a serem verificados em uma revisão de código, fique à vontade para usar/modificar/melhorar, na sua empresa ou projeto open source.

Para quem solicita

Escreva boas mensagens de commit (seguir o Conventional Commits é um bom início);
Revise seu pull request antes de abrí-lo, tenha certeza que você não esqueceu algum debugger ou erro de digitação;
Deixe seu pull request pequeno, isso o mantém fácil de revisar e menos nocivo ao negócio;
Garanta que seu pull request passe nos testes, linters e builds, e não tenha conflitos;
Escreva uma boa descrição;
Comente no seu próprio pull request caso algum trecho de código não seja óbvio;
Espere o revisor terminar para começar a corrigir;
Escolha os revisores corretos (exemplo: alguém que já tenha trabalhado na mesma parte do código);

Para quem revisa

Seja gentil;
Seja uma pessoa minuciosa (este documento pode te ajudar);
Busque contexto. Leia a descrição do pull request, o ticket, verifique até mesmo as telas (se houver);
Tenha certeza que você separou tempo necessário para entender e fazer a melhor revisão de código que você puder;
Respeite o contexto. Se um pull request resolve um bug, não peça para a pessoa desenvolvedora refatorar todo o componente, isso pode ser resolvido no futuro;
Deixe claro que você está fazendo a revisão, comente Revisando ao iniciar, e Revisado ao terminar.

Esse guia é vivo e está em constante evolução 😉

Register Global components in Vue 3

Lucas Vilaboim — Fri, 07 May 2021 21:57:24 +0000

UPDATE: there is an official guide now.

Vue 2 docs has a great way to automatically register base components.
Fortunately this keeps working in Vue 3 with minimal changes.

Get started

As soon as we start a project using vue-cli and Vue 3 we will see something like this in the main.js file:

createApp(App).mount('#app')

Let's change it up a bit to add our base components:

const app = createApp(App)

app.mount('#app')

Before mount the app we will add our registration.

Here we require all components that are inside components folder:

const requireComponent = require.context(
  './components',
  true,
  /Base[A-Z]\w+.(vue|js)$/
)

If you prefer to have folders and index.vue files for components you need to change the regex:

/Base[A-Z]\w+\/index.vue$/

Finally, you need to iterate over all components and register them using the Vue instance we assigned to app variable:

requireComponent.keys().forEach(fileName => {
  const componentConfig = requireComponent(fileName)

  const componentName = upperFirst(
    camelCase(
      fileName
        .split('/')
        .pop()
        .replace(/\.\w+$/, '')
    )
  )

  app.component(
    componentName,
    componentConfig.default || componentConfig
  )
})

Is this real life?

There is a demo app to show the real life implementation.

DEV Community: Lucas Vilaboim

O Descompasso entre Frontend e Backend: Por que suas Rotas Devem Ser RESTful

Guide to using Slack in remote work

The secret is asynchronous communication

How do I do this?

How to make your conversations asynchronous

@channel and @here

I follow these rules:

Direct Messages vs Group Messages vs Channels

When to use a direct message

When to use a group direct message

When to use channels?

Threads

Audios and Huddles

When to send an audio

When to create a huddle

Basic guide to code review

For the requester

For the reviewer

Guia de uso do Slack no trabalho remoto

O segredo é a comunicação assíncrona

Como faço isso?

Como tornar as suas conversas assíncronas

@canal and @aqui

Eu sigo as seguintes regras:

Mensagens diretas vs mensagens em grupo vs canais

Quando usar uma mensagem direta

Quando usar uma mensagem direta em grupo

Quando usar canais?

Threads

Áudios e Círculos

Quando enviar um áudio

Quando criar um círculo

Cuidado com o margin collapse

Guia básico da revisão de código

Para quem solicita

Para quem revisa

Register Global components in Vue 3

Get started

Is this real life?

`@channel` and `@here`