Il primo API di MoёgoSklada è apparso 10 anni fa. Da allora lavoriamo sulle versioni esistenti dell'API e sviluppiamo nuove versioni. E alcune versioni dell'API sono già state obsolete.
In questo articolo troverai molte informazioni: come è stato creato l'API, a cosa serve per i servizi cloud, cosa offre agli utenti, quali ostacoli abbiamo incontrato e cosa vogliamo fare in futuro.
Mi chiamo Oleg Alekseev , sono il direttore tecnico e cofondatore di MoёgoSklada.
Perché fare un'API per il servizio
I nostri clienti, che sono decine di migliaia di imprenditori, utilizzano attivamente soluzioni cloud: banche online, negozi internet, gestione delle merci, CRM. Una volta collegati a uno, è difficile fermarsi. E ora il quinto, l'ottavo, il decimo servizio rende il lavoro degli imprenditori più facile, ma i dati tra questi servizi cloud devono essere trasferiti manualmente dagli utenti. Il lavoro si trasforma in un incubo.
Una soluzione ovvia è quella di consentire agli utenti di trasferire dati tra servizi cloud. Ad esempio, importare ed esportare dati come file che possono poi essere caricati nel servizio desiderato. I file di solito vengono modificati nel formato richiesto da ciascun servizio. Questo è un lavoro manuale più o meno semplice, ma con l'aumento di questi servizi, diventa sempre più difficile da gestire.
Pertanto, il passo successivo è l'API. Con essa, il servizio cloud beneficia del collegamento di più servizi in un unico punto. La creazione di un ecosistema del genere attira nuovi clienti grazie alle opportunità aggiuntive. Un prodotto con nuove funzionalità diventa più vantaggioso e utile.
Se si creano interfacce di programmazione proprie, si attirano venditori esterni sotto forma di programmatori che conoscono il proprio prodotto grazie all'API. Iniziano a sviluppare soluzioni basate sull'API proposta e guadagnano denaro automatizzando i compiti dei loro clienti.
Il sistema di contabilità di MoegoSklanda si basa su processi semplici. L'obiettivo principale è lavorare con documenti primari, consentire la ricezione e la spedizione di merci e fornire report aziendali basati sui documenti primari. È anche possibile trasferire dati, ad esempio verso software di contabilità cloud, e riceverli da sistemi bancari o punti vendita. Inoltre, collaboriamo con negozi online: otteniamo informazioni sui prodotti e inviamo dati sulle giacenze.
Il primo API di MoegoSklanda
Negli ultimi 10 anni di attività di MoegoSklanda con API, abbiamo accumulato una varietà di integrazioni che consentono lo scambio di dati, l'interazione con le banche, l'effettuazione di pagamenti e l'uso di telefonia esterna.
Nel primo anno abbiamo creato la possibilità di esportare qualsiasi dato in formato XML. All'epoca, per gli utenti era molto più chiaro e consueto mantenere i dati offline piuttosto che in qualche cloud, e abbiamo fornito loro questa opzione. L'esportazione veniva avviata tramite un'esportazione manuale dall'interfaccia. Quindi non si poteva nemmeno parlare di API.
Allora abbiamo iniziato a collaborare con l'azienda Rusagro: avevano già utilizzato un ERP 'mature' per la pianificazione della produzione e delle vendite, mentre il caricamento dei vagoni negli stabilimenti è stato automatizzato in МоемСкладе. Così sono emerse le prime basi di una vera API: lo scambio tra il nostro servizio e l'ERP avveniva tramite l'invio di un grande file con i dati su tutti i tipi di documenti.
Questa è una buona opzione per lo scambio di dati in batch, ma insieme ai documenti era necessario trasmettere anche le loro dipendenze: informazioni sui prodotti, sui partner commerciali e sui magazzini. Generare un simile ammasso durante l'esportazione non è così difficile, ma è piuttosto complicato da analizzare durante l'importazione, poiché in un unico pacchetto arrivano tutte le informazioni: sia sui nuovi documenti che su quelli già esistenti.
Il primo XML API non è durato a lungo: dopo due anni abbiamo iniziato la sua ristrutturazione. Anche all'inizio del suo funzionamento abbiamo commesso alcuni errori nella costruzione dell'interfaccia programmativa.
Come è stato realizzato l'XML API: un'illustrazione di uno dei nostri architetti. A proposito, aspettatevi i suoi articoli.
Ecco i nostri principali errori:
- La serializzazione JAXB è stata eseguita direttamente sui bean delle entità. Per comunicare con il database utilizziamo Hibernate, e la stessa serializzazione JAXB è stata applicata a questi bean. Questo errore è emerso quasi immediatamente: qualsiasi aggiornamento della struttura dei dati richiedeva di avvisare urgentemente tutti coloro che utilizzavano l'API, oppure di costruire delle soluzioni temporanee che garantissero la compatibilità con la precedente struttura dei dati.
- L'API è cresciuto come un'aggiunta, e inizialmente non abbiamo definito quale parte del prodotto costituisse. Non ci siamo chiesti se l'API fosse qualcosa di importante, se fosse necessario mantenere la retrocompatibilità per i suoi primi clienti. A un certo punto, il numero degli utenti dell'API rappresentava circa il 5% del totale, e non si prestava loro attenzione. La filtrazione universale realizzata all'epoca ha portato a usarci come backend. Questa filtrazione non era del tutto GraphQL, ma qualcosa di simile — funzionava tramite un mucchio di parametri nella stringa della query. Con uno strumento così potente, gli utenti hanno trovato difficile resistere, e le richieste sono state indirizzate a noi in modo che fossero inviate direttamente dall'interfaccia utente dei loro negozi online. La situazione si è rivelata una spiacevole sorpresa, poiché fornire tale servizio richiederebbe una diversa tariffazione e, in generale, una diversa comprensione dell'API come prodotto.
- Из-за того, что API развивался не как основной продукт, документация по API производилась и публиковалась по остаточному принципу — через реверс-инжиниринг. Такой путь кажется достаточно простым и удобным, но противоречит работе по контракту. Это когда есть некий компонент с предустановленной схемой работы. Разработчик реализует его в соответствии с этой схемой и задачей, компонент проходит тестирование, клиент получает продукт, который соответствует задумке аналитика. Реверс-инжиниринг же на рынок выбрасывает продукт, который просто есть: с костылями, странными решениями и велосипедами вместо нужного функционала.
- L'intero flusso di richieste che arrivava tramite API poteva essere analizzato al massimo come un log di Nginx o di un server applicativo. Questo non permetteva di identificare le aree tematiche, a meno di suddividerle per utenti e abbonati. Senza la possibilità di regolare la registrazione delle applicazioni o dei clienti, diventa impossibile analizzare la situazione. Questo problema ha avuto un impatto minimo sullo sviluppo dell'API, si tratta più di comprendere la sua domanda e la completezza delle funzionalità.
Tentativo numero due: REST API
Nel 2010 abbiamo cercato di costruire un sistema di integrazione con un software di contabilità online — BuchSoft. Non ha avuto successo. Tuttavia, durante il processo di integrazione è emerso un API completo: un servizio REST di scambio, dove non c'erano libertà come le chiamate RPC per le operazioni. Tutta la comunicazione con l'API è stata standardizzata secondo il formato REST: nella stringa di richiesta è contenuto il nome dell'entità, e l'operazione da eseguire è specificata tramite il metodo HTTP. Abbiamo aggiunto la possibilità di filtrare in base al momento di aggiornamento delle entità, dando agli utenti la possibilità di costruire la replicazione con i propri sistemi.
Nello stesso anno è stato introdotto l'API per l'esportazione delle giacenze e dei prodotti. Attraverso l'API sono diventate disponibili per gli utenti le parti più preziose del sistema: lo scambio di documenti primari e i dati di calcolo sulle giacenze e sui costi dei prodotti.
Nel dicembre 2015, RetailCRM ha pubblicato la prima libreria di terze parti per accedere al nostro API. È stata utilizzata piuttosto attivamente, mentre la popolarità del servizio in generale cresceva, e il carico sull'API aumentava più rapidamente di quello sull'interfaccia web. Un giorno, la crescita si è trasformata in un'impennata del carico.
E questa impennata, indicata dalla freccia a sinistra, ha lasciato completamente sbalordito il server che gestisce il nostro API. Abbiamo trascorso una settimana a capire cosa stava generando quel carico. Si è scoperto che erano proprio quelle richieste trasmesse al nostro API dai fronti dei clienti. Circa 50 clienti hanno assorbito tutto. In quel momento abbiamo capito uno dei nostri errori: la totale assenza di limiti.
Alla fine abbiamo introdotto un limite al numero di richieste simultanee. Da un singolo account ora è possibile aprire al massimo due richieste contemporaneamente. Questo è sufficiente per lavorare in modalità replica per lo scambio di dati in modalità batch. Coloro che desideravano utilizzare i nostri servizi come backend erano costretti a seguire maggiormente le tariffe, poiché hanno dovuto implementare nel proprio software la gestione di più account.
Mettiamo in ordine
Già dal 2014, la domanda per l'API esistente è diventata una parte importante del business, e l'API stessa generava il più grande volume di dati nello scambio informatico con i clienti. Nel 2015 abbiamo avviato un progetto per mettere a posto l'API. Abbiamo scelto il formato JSON invece di XML e abbiamo iniziato a costruirlo sulla base delle caratteristiche emerse dalla realizzazione della versione precedente:
- Possibilità di gestire le versioni. La gestione delle versioni consente di sviluppare una nuova versione senza influenzare l'applicazione esistente e senza interrompere il lavoro degli utenti.
- Possibilità per l'utente di vedere i metadati nella risposta che riceve.
- La possibilità di scambiare grandi documenti. Quando elaboriamo un documento con più di 4-5 mila voci, questo diventa un problema per il server: transazione lunga, richiesta HTTP lunga. Abbiamo costruito un meccanismo speciale che consente di aggiornare il documento in parti e gestire singole voci di quel documento, inviandole al server.
- Strumenti per la replicazione - presenti anche nella versione precedente.
- Limiti di carico - come un'eredità degli errori commessi nella versione precedente. Abbiamo introdotto limiti sul numero di richieste in un dato intervallo di tempo, sul numero di richieste parallele e sulle richieste da un singolo indirizzo IP.
Da quel momento abbiamo rilasciato due versioni minori dell'API e lanciato diverse API specializzate, ma in generale l'approccio è rimasto invariato. Il nuovo formato di scambio e la nuova architettura hanno permesso di risolvere i difetti nell'API molto più rapidamente.
API di MoioScald oggi
Oggi API di MoioScald risolve molte attività:
- scambio di dati con negozi online, sistemi contabili, banche;
- ottenimento di dati di calcolo, report;
- utilizzo come backend per applicazioni client — le nostre app mobili e il punto cassa desktop funzionano tramite API
- invio di notifiche sulle modifiche dei dati in Moïsklad — webhooks;
- telefoni;
- sistemi di fidelizzazione.
Basato sull'API, il nostro CEO Askar Rakhimberdiev ha scritto un bot Telegram in quattro ore, che recupera tramite API i dati di magazzino:
Ora i numeri nudi.
Ecco le nostre statistiche per il vecchio REST API:
- 400 aziende;
- 600 utenti;
- 2 milioni di richieste al giorno;
- 200 GB/giorno di traffico in uscita.
Ecco a cosa siamo arrivati con tutte le API di Moïsklad:
- oltre 70 integrazioni (alcune delle quali possono essere visualizzate qui );
- 8500 aziende;
- 12.000 utenti;
- 46 milioni di richieste al giorno;
- 2 TB/giorno di traffico in uscita.
Cosa succede dopo
I piani per lo sviluppo delle API sono attivamente in discussione. Cerchiamo di tenere conto delle esperienze operative fornite dagli utenti. Non sempre riusciamo a fare tutto subito, ma non è lontana una nuova versione dell'API con metadati più comodi e una struttura meno complessa, OAuth per l'autenticazione e API per l'integrazione nelle applicazioni.
Puoi seguire le ultime novità sul sito speciale per sviluppatori sulle integrazioni con MoimSklad: .
Fonte: habr.com
