Criando uma estrutura escalável para sua aplicação
Published: 2020-04-22 21:23:35

---
title: Criando uma estrutura escalável para sua aplicação
published: true
date: 2018-07-11 02:21:33 UTC
tags: 
canonical_url: https://medium.com/@mauriciord/criando-uma-estrutura-escal%C3%A1vel-para-sua-aplica%C3%A7%C3%A3o-e2e8dc0cecdf
---

![](https://cdn-images-1.medium.com/max/1024/1*cfPMuylOaSJhmtOaLs0p0w.png)

### Introdução

Muitas vezes quando você inicia o desenvolvimento de uma aplicação, não há um planejamento de como nomear e organizar os arquivos de uma forma que sua aplicação seja escalável. Depois que ela cresce sem organização, fica díficil outra pessoa além de você mexer no código e aí cada um nomeia de um jeito(PARE!!!).  
Vou me basear em uma aplicação usando React Native com as principais libs: **Redux** , **React Navigation** , **Redux Saga** , etc. Isso vai servir para qualquer aplicação que a ideia seja desacoplar o máximo de coisa possível.

### Árvore de arquivos

```
- assets
- src
    - components
    - features
    - navigation
        - stacks
    - screens
    - services
        - api
    - shared
        - constants
        - validations
        - utils
    - state
    - App.js
- index.js
- .babelrc
```

> Essa separação de arquivos é toda baseada em _Features_, que nada mais é que toda novidade que você deseja criar na sua aplicação

### Estrutura de pastas

#### src/components

É semelhante ao UI, com componentes que serão comuns em mais de uma tela do sistema. A ideia é de que não tenhamos mais uma pasta como essa na aplicação, visto que depois você pode criar separado uma UI, compartilhando seus componentes em qualquer sistema que você tenha.

#### src/features

É onde armazenamos todos as _features_ do sistema, com seus respectivos _components_ e _containers_.

- **Components** : O _component_ da _feature_ irá usar os components ou algum específico
- **Containers** : No caso, como usamos **Redux** , aqui estão os disparos das _actions_, propriedades da _store_, etc.

#### src/navigation

Aqui temos o Router.js, do qual funciona semelhante a um React Router. Na pasta stacks está separado por _features_ cada _stack_ de rotas de navegação.

#### src/screens

Pasta que contém as telas do sistema. Em cada tela, podemos chamar os componentes(UI) comuns que estão na pasta components tanto quanto as _features_ que ficam na pasta features, fazendo com que não seja misturado nenhum estado das _features_.  
Uma observação é que conforme a necessidade nos faça criar novas telas, seria melhor separar as _screens_ por _features_, criando uma pasta com nome da _feature_.

#### src/services

É onde colocamos serviços com integrações com aplicações de terceiros, _client_para a API, etc. Na pasta api, temos os _clients_ da API, com o arquivo api.js que contém a base do _client_ e depois os _clients_ nomeados por _feature_. Aqui caso você use um serviço, como o Firebase, por exemplo, você pode adicionar as configurações dele em uma pasta firebase.

#### src/shared

Aqui é onde compartilhamos qualquer coisa(com exceção dos componentes) que seja comum em mais de um lugar na aplicação.

#### src/state

Pasta que contém a estrutura de estados da aplicação, separados por _feature_. Cada pasta da _feature_ irá conter essencialmente:

- actions: Arquivo que contém as _actions creators_ disparadas no _container_ da _feature_
- reducer: Arquivo que contém o _reducer_ da _feature_
- sagas: Arquivo que contém as _sagas_(_side-effects_ das _actions_) da _feature_
- types: Arquivo que contém as definições de tipo das _actions_ disparadas no _container_ da _feature_
- schema: Arquivo que contém _schema_ para normalizar a estrutura dos dados recebidos pelo _client_ da API ( **OBS:** NEM SEMPRE É NECESSÁRIO)

Não precisa ser uma estrutura idêntica a essa, mas com esse post você pode se basear para criar sua própria estrutura escalável.  
Tentei passar no _post_ a importância de uma estrutura como essa para que sua aplicação não fique bagunçada a ponto de ninguém querer se juntar a sua ideia, por bagunça de código.