From f069cecf3c4527cd70058b91a9807d1a65ce9e03 Mon Sep 17 00:00:00 2001 From: j-armenio <joaoarmeniosilveira@gmail.com> Date: Tue, 3 Sep 2024 12:09:52 -0300 Subject: [PATCH] =?UTF-8?q?add:=20Tutorial=20de=20'Cria=C3=A7=C3=A3o=20de?= =?UTF-8?q?=20plugins'=20e=20Tutorial=20de=20'Criacao,=20teste=20e=20produ?= =?UTF-8?q?cao=20do=20frontend'?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- Apache Superset/Criacao_de_plugins.md | 23 ++++ .../Criacao_teste_producao_do_frontend.md | 107 ++++++++++++++++++ 2 files changed, 130 insertions(+) create mode 100644 Apache Superset/Criacao_de_plugins.md create mode 100644 Apache Superset/Criacao_teste_producao_do_frontend.md diff --git a/Apache Superset/Criacao_de_plugins.md b/Apache Superset/Criacao_de_plugins.md new file mode 100644 index 0000000..912e9a5 --- /dev/null +++ b/Apache Superset/Criacao_de_plugins.md @@ -0,0 +1,23 @@ +## Criação de um plugin +--- + +Veja que a criação de um plugin de visualização é semelhante ao tutorial oficial do [Superset](https://superset.apache.org/docs/contributing/howtos/#creating-visualization-plugins). + +Porém se seguirmos o tutorial como está na documentação oficial vamos ver que ele não funciona (problemas com Superset Yeoman Generator, problemas com docker, etc.). Então vamos resolver esses problemas. + +### Problema com o Superset Yeoman Generator + +Atualmente o superset exige os seguintes pré requisitos: - node.js 16 - npm 7 ou 8 Porém após instalar o yeoman vemos que ele não roda ao executar `yo @superset-ui/superset`. Para resolver isso eu utilizei as seguintes versões: - node.js 20.12.2 - npm 10.5.0 Isso resolveu o problema de utilizar o yeoman. + +### Criando o plugin + +Para não colocar o plugin em `/tmp` crie um diretório que fica fora da raiz do superset e coloque seus plugins lá, vamos chamar de `my-plugins/`. E siga o tutorial trocando o diretório `/tmp` por `mt-plugins/`. + +Siga o tutorial até a parte que ele pede para executar `npm run dev-server`. Sim, vamos rodar local o superset-frontend (mas apenas ele, o backend e banco ainda vão estar no docker). Para que o superset não crie o serviço webpack no docker precisamos marcar a flag `BUILD_SUPERSET_FRONTEND_IN_DOCKER=false` e depois executar o `docker compose up` na raiz do projeto. Após subir o docker podemos rodar `npm run dev-server`. + +Baseado no que já vimos de [como rodar o frontend local]() você pode escolher como quer rodar + +- `npm run dev`: Sem servidor webpack +- `npm run dev-server`: Com servidor webpack +- `npm run dev-server -- --env=--superset=http://superset.c3sl.ufpr.br:8088`: Com servidor webpack e outro superset + diff --git a/Apache Superset/Criacao_teste_producao_do_frontend.md b/Apache Superset/Criacao_teste_producao_do_frontend.md new file mode 100644 index 0000000..c1500ec --- /dev/null +++ b/Apache Superset/Criacao_teste_producao_do_frontend.md @@ -0,0 +1,107 @@ +# Criação, teste e produção do frontend Superset +--- + +O superset atual é formado por vários processos:1 + +* backend +* banco + * redis + * postgres (ou outros) +* websocket +* outros + +Percebeu que não tem um frontend? Pois então, o superset não possui um servidor de frontend, ele funciona de formas diferentes dependendo do ambiente que está executando (produção, development/docker). + +## Rodando em dev +--- + +**Existem duas formas de rodar em development, que dependem do valor da variável de ambiente BUILD_SUPERSET_FRONTEND_IN_DOCKER, que está em docker/.env** + +#### 1. BUILD_SUPERSET_FRONTEND_IN_DOCKER=TRUE (default) + +Quando o superset está em modo de desenvolvimento, vamos focar no uso do docker. O que acontece é o seguinte: + +Vários containers vão ser executados e vários diretórios serão montados como volumes neles. Os containers que nos interessam são: + +- `superset_node`: Serviço que roda o webpack, que recompila e junta os arquivos js/ts. +- `superset_app`: Backend que serve a aplicação. + +Quando abrimos o superset no navegador é feita uma requisição para o servidor no `superset_app`, ele então devolve alguns arquivos .js que estão em `/app/superset/static/assets` (montado como volume no docker), que foram compilados pelo `superset_node`. Esses são os arquivos React que fazem o frontend. + +o `superset_node` fica observando o diretório `superset-frontend` (montado como volume no docker) e recompila ele caso haja alguma alteração, em seguida coloca esses arquivos em `/app/superset/static/assets`. Em resumo, quando alguma alteração no código fonte ocorre: + +1. `superset_node` é avisado; +2. `superset_node` recompila arquivos em `superset-frontend`; +3. `superset_node` coloca os arquivos em `superset/static/assets`; +4. `superset_app` verifica que tem novos arquivos e os serve para o usuário. + +#### 2. BUILD_SUPERSET_FRONTEND_IN_DOCKER=FALSE + +Nesse caso o container `superset_node` não vai ser criado, então ele deve ser executado localmente usando o serviço webpack manualmente, com `npm run dev` ou `npm run dev-server` (será explicada a diferença entre eles). + +O funcionamento é exatamente o mesmo, pois agora o serviço webpack que você subiu vai verificar por mudanças em `superset-frontend` na sua máquina e vai fazer tudo local. Ou seja, quando você altera algo em `superset-frontend`: + +1. serviço webpack é avisado; +2. serviço webpack recompila arquivos em `superset-frontend`; +3. serviço webpack coloca arquivos em `superset/static/assets`; +4. `superset_app` verifica que tem novos arquivos e serve para o usuário; + +Mas como o `superset_app` fica sabendo que existem novos arquivos se verifica o diretório `/app/superset/static/assets`? Isso acontece pois o diretório local `superset` foi montado no docker em `/app/superset`, ou seja, eles são sincronizados e dessa forma o `superset_app` consegue ver as alterações. + +#### Diferença entre `npm run dev` e `npm run dev-server` + +`npm run dev` + +Apenas sobe um serviço que observa o `superset-frontend`, recompila esses arquivos e coloca em `superset/static/assets`. Quem fica responsável de entregar esses arquivos é o backend/`superset_app`. + +`npm run dev-server` + +Sobe o serviço webpack e um novo servidor (normalmente com host `http://localgost:9000`) que serve os arquivos compilados pelo serviço webpack. Esses arquivos não vão para `superset/static/assets` (não sabemos exatamente para onde eles vão). Então se é feita uma alteração no front, com ele sendo rodado locamente, e abrir `http://localhost:8088` não vai ter essa alteração, pois não foi colocado nada em `superset/static/assets`. + +O servidor subido por `npm run dev-server` faz uma requisição para o backend do superset rodando em `http://localhost:8088` e altera os arquivos retornados para com os novos arquivos compilados pelo serviço webpack, ou seja, ele vai ter as suas alterações. + +No final, o resultado é o mesmo, você só testa em locais diferentes: + +- `npm run dev`:`http://localhost:8088` +- `npm run dev-server`:`http://localhost:9000` + +**ATENÇÃO: existem algumas diferenças cruciais** + +Se você usar `npm run dev` e depois dar `ctrl-c`, você ainda vai conseguir utilizar o superset em `http://localhost:8088` pois os arquivos ainda estão em `superset/static/assets`. Porém se rodar `npm run dev-server` e der `ctrl-c` você não vai conseguir ver nada em `http://localhost:9000` (talvez tenha algo em `http://localhost:8088`, mas provavelmente vai estar errado). + +##### Proxy com backend remoto + +Outra diferença crucial é, usando o `npm run dev-server`, existe a opção de não utilizar o backend rodando localmente de sua máquina, é possÃvel usar qualquer outro Superset. Isso torna possÃvel o uso do backend de uma máquina de produção sem quebrar nada no front, pois ele será executado localmente. + +Como fazer isso? Simples basta executar + +```bash +npm run dev-server -- --env=--superset=http://supersetdeppdev1.c3sl.ufpr.br:8088 +``` + +No exemplo, esse comando, irá executar o front localmente e conectar com o Superset executado na máquina `supersetdeppdev1`. Todas alterações que forem feitas no diretório `superset-frontend` serão refletidas apenas na máquina local, e não na VM, porém todas mudanças feitas em datasets,charts e queries serão refletidas na máquina, pois são mudanças executadas no backend. + +## Rodando em produção +--- + +Vamos considerar que rodar em produção é subir o superset usando `docker compose -f docker-compose-non-dev.yml up` (de acordo com o que está na documentação da equipe de bd [https://documentation-db.docs.c3sl.ufpr.br/en/latest/pages/Superset/Superset_producao.html](https://documentation-db.docs.c3sl.ufpr.br/en/latest/pages/Superset/Superset_producao.html)). + +Em produção o diretório `superset/` não vai ser montado no docker, então independente da alteração que fizermos em `superset-frontend` não vai aparecer após subir em produção. + +Mas então como devemos fazer para "buildar" as nossas operações? +**TODO** + +## Diretórios montados +--- + +O docker monta varios diretórios da nossa máquina para poder interagir com o código fonte (no caso do devsenvolvimento). + +Os volumes montados são + +|diretório local|diretório no docker|`docker-compose.yml`|`docker-compose-non-dev.yml`| +|---------------|-------------------|--------------------|----------------------------| +|`./docker` |`/app/docker` | sim | sim | +|`./superset` |`/app/superset` | sim | não | +|`./superset-frontend`|`/app/superset-frontend`| sim | não | +|`./tests` |`/app/tests` | sim | não | + -- GitLab