DEV Community

Vinícius Carregosa
Vinícius Carregosa

Posted on

Mock Server na prática: entendendo JSON Server e o db.json

#api #frontend #javascript #tutorial

Um guia para iniciantes entenderem o que é um Mock Server, como o JSON Server funciona e como utilizar um db.json para desenvolver e testar aplicações frontend.

Introdução

Quando estamos desenvolvendo uma aplicação frontend, existe um problema muito comum: a interface precisa consumir uma API, mas o backend ainda não está pronto.

Imagine que você está construindo uma tela de gerenciamento de membros. O frontend já possui componentes, formulários e regras de interface, mas a API responsável por fornecer e salvar os dados ainda está em desenvolvimento.

Precisamos de uma forma de continuar trabalhando sem esperar o backend ficar pronto.

É aí que entra o Mock Server.

Neste artigo, vamos entender o conceito desde o início e, principalmente, mostrar como utilizar o JSON Server com um arquivo db.json para simular uma API REST.

1. O problema entre frontend e backend

Em uma aplicação real, o frontend normalmente conversa com uma API para obter e modificar dados.

Por exemplo, quando uma tela precisa listar membros, ela pode realizar uma requisição:

GET /members
Enter fullscreen mode Exit fullscreen mode

O backend processaria essa requisição e devolveria algo semelhante a:

[
  {
    "id": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  }
]
Enter fullscreen mode Exit fullscreen mode

O problema aparece quando o frontend está pronto para consumir essa API, mas o backend ainda está sendo desenvolvido.

Nesse cenário, esperar pelo backend pode atrasar o desenvolvimento.

Uma alternativa é criar uma API simulada.

2. O que é um Mock Server?

Um Mock Server é um servidor utilizado para simular o comportamento de uma API.

Ele recebe requisições HTTP e devolve respostas utilizando dados ou comportamentos definidos para o ambiente de desenvolvimento.

Em vez de:

Frontend → API real

podemos trabalhar temporariamente com:

Frontend → Mock Server

Para o frontend, a comunicação continua acontecendo por HTTP.

A diferença é que o servidor utilizado durante o desenvolvimento não representa necessariamente a implementação definitiva do sistema.

Mock Server não é o backend real. É uma simulação da API utilizada para permitir desenvolvimento, testes e prototipação.

3. Uma analogia simples

Imagine que uma equipe esteja construindo um aeroporto.

A equipe responsável pelos sistemas do terminal precisa testar os painéis de voo, balcões e sistemas de atendimento, mas o aeroporto ainda não está operacional.

Em vez de esperar toda a infraestrutura ficar pronta, pode-se criar um ambiente simulado com informações semelhantes às reais.

Os sistemas conseguem testar:

  • chegada de informações;
  • consulta de dados;
  • atualização;
  • comunicação;
  • tratamento de respostas.

Esse ambiente não é o aeroporto definitivo, mas permite que uma parte significativa do trabalho continue.

Um Mock Server funciona de maneira semelhante.

Ele cria um ambiente controlado para que o frontend consiga trabalhar antes da existência da API definitiva.

4. Mock Data não é Mock Server

Os conceitos estão relacionados, mas não são iguais.

Mock Data

São dados fictícios utilizados durante o desenvolvimento.

Por exemplo:

{
  "id": 1,
  "email": "ana@exemplo.com",
  "role": "Admin"
}
Enter fullscreen mode Exit fullscreen mode

Isso é apenas um dado.

Mock Server

É um servidor capaz de disponibilizar esses dados através de uma API.

Por exemplo:

GET http://localhost:3002/members
Enter fullscreen mode Exit fullscreen mode

Agora existe uma aplicação capaz de receber uma requisição HTTP e devolver uma resposta.

Conceito Função
Mock Data Representa dados fictícios
Mock Server Disponibiliza esses dados através de uma API simulada

5. O que é o JSON Server?

O JSON Server é uma ferramenta que permite transformar um arquivo JSON em uma API REST simples.

A ideia é bastante interessante para quem está começando:

Você cria uma estrutura JSON e o JSON Server disponibiliza seus recursos através de endpoints HTTP.

Ele permite simular operações comuns de uma API, como:

  • GET
  • POST
  • PUT
  • PATCH
  • DELETE

Isso possibilita desenvolver e testar um frontend sem precisar construir imediatamente uma API completa.

6. O db.json

No contexto do Member Manager, utilizamos um arquivo chamado:

db.json
Enter fullscreen mode Exit fullscreen mode

Sua estrutura é semelhante a:

{
  "members": [
    {
      "id": 1,
      "projectId": 1,
      "email": "ana@exemplo.com",
      "role": "Admin"
    },
    {
      "id": 2,
      "projectId": 1,
      "email": "carlos@exemplo.com",
      "role": "Viewer"
    },
    {
      "id": 3,
      "projectId": 2,
      "email": "bia@exemplo.com",
      "role": "Operator"
    }
  ]
}
Enter fullscreen mode Exit fullscreen mode

À primeira vista, parece apenas um arquivo JSON comum.

E realmente é.

A diferença é que o JSON Server utiliza essa estrutura para disponibilizar uma API.

7. Entendendo a estrutura do db.json

O primeiro nível do arquivo possui:

{
  "members": []
}
Enter fullscreen mode Exit fullscreen mode

A propriedade:

members
Enter fullscreen mode Exit fullscreen mode

representa uma coleção de recursos.

Podemos pensar nela como uma pequena coleção de membros.

Cada elemento possui suas próprias propriedades:

{
  "id": 1,
  "projectId": 1,
  "email": "ana@exemplo.com",
  "role": "Admin"
}
Enter fullscreen mode Exit fullscreen mode

Vamos entender cada uma delas.

id

O id identifica aquele membro.

"id": 1
Enter fullscreen mode Exit fullscreen mode

Isso permite acessar um recurso específico:

GET /members/1
Enter fullscreen mode Exit fullscreen mode

O identificador também é utilizado nas operações de atualização e remoção.

projectId

O projectId representa o projeto ao qual o membro está associado.

No nosso exemplo:

"projectId": 1
Enter fullscreen mode Exit fullscreen mode

Ana e Carlos pertencem ao projeto 1.

Bia pertence ao projeto 2:

"projectId": 2
Enter fullscreen mode Exit fullscreen mode

Isso permite simular uma relação entre projetos e membros.

Por exemplo:

GET /members?projectId=1
Enter fullscreen mode Exit fullscreen mode

pode ser utilizado para consultar os membros relacionados ao projeto 1.

Essa estrutura foi utilizada no Mock Server do Member Manager para permitir que o frontend consultasse membros por projeto.

email

Representa o email do membro:

"email": "ana@exemplo.com"
Enter fullscreen mode Exit fullscreen mode

É uma informação pertencente à entidade Member.

role

Representa a função do membro dentro do projeto.

No nosso exemplo:

Admin
Operator
Viewer
Enter fullscreen mode Exit fullscreen mode

podem representar diferentes papéis dentro da aplicação.

É importante perceber que o Mock Server está apenas fornecendo esses dados.

Ele não está necessariamente implementando toda a lógica de autorização de uma aplicação real.

8. Como o JSON Server transforma o arquivo em uma API?

Essa é uma das partes mais importantes para entender.

Temos:

db.json
Enter fullscreen mode Exit fullscreen mode

contendo:

{
  "members": [...]
}
Enter fullscreen mode Exit fullscreen mode

Quando o JSON Server é iniciado, ele utiliza essa coleção para disponibilizar recursos HTTP.

No exemplo utilizado no projeto:

npm install -g json-server
Enter fullscreen mode Exit fullscreen mode

Depois:

json-server --watch db.json --port 3002
Enter fullscreen mode Exit fullscreen mode

O recurso members passa a estar disponível em:

http://localhost:3002/members
Enter fullscreen mode Exit fullscreen mode

Agora o frontend pode tratar essa URL como uma API.

9. O endpoint /members

Depois de iniciar o servidor:

GET http://localhost:3002/members
Enter fullscreen mode Exit fullscreen mode

podemos receber:

[
  {
    "id": 1,
    "projectId": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "projectId": 1,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  },
  {
    "id": 3,
    "projectId": 2,
    "email": "bia@exemplo.com",
    "role": "Operator"
  }
]
Enter fullscreen mode Exit fullscreen mode

Perceba que não criamos manualmente uma rota chamada /members.

O JSON Server identificou a coleção:

members
Enter fullscreen mode Exit fullscreen mode

e disponibilizou o recurso.

10. Filtrando por projectId

Agora podemos utilizar o projectId para consultar somente os membros de determinado projeto.

Por exemplo:

GET /members?projectId=1
Enter fullscreen mode Exit fullscreen mode

A resposta será semelhante a:

[
  {
    "id": 1,
    "projectId": 1,
    "email": "ana@exemplo.com",
    "role": "Admin"
  },
  {
    "id": 2,
    "projectId": 1,
    "email": "carlos@exemplo.com",
    "role": "Viewer"
  }
]
Enter fullscreen mode Exit fullscreen mode

Para o projeto 2:

GET /members?projectId=2
Enter fullscreen mode Exit fullscreen mode

podemos obter:

[
  {
    "id": 3,
    "projectId": 2,
    "email": "bia@exemplo.com",
    "role": "Operator"
  }
]
Enter fullscreen mode Exit fullscreen mode

Isso torna o Mock Server mais interessante para desenvolvimento porque conseguimos testar situações próximas das que existirão na aplicação real.

11. GET: lendo dados

O método GET é utilizado para consultar informações.

Listar todos os membros 

GET /members
Enter fullscreen mode Exit fullscreen mode

Buscar um membro específico 

GET /members/1
Enter fullscreen mode Exit fullscreen mode

Buscar membros de um projeto 

GET /members?projectId=1
Enter fullscreen mode Exit fullscreen mode

O Angular pode utilizar essas respostas para construir a interface.

12. POST: criando um membro

O POST normalmente é utilizado para criar um novo recurso.

Podemos enviar:

POST /members
Enter fullscreen mode Exit fullscreen mode

com:

{
  "projectId": 1,
  "email": "joao@exemplo.com",
  "role": "Viewer"
}
Enter fullscreen mode Exit fullscreen mode

O JSON Server adicionará o novo membro à coleção.

Isso permite testar o fluxo de cadastro antes de existir um backend definitivo.

13. PUT: atualizando um membro

Imagine que Carlos atualmente seja:

{
  "id": 2,
  "projectId": 1,
  "email": "carlos@exemplo.com",
  "role": "Viewer"
}
Enter fullscreen mode Exit fullscreen mode

Queremos alterar sua função para Admin.

Podemos fazer:

PUT /members/2
Enter fullscreen mode Exit fullscreen mode

enviando:

{
  "id": 2,
  "projectId": 1,
  "email": "carlos@exemplo.com",
  "role": "Admin"
}
Enter fullscreen mode Exit fullscreen mode

O recurso correspondente será atualizado.

14. DELETE: removendo um membro

Para remover Carlos:

DELETE /members/2
Enter fullscreen mode Exit fullscreen mode

O registro com id = 2 será removido da coleção.

Com isso, conseguimos simular um CRUD completo:

Operação HTTP Endpoint
Criar POST /members
Listar GET /members
Buscar GET /members/:id
Atualizar PUT /members/:id
Remover DELETE /members/:id

15. Onde entra o Angular?

Agora podemos conectar o Mock Server ao frontend.

Uma boa prática é evitar que cada componente faça suas próprias requisições HTTP.

Em vez disso, podemos utilizar um service.

A comunicação pode ser entendida assim:

Component
    |
    | chama
    v
MemberService
    |
    | HTTP
    v
JSON Server
    |
    | lê/escreve
    v
db.json
Enter fullscreen mode Exit fullscreen mode

O componente cuida principalmente da interface.

O service concentra o acesso aos dados.

16. O MemberService

Um exemplo simplificado seria:

@Injectable({
  providedIn: 'root'
})
export class MemberService {

  private api = 'http://localhost:3002/members';

  constructor(private http: HttpClient) {}

  getByProject(projectId: number) {
    return this.http.get<Member[]>(
      `${this.api}?projectId=${projectId}`
    );
  }

  add(member: Omit<Member, 'id'>) {
    return this.http.post<Member>(
      this.api,
      member
    );
  }

  update(member: Member) {
    return this.http.put<Member>(
      `${this.api}/${member.id}`,
      member
    );
  }

  remove(id: number) {
    return this.http.delete(
      `${this.api}/${id}`
    );
  }
}
Enter fullscreen mode Exit fullscreen mode

O mais importante não é decorar esse código.

É entender a responsabilidade do service.

O componente não precisa saber como a URL foi construída.

Ele pode simplesmente solicitar ao service:

"Busque os membros deste projeto."

O service transforma essa solicitação em uma requisição HTTP.

17. Por que separar o componente do service?

Imagine que hoje nossa API seja:

http://localhost:3002/members
Enter fullscreen mode Exit fullscreen mode

Mais tarde, o backend real pode disponibilizar:

https://api.exemplo.com/members
Enter fullscreen mode Exit fullscreen mode

Se os componentes construírem as URLs diretamente, teremos que procurar e alterar diversos pontos da aplicação.

Quando o acesso fica concentrado no service, a mudança fica muito mais controlada.

Essa separação também ajuda a manter responsabilidades claras:

Responsabilidade Componente Service
Interface ✓
Interação do usuário ✓
Requisições HTTP ✓
URL da API ✓
Conversão de dados ✓
Regras de apresentação ✓

18. Mock Server não é backend

Esse é um dos pontos mais importantes.

JSON Server é muito útil para:

  • desenvolvimento frontend;
  • prototipação;
  • testes;
  • demonstrações;
  • desenvolvimento paralelo;
  • criação de interfaces antes do backend.

Mas ele não deve ser confundido com uma API de produção.

Um backend real pode possuir:

  • autenticação;
  • autorização;
  • regras de negócio;
  • validações;
  • banco de dados;
  • tratamento de erros;
  • logs;
  • segurança;
  • transações;
  • controle de concorrência.

O Mock Server normalmente fornece apenas uma representação simplificada da API necessária para o desenvolvimento.

Mock Server permite que o desenvolvimento avance. Ele não substitui automaticamente a arquitetura definitiva do backend.

19. Testando o Mock Server diretamente

Uma das melhores formas de entender uma API é testá-la sem passar pelo frontend.

Depois de iniciar:

json-server --watch db.json --port 3002
Enter fullscreen mode Exit fullscreen mode

podemos utilizar ferramentas como:

  • Postman;
  • Bruno;
  • Insomnia;
  • curl;
  • navegador, para requisições GET.

Por exemplo:

curl http://localhost:3002/members
Enter fullscreen mode Exit fullscreen mode

Para testar o filtro:

curl "http://localhost:3002/members?projectId=1"
Enter fullscreen mode Exit fullscreen mode

Para consultar um membro:

curl http://localhost:3002/members/1
Enter fullscreen mode Exit fullscreen mode

Isso também ajuda no diagnóstico.

Se o endpoint não responde diretamente pelo Postman ou curl, provavelmente o problema está no Mock Server ou na configuração da API simulada, e não no Angular.

20. Um ponto importante sobre versões

É importante prestar atenção à versão do JSON Server utilizada.

A versão atual disponível no npm possui diferenças em relação a versões antigas, inclusive em alguns comportamentos relacionados a id e consultas.

Por isso, em projetos de equipe, é uma boa prática registrar a versão da ferramenta utilizada.

Em vez de cada desenvolvedor instalar uma versão diferente globalmente, podemos declarar a dependência no projeto.

Por exemplo:

npm install --save-dev json-server
Enter fullscreen mode Exit fullscreen mode

Assim, a dependência passa a fazer parte do projeto e pode ser instalada junto com as demais:

npm install
Enter fullscreen mode Exit fullscreen mode

Isso reduz o risco de:

"Na minha máquina funciona."

21. Como pensar sobre Mock Server

Evite pensar:

"Tenho um JSON falso."

É melhor pensar:

"Tenho uma API simulada que permite desenvolver e testar o consumidor antes de possuir o backend definitivo."

Essa diferença de perspectiva é importante.

O arquivo:

db.json
Enter fullscreen mode Exit fullscreen mode

é a fonte dos dados.

O JSON Server fornece o comportamento de servidor HTTP.

O Angular consome essa API.

O MemberService encapsula essa comunicação.

22. O fluxo completo

Podemos representar o funcionamento completo de forma simples:

Usuário
   |
   v
Angular Component
   |
   v
MemberService
   |
   v
HTTP Request
   |
   v
JSON Server
   |
   v
db.json
Enter fullscreen mode Exit fullscreen mode

Quando uma alteração acontece, o caminho inverso ocorre:

db.json
   |
   v
JSON Server
   |
   v
HTTP Response
   |
   v
MemberService
   |
   v
Angular Component
   |
   v
Interface
Enter fullscreen mode Exit fullscreen mode

O ponto importante é que cada camada possui uma responsabilidade.

23. Exercício prático

Uma boa forma de fixar o conteúdo é modificar o próprio db.json.

Adicione:

{
  "id": 4,
  "projectId": 2,
  "email": "lucas@exemplo.com",
  "role": "Viewer"
}
Enter fullscreen mode Exit fullscreen mode

Depois consulte:

GET /members?projectId=2
Enter fullscreen mode Exit fullscreen mode

Observe quais membros aparecem.

Depois tente realizar as quatro operações:

Criar 

POST /members
Enter fullscreen mode Exit fullscreen mode

Consultar 

GET /members
Enter fullscreen mode Exit fullscreen mode

Atualizar 

PUT /members/4
Enter fullscreen mode Exit fullscreen mode

Remover 

DELETE /members/4
Enter fullscreen mode Exit fullscreen mode

Depois tente explicar o que acontece em cada etapa.

Se você consegue explicar o caminho entre Angular → Service → HTTP → Mock Server → dados, o conceito já está sendo compreendido, e não apenas decorado.

24. Erros comuns de iniciantes

Pensar que o db.json é a API

Não é.

O JSON é apenas a fonte de dados utilizada pelo Mock Server.

Colocar toda a lógica HTTP no componente

Isso mistura responsabilidades.

É preferível centralizar o acesso aos dados em um service.

Tratar Mock Server como backend definitivo

O Mock Server existe para simular.

Ele não necessariamente representa todas as regras e comportamentos do backend de produção.

Não testar a API isoladamente

Quando existe um problema no frontend, testar primeiro o endpoint diretamente pode economizar bastante tempo.

Não controlar a versão da ferramenta

Projetos de equipe devem buscar um ambiente reproduzível.

Se cada desenvolvedor utilizar uma versão diferente do JSON Server, o comportamento pode variar.

25. O que aprendemos?

Ao final deste processo, temos vários conceitos importantes:

Mock Data são dados simulados.

Mock Server é um servidor utilizado para simular uma API.

JSON Server transforma uma estrutura JSON em uma API REST simples.

db.json contém os dados utilizados pelo Mock Server.

HTTP é o mecanismo utilizado para comunicação entre cliente e servidor.

MemberService encapsula o acesso à API.

Angular utiliza HttpClient para consumir os endpoints.

A ideia pode ser resumida assim:

Dados simulados
      |
      v
JSON Server
      |
      v
API HTTP
      |
      v
MemberService
      |
      v
Angular
Enter fullscreen mode Exit fullscreen mode

Essa estrutura é simples o suficiente para começar, mas já apresenta conceitos fundamentais que serão encontrados em APIs reais.

26. O que acontece quando o backend real chegar?

Essa é uma das perguntas mais importantes.

No início do desenvolvimento podemos ter:

private api = 'http://localhost:3002/members';
Enter fullscreen mode Exit fullscreen mode

Depois, quando o backend real estiver disponível:

private api = 'https://api.exemplo.com/members';
Enter fullscreen mode Exit fullscreen mode

Idealmente, o componente não precisa saber que essa mudança aconteceu.

Ele continua utilizando:

memberService.getByProject(...)
Enter fullscreen mode Exit fullscreen mode

O service continua responsável pela comunicação.

O que muda é o sistema que responde à requisição.

Essa é uma das vantagens de manter uma separação clara entre a interface e o acesso aos dados.

Conclusão

Um Mock Server resolve um problema bastante comum:

Como continuar desenvolvendo o frontend enquanto o backend ainda não está pronto?

No nosso exemplo, o db.json contém os dados simulados dos membros.

O JSON Server transforma essa estrutura em uma API HTTP.

O Angular consome essa API através do MemberService.

Assim conseguimos implementar e testar operações de:

  • criação;
  • consulta;
  • atualização;
  • remoção;
  • filtragem.

O mais importante é não pensar no Mock Server simplesmente como "um JSON falso".

Pense nele como uma API simulada criada para fornecer um contrato previsível ao frontend durante o desenvolvimento.

Quando o backend real estiver disponível, a simulação pode ser substituída pela implementação definitiva.

Mock Server não tenta substituir o backend. Ele permite que o restante da aplicação avance enquanto o backend ainda está sendo construído.

Referências

Top comments (0)