# Brainstorm Products-api v2

**Objetivo:** Listar e debater idéias de melhoria da arquitetura da products-api, sem entrar em detalhes de implementação e priorização. A discussão sobre versionamento também ficam para outro momento.

## Problemas Atuais da Products-api:
- Documentação incompleta e espalhada.
- Muitas responsábilidades distintas na mesma API. Além de armazenar os dados cadastrais e mercadológicos relacionados aos produtos, a ProductsAPI também gerencia dados de precificação, campanhas, subsídios e controles de preço das branded stores.
- Endpoints e modelos criados para atender a WebApp (ex.: stock-and-price).
- Pouco suporte para integrações externas.
- Lógica complexa dos managers. As operações de criação e atualização geram muitos creates e deletes no banco de dados por cada relação.
- Mensagens SNS pesadas.
- Validações de dados falhas ou inexistentes.
- Dependência com GTIN.
- Dependência ao IAS.
- ...

## Ideias:

### Remoção de campos não-utilizados ou mal-utilizados
- (Jé) O array de prices por canal deveria ser usado somente quando o preço do array for diferente do preço na raiz (essa melhoria também se aplica ao array de prices do controlled-gtin) (https://jira-olist.atlassian.net/browse/SUCT-2400 e https://jira-olist.atlassian.net/browse/SUCT-2369)
- (Jé) Precisamos mesmo ter offer e price?
- (Jé) Avaliar remoção da property is_pool (https://jira-olist.atlassian.net/browse/SUCT-1532)
- (Jé) Os campos de comissão, shift de frete, frete grátis, subsidio, minimum_quantity, availability_days, approved, etc ainda são ou devem ser utilizados?
- (Jé) Talvez salvar os historicos em JSON?
- (Jé) Precisamos de um array de product_measures, package_measures e stock, ao invés de apenas um dict?

### Separação de responsabilidades
- (Jé) No futuro, daria para a products-api não ter nada de dados de catálogo, e isso ficar na catalogs-api
- (Jé) Parar de usar a products-api para dados de catálogo nos serviços (https://jira-olist.atlassian.net/browse/SUCT-1481)
- (Jé, Prá) Campos relacionados com campanhas deveriam ficar em outra API, talvez a market-api?
- (Jé, Prá) Ter uma validação tardia de dados mercadologicos com um market-keeper
- (Kako, João) Centralizar validações em uma API, biblioteca, serviço, gRPC... (de webapp, mobile, etc)

### Débitos Técnicos
- (Jé) Remover model de ProductGroup
- (Jé) Melhorar uso de deletes/creates nos managers (https://jira-olist.atlassian.net/browse/SUCT-2096)
- (Jé) Remover implementação de soft-delete (https://jira-olist.atlassian.net/browse/SUCT-2392)
- (Jé) Reduzir payload SNS de seller-product (https://jira-olist.atlassian.net/browse/SUCT-2104)
- (Jé) Como melhorar o endpoint de stock-price?
- (Jé) E a market-api?
- (Jé, Prá) Seller-product sem ODIN
- Isso vai ser resolvido com o novo fluxo de moderação

### Limpeza de dados
- (Jé) Implementar um soft-delete que funciona, e permitir que o seller delete produtos inativados
- (Jé) Padronizar o GTIN

### Documentação
- (Prá) Geração automática de documentação (principalmente para uso externo)