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
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**
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`|
