Por que decidimos publicar uma nova API
Tudo acontece muito rápido aqui no iFood. Pode parecer clichê, mas é a mais pura verdade. Isso tem muito a ver com a forma como a gente se organiza e trabalha no dia-a-dia. Pra você entender um pouco melhor a curta história das nossas APIs públicas, precisa entender como a gente se organiza.
Aqui a gente utiliza o modelo de Tribos e Squads do Spotify com algumas adaptações. Internamente nós costumamos dizer que o iFood é um grande transatlântico. Esse transatlântico se organiza em 3 tribos e 87 squads. Essas 87 squads são responsáveis por algumas centenas de microsserviços. Existe portanto uma divisão clara da responsabilidade de cada time.
Além disso de toda essa estrutura, temos também nossas lanchas e motos aquáticas. Sempre que temos uma ideia de novo produto ou de uma feature específica, nós “construímos uma moto aquática e liberamos em alto mar para explorar essa ideia”. São pequenos times multidisciplinares que trabalham numa velocidade incrível para validar essa ideia. Depois de validado, essa moto aquática pode se transformar numa lancha com uma estrutura maior ou até mesmo já ser incorporada a alguma squad. Com esse modelo a gente consegue criar coisas novas e validar tudo isso muito rapidamente, enquanto outros times continuam mantendo e evoluindo a plataforma.
E como esse modelo impacta nas nossas APIs públicas?
Acontece que ao longo do tempo, algumas necessidades foram surgindo e nós sempre respondemos muito rápido. Quando surgiu a necessidade de disponibilizar uma API para que alguns PDVs (POS) fizessem a integração da recepção de pedidos, o time em que eu trabalho atualmente ficou responsável por criar alguns serviços novos para atender essa demanda. Pouco tempo depois um outro time precisou disponibilizar uma API de catálogo (cardápio) e logo depois um outro time disponibilizou endpoints de avaliações de restaurantes e daí em diante. Em pouco tempo tivemos então um conjunto de APIs sendo disponibilizadas cada uma por um time diferente.
Começamos a perceber que para ser rápidos, acabamos expondo o nossos modelos internos que geralmente são complexos ao invés de construir algo pensando no cliente externo. Além disso, sentimos falta de alguns padrões básicos como política de versionamento, padrões de rotas e recursos da API.
Foi aí então que decidimos disponibilizar uma API nova e criar um time novo responsável pela governança dessas novas APIs. Aproveitamos a oportunidade também para desenvolver um novo portal do desenvolvedor que além de prover uma documentação mais clara e detalhada, permitisse também que a gente disponibilizasse novas ferramentas para que os desenvolvedores pudessem ter uma experiência melhor no dia-a-dia.
Agora chegou o momento de compartilhar essas mudanças com todos vocês. Nos próximos dias vamos publicar alguns artigos com mais detalhes dessas mudanças e esperamos que vocês gostem das novidades e que também nos enviem feedbacks para que a gente possa continuar evoluindo e revolucionando o universo da alimentação juntos!
