Il nostro sviluppatore consiglia Python per l'API: è una scelta solida o solo una questione di abitudine?

Sfruttando le moderne strutture asincrone di Python non avrete alcun collo di bottiglia sui trasferimenti dati I/O bound. Anche se il traffico di una piattaforma B2B dovesse salire a decine di migliaia di richieste al minuto, se gli indici del database sono fatti bene il vero carico finisce sul DB, non sul linguaggio. Preoccupazione infondata.

Sul nostro servizio di logistica e-commerce gestiamo 1,5 milioni di chiamate API al giorno con microservizi basati su Python. La spesa mensile per i server cloud non supera i 65 dollari. Non date retta al mito del linguaggio lento, i veri costi arrivano da una cattiva architettura.

La preferenza dello sviluppatore conta, certo, ma se domani questo dev lascia il team che fate? Il bacino di programmatori Python è vasto, ma non tutti sanno scrivere architetture asincrone pulite. Assicuratevi assolutamente che il progetto sia strutturato a livelli e che ci sia un type checking rigoroso, altrimenti il passaggio di consegne diventerà un incubo totale.

Fate inserire queste 3 clausole tecniche nel contratto: 1) Documentazione di tutti gli endpoint con schema OpenAPI standard. 2) Uso completo dei type hint. 3) Copertura degli unit test di almeno il 70 percento per gli scenari principali. Finché queste tre condizioni vengono rispettate, Python non lascia rischi alle spalle.

per la leggibilità del codice python è un'ottima scelta... se in futuro inserite un nuovo dev nel team, ci metterà al massimo un paio di giorni a capire il progetto. con linguaggi più complessi ci vogliono settimane.

Indipendentemente dalla scelta dell'architettura software, vi consiglio di chiarire le clausole sulla proprietà intellettuale e sul codice sorgente. Per la vostra tutela legale è essenziale che il codice sorgente risieda in un repository privato di proprietà della vostra azienda e che vengano verificate le licenze di eventuali dipendenze di terze parti.

Fate una sola domanda al vostro sviluppatore: 'Quale architettura e quale framework asincrono utilizzerai e come gestirai il connection pooling del database?' Se riesce a rispondere senza esitazioni fornendo motivazioni tecniche chiare, potete procedere in tutta tranquillità.

Tre anni fa, nella piattaforma che ho fondato, su consiglio del team scegliemmo un sistema molto di nicchia perché 'sarebbe stato velocissimo'. Sei mesi dopo il programmatore principale se ne andò e non trovammo nessun altro che conoscesse quel linguaggio. Alla fine abbiamo dovuto riscrivere tutto da zero in Python e abbiamo finalmente tirato un sospiro di sollievo.

Racconto cosa mi è successo, magari vi è utile. Chiunque abbia fretta su sviluppo api si blocca nello stesso punto.

Scrivo questo per evitare che facciate lo stesso errore. Cercare di farlo da soli è la strada più costosa.

Quando prendi una decisione, guarda prima quali dati hai a disposizione. Spero che le sia utile.

Sono una piccola impresa, vi parlo dal mio punto di vista. Le persone difendono le abitudini, non i processi. La resistenza nasce da lì.

Buon lavoro.

Argomento molto attuale.

Questo consiglio non va bene per tutti, secondo me. L'offerta più economica è spesso quella meno ponderata.

Spero che le sia utile.

La discussione si è dispersa, la riassumo. Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

Se scrivete qui il risultato, sarà utile anche ad altri.

su questo punto non sono d'accordo. onestamente se è la priam volta inizia in piccolo il ridimensionamento viene dopo.

naturalmente cambia se la vostra situazione è diversa.

Vi spiego come si fa in pratica. Nei sistemi ereditati, la cosa più costosa sono le dipendenze sconosciute.

È tutto, scusate se mi sono dilungato.

Riassumo l'argomento perché sono state date diverse risposte. Nei sistemi ereditati, la cosa più costosa sono le dipendenze sconosciute.

Se non lo rendete scritto fin dall'inizio poi nascono discussioni. Lascio una nota, potrebbe servire.

Ottimo lavoro.