A primeira API MySklad apareceu há 10 anos. Durante todo esse tempo trabalhamos nas versões existentes da API e desenvolvemos novas. E várias versões da API já foram enterradas.
Este artigo conterá muitas coisas: como a API foi criada, por que o serviço em nuvem precisa dela, o que ela oferece aos usuários, quais erros conseguimos cometer e o que queremos fazer a seguir.
Meu nome é Oleg Alekseev , sou o diretor técnico e cofundador da MySklad.
Por que fazer uma API para um serviço
Nossos clientes, que são dezenas de milhares de empreendedores, usam ativamente soluções em nuvem: bancos, lojas online, contabilidade de commodities, CRM. Depois de se conectar a um, é difícil parar. E agora o quinto, oitavo, décimo serviço facilita o trabalho do empresário, mas os usuários transferem dados entre esses serviços em nuvem manualmente. O trabalho se transforma em um pesadelo.
A solução óbvia é dar aos usuários a capacidade de transferir dados entre serviços em nuvem. Por exemplo, importe e exporte dados como arquivos, que podem então ser carregados no serviço desejado. Os arquivos geralmente são alterados para se adequarem ao formato de cada serviço. Este é um trabalho manual mais ou menos simples, mas com o aumento do número destes serviços torna-se cada vez mais difícil de realizar.
Portanto, o próximo passo é a API. Com ele, o serviço em nuvem se beneficia do fato de conectar diversos serviços em um só ponto. O surgimento de tal ecossistema atrai novos clientes devido a oportunidades adicionais. Um produto com novas funcionalidades torna-se mais rentável e útil.
Se você criar suas próprias interfaces de programação, isso atrairá vendedores terceirizados na forma de programadores que conhecem seu produto graças à API. Eles começam a construir soluções baseadas na API proposta e a ganhar dinheiro automatizando as tarefas de seus clientes.
O sistema de contabilidade MySklad é baseado em processos simples. O principal é trabalhar com documentos primários, a capacidade de aceitar e enviar mercadorias e receber relatórios comerciais com base em documentos primários. Há também a transferência de dados, por exemplo para a contabilidade na nuvem, e o seu recebimento de sistemas bancários ou pontos de venda. Também trabalhamos com lojas online: recebemos informações sobre produtos e enviamos informações sobre saldos.
A primeira API do MySklad
Ao longo dos 10 anos de MySklad trabalhando com API, adquirimos todo tipo de integrações que nos permitem trocar dados, trabalhar com bancos, efetuar pagamentos e utilizar telefonia externa.
No primeiro ano, possibilitamos o download de quaisquer dados em formato XML. Naquela época, era muito mais claro e comum que os usuários mantivessem os dados off-line, em vez de em alguma nuvem, e nós demos isso a eles. O upload foi iniciado pela exportação manual da interface. Ou seja, ainda não poderia ser chamada de API.
Ao mesmo tempo, começamos a cooperar com a empresa Rusagro - eles já usavam um ERP “adulto” para planejamento de produção e vendas, mas automatizavam o carregamento de carros nas fábricas de MySklad. Foi assim que obtivemos os primeiros rudimentos de uma API real: a troca entre nosso serviço e o ERP se dava por meio do envio de um grande arquivo com dados de todos os tipos de documentos.
Esta é uma boa opção para troca de dados em lote, mas junto com os documentos tivemos que transferir suas dependências: informações sobre mercadorias, empreiteiros e armazéns. Esse dump não é tão difícil de gerar na exportação, mas é bastante difícil de analisar na importação, pois todas as informações vêm em um único pacote: tanto sobre novos documentos quanto sobre os existentes.
A primeira API XML não durou muito - dois anos depois começamos a reconstruí-la. Ainda no início do seu trabalho, cometemos vários erros na construção da interface do software.
Como foi feita a API XML: ilustração de um de nossos arquitetos. Aliás, fique atento aos artigos dele.
Aqui estão nossos principais erros:
- A marcação JAXB foi feita diretamente nos beans de entidade. Usamos o Hibernate para nos comunicarmos com o banco de dados, e a marcação JAXB foi feita para os mesmos beans. Este erro apareceu quase imediatamente: qualquer atualização na estrutura de dados levava à necessidade de notificar com urgência todos os que utilizam a API, ou de construir muletas que garantissem a compatibilidade com a estrutura de dados anterior.
- A API cresceu como um complemento e inicialmente não definimos que parte do produto ela representava. Eles nem pensaram se a API era algo importante, se era necessária para manter a retrocompatibilidade de seus primeiros clientes. A certa altura, o número de usuários da API era cerca de 5% do pequeno número e nenhuma atenção foi dada a eles. A filtragem universal feita ao mesmo tempo nos levou a ser usados como backend. Essa filtragem não era GraphQL, mas algo assim - funcionava por meio de vários parâmetros de string de consulta. Com uma ferramenta tão poderosa, era difícil para os usuários resistirem, e as solicitações eram transferidas para nós para que fossem enviadas diretamente da UI de suas lojas online. A situação foi uma surpresa desagradável, porque a prestação de tal serviço deveria exigir preços diferentes e uma compreensão geralmente diferente da própria API como produto.
- Devido ao fato da API não ter sido desenvolvida como produto principal, a documentação da API foi produzida e publicada de forma residual - por meio de engenharia reversa. Este caminho parece bastante simples e conveniente, mas contradiz o trabalho sob contrato. É quando existe um determinado componente com um esquema de funcionamento predefinido. O desenvolvedor o implementa de acordo com este esquema e tarefa, o componente é testado e o cliente recebe um produto que corresponde à ideia do analista. A engenharia reversa lança no mercado um produto que simplesmente existe: com muletas, soluções estranhas e bicicletas em vez da funcionalidade necessária.
- Todo o fluxo de solicitações provenientes da API pode ser analisado como nada mais do que um Nginx ou log do servidor de aplicativos. Isto não nos permitiu identificar áreas temáticas, exceto talvez por usuários e assinantes. Se não houver como regular a aplicação ou o cadastro de clientes, torna-se impossível analisar a situação. Este problema teve o menor impacto no desenvolvimento da API; trata-se mais de entender sua relevância e funcionalidade.
Tentativa número dois: API REST
Em 2010, tentamos construir um sistema de troca com contabilidade online - BukhSoft. Não decolou. Mas durante o processo de integração, apareceu uma API completa: um serviço de troca REST, onde não havia liberdades como acessar operações na forma de chamadas RPC. Toda a comunicação com a API foi trazida para o modo padrão para descanso: a linha de consulta contém o nome da entidade, e a operação que é realizada com ela é especificada pelo método http. Adicionamos filtragem com base em quando as entidades foram atualizadas e os usuários agora têm a oportunidade de criar replicação com seus sistemas.
No mesmo ano, surgiu uma API para descarga de saldos de armazém e estoque. As partes mais valiosas do sistema tornaram-se disponíveis aos usuários via API - a troca de documentos primários e dados calculados sobre saldos e custos de mercadorias.
Em dezembro de 2015, o RetailCRM publicou a primeira biblioteca de terceiros para acessar nossa API. Ele começou a ser usado de forma bastante ativa, enquanto a popularidade do serviço como um todo crescia, a carga na API crescia mais rápido do que a carga na interface web. Um dia, o crescimento se transformou em aumento de carga.
E esse salto, indicado pela seta à esquerda, surpreendeu completamente o servidor que atende nossa API. Passamos uma semana descobrindo o que exatamente estava gerando essa carga. Descobriu-se que essas são as mesmas solicitações transmitidas à nossa API pelas frentes do cliente. Cerca de 50 clientes comeram de tudo. Foi então que percebemos um dos nossos erros - a total falta de limites.
Como resultado, introduzimos um limite no número de solicitações simultâneas. Agora é possível abrir no máximo duas solicitações simultaneamente de uma conta. Isso é suficiente para trabalhar no modo de replicação para troca de dados em lote. E quem quis nos utilizar como backend, a partir desse momento, foi obrigado a cumprir melhor as tarifas, pois introduziu trabalho em diversas contas em seu software.
Vamos colocar isso em ordem
Já desde 2014, a demanda pela API existente tornou-se uma parte importante do negócio, e a própria API gera o maior volume de dados na troca de dados com os clientes. Em 2015, lançamos um projeto de limpeza da API. Escolhemos JSON em vez de XML como formato e começamos a construí-lo com base nos recursos que foram identificados durante a implementação da versão anterior:
- Capacidade de gerenciar versões. O versionamento permite desenvolver uma nova versão sem afetar o aplicativo existente ou interromper a experiência do usuário.
- A capacidade do usuário ver metadados na própria resposta que recebe.
- Capacidade de trocar documentos grandes. Se processarmos um documento com mais de 4 a 5 mil posições, isso se torna um problema para o servidor: uma transação longa, uma solicitação HTTP longa. Construímos um mecanismo especial que permite atualizar um documento em partes e gerenciar posições individuais deste documento, enviando-as para o servidor.
- Ferramentas para replicação também estavam presentes na versão anterior.
- Os limites de carga são como um legado do rake que foi pisado na versão anterior. Introduzimos limites no número de solicitações em um período de tempo, no número de solicitações paralelas e nas solicitações de um endereço IP.
Desde então, lançamos duas versões secundárias da API e diversas APIs especializadas, mas a abordagem geral permaneceu inalterada. O formato de troca atualizado e a nova arquitetura possibilitaram corrigir falhas na API com muito mais rapidez.
API MySklad hoje
Hoje, a API MySklad resolve muitos problemas:
- troca de dados com lojas online, sistemas de contabilidade, bancos;
- obtenção de dados e relatórios calculados;
- use como back-end para aplicativos de clientes - nossos aplicativos móveis e caixa registradora de desktop funcionam via API
- envio de notificações sobre alterações de dados no MySklad - webhooks;
- telefonia;
- sistemas de fidelidade.
Com base na API, nosso CEO Askar Rakhimberdiev em quatro horas escrevi um bot de telegrama que extrai sobras por meio da API:
Agora, números secos.
Aqui estão nossas estatísticas para a antiga API REST:
- 400 empresas;
- 600 usuários;
- 2 milhões de solicitações por dia;
- 200 GB/dia de tráfego de saída.
E aqui está o que criamos para todas as APIs MySklad:
- mais de 70 integrações (algumas delas podem ser visualizadas aqui );
- 8500 empresas;
- 12 usuários;
- 46 milhões de solicitações por dia;
- 2 TB/dia de tráfego de saída.
Qual é o próximo
Os planos de desenvolvimento de API estão em discussão ativa. Tentamos levar em consideração a experiência operacional que os usuários nos proporcionam. Nem sempre é possível fazer tudo de uma vez, mas uma nova versão da API está chegando, com metadados mais convenientes e uma estrutura menos complicada, OAuth para autenticação e uma API para aplicativos integrada à interface.
Você pode acompanhar as novidades em um site especial para desenvolvedores de integrações com MySklad: .
Fonte: habr.com