Skip to main content

Estrutura de Código

Na pasta raiz temos 3 app-configs diferentes. Eles são usados para diferentes ambientes. Quando executamos yarn dev ele usará por padrão o app-config.yaml e sobreescreverá o que estiver em app-config.local.yaml que inicialmente vem vazio.

Vamos imaginar que temos um portal de desenvolvimento e um de produção, mas o projeto é o mesmo e o que muda são as chaves do Github, Gitlab, do banco de dados, do cluster, etc. Claro que na hora de criar uma imagem produtiva precisamos apontar config com as credenciais corretas. Nesse segundo momento será utilizado o app-config.yaml para carregar as configurações inicial e usado o app-config.production.yaml para sobreescrever o necessário.

Na pasta packages temos o seguinte.

tree packages  
packages
├── README.md
├── app
│   ├── e2e-tests
│   │   └── app.test.ts
│   ├── package.json
│   ├── public
│   │   ├── android-chrome-192x192.png
│   │   ├── apple-touch-icon.png
│   │   ├── favicon-16x16.png
│   │   ├── favicon-32x32.png
│   │   ├── favicon.ico
│   │   ├── index.html
│   │   ├── manifest.json
│   │   ├── robots.txt
│   │   └── safari-pinned-tab.svg
│   └── src
│       ├── App.test.tsx
│       ├── App.tsx
│       ├── apis.ts
│       ├── components
│       │   ├── Root
│       │   │   ├── LogoFull.tsx
│       │   │   ├── LogoIcon.tsx
│       │   │   ├── Root.tsx
│       │   │   └── index.ts
│       │   ├── catalog
│       │   │   └── EntityPage.tsx
│       │   └── search
│       │       └── SearchPage.tsx
│       ├── index.tsx
│       └── setupTests.ts
└── backend
    ├── Dockerfile
    ├── README.md
    ├── node_modules
    │   └── app -> ../../app
    ├── package.json
    └── src
        └── index.ts

Podemos ver que temos a pasta app (frontend) e a pasta backend.

  • O fronted (app) é baseado em react.
  • O backend é baseado em nodejs e usa o framework Express JS.

Podemos rodar juntos ou separados. Se olharmos no app-config.yaml podemos ajustar as portas que serão utilizadas para isso.

app:
  title: Scaffolded Backstage App
  baseUrl: http://localhost:3000

backend:
  baseUrl: http://localhost:7007
  listen:
    port: 7007

Em um terminal, na pasta raiz do projeto, se rodarmos o comando yarn start teremos o portal no navegador em localhost:3000 sem conseguir popular nada. Em outro terminal se rodarmos yarn start-backend esperamos um pouco e fizermos um refresh no navegador tudo funciona. O comando yarn dev roda ambos os comandos juntos.

Sabendo disso já podemos entender que podemos escalar isso se precisar no futuro no kubernetes como containers.

A pasta plugins será utilizada se necessário for quando criamos nossos próprios plugins.

O arquivo packages.json podemos ver os comandos que podemos executar no yarn e as versões das bibliotecas utilizadas.

O comando yarn dev é só um alias para o comando real yarn workspaces foreach -A --include backend --include app --parallel -v -i run start. É importante conhecer os comandos pois eles poderão ser uteis no entrypoint e cmd da imagem.

  "scripts": {
    "dev": "yarn workspaces foreach -A --include backend --include app --parallel -v -i run start",
    "start": "yarn workspace app start",
    "start-backend": "yarn workspace backend start",
    "build:backend": "yarn workspace backend build",
    "build:all": "backstage-cli repo build --all",
    "build-image": "yarn workspace backend build-image",
    "tsc": "tsc",
    "tsc:full": "tsc --skipLibCheck false --incremental false",
    "clean": "backstage-cli repo clean",
    "test": "backstage-cli repo test",
    "test:all": "backstage-cli repo test --coverage",
    "test:e2e": "playwright test",
    "fix": "backstage-cli repo fix",
    "lint": "backstage-cli repo lint --since origin/master",
    "lint:all": "backstage-cli repo lint",
    "prettier:check": "prettier --check .",
    "new": "backstage-cli new --scope internal"
  },

Ainda em packages.json, podemos ver a utilização de workspaces. Essa configuração indica o projeto Node.js utiliza Yarn Workspaces, uma funcionalidade que facilita o gerenciamento de monorepos. O que significa? Significa que o yarn instalada todas as dependências dos projetos parciais em um único lugar (pasta node_modules) para evitar duplicação de dependência e facilitar o gerenciamento.

  "workspaces": {
    "packages": [
      "packages/*",
      "plugins/*"
    ]
  },
  • workspaces: Define que o projeto atual é um monorepo e especifica onde os pacotes que fazem parte desse monorepo estão localizados.
  • packages: É um array que lista os diretórios onde estão os pacotes do monorepo. Neste caso temos app com o seu package.json e o backend com seu próprio package.json.
  • plugins: Cada um dos projetos de plugins poderiam inclusive ter seu package.json separado.

"packages/": Inclui todos os diretórios dentro da pasta packages. "plugins/": Inclui todos os diretórios dentro da pasta plugins.

Um exemplo ilustrativo.

meu-projeto/
├── package.json        ← Definição dos workspaces
├── node_modules/       ← Dependências centralizadas
├── packages/
│   ├── pacote1/
│   │   ├── package.json
│   └── pacote2/
│       ├── package.json
└── plugins/
    ├── plugin1/
    │   ├── package.json
    └── plugin2/
        ├── package.json

O comando yarn install instala as dependências para todos os package.json e cada um do projetos do workspace.

O comando yarn workspace app start ou o script yarn start na pasta raiz quer dizer que vamos executar somente o comando yarn start como se estivessemos na pasta package/app. Este comando yarn start, que também é um script do package.json dentro da pasta packages/app, se fosse executado dentro da pasta app (é um workspace) seria a mesma coisa que executar o comando backstage-cli package start.

Scripts do workspace app para ilustrar melhor.

 "scripts": {
    "start": "backstage-cli package start",
    "build": "backstage-cli package build",
    "clean": "backstage-cli package clean",
    "test": "backstage-cli package test",
    "lint": "backstage-cli package lint"
  },

Em app podemos ter um portal com a cara da empresa, incluir diversas abas laterais para facilitar as buscas, e muito mais.

Em backend temos de fato as funcionalidades implementadas.

Sabendo disso, vamos colocar uma aba para o kubernetes ali? Calma jovem gafanhoto, vamos andar depois correr.