diff --git a/Apache Superset/Criacao_de_plugins.md b/Apache Superset/Criacao_de_plugins.md
new file mode 100644
index 0000000000000000000000000000000000000000..912e9a54626702255d77d02e5e8bf0fdef36ea56
--- /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 0000000000000000000000000000000000000000..c1500ec43eed2288e987354e616adc3e53aa0424
--- /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                        |
+