Desenvolupar un ecommerce des de zero amb integració logística: les cinc capes i en quin ordre es construeixen

«Vull una botiga en línia feta de zero» sol voler dir «vull una botiga que faci el que les plantilles no fan». I el que les plantilles no fan és gairebé sempre el mateix: parlar amb qui fabrica, amb qui envia i amb qui cobra, sense que una persona copiï dades d'una pantalla a una altra. Aquest article explica com estructurem aquesta feina en cinc capes, què porta cadascuna i en quin ordre es construeixen. Els exemples són d'eclipseando.com, una botiga nostra que està en producció, i dels connectors de transportista que tenim publicats per a Odoo.

Les cinc capes d'una botiga

Capa 1: les dades viuen en un sol lloc

Abans de dibuixar una pantalla cal decidir on viu el catàleg. Si el client té Odoo, la resposta és Odoo: productes, preus, estoc i comandes hi són i la web els llegeix, no els copia. Si no el té, la botiga necessita la seva pròpia base de dades, i convé que sigui petita i avorrida. A eclipseando.com és SQLite, en un fitxer, amb còpia de seguretat. El que no pot passar és que el preu sigui a la web i també en un full de càlcul i també a l'ERP: als dos mesos són tres preus diferents.

Capa 2: la caixa no es refia del navegador

Dues regles que no negociem. La primera: el preu es calcula al servidor, amb el catàleg vigent, en el moment de crear la sessió de pagament. El navegador pot guardar la cistella, però no pot dir quant val. La segona: una comanda està cobrada quan la passarel·la la confirma amb un webhook signat, no quan el client aterra a la pàgina de gràcies. Amb Stripe això és checkout.session.completed amb la signatura verificada; amb altres passarel·les té un altre nom i la mateixa idea. I si en rebre el webhook falla el pas següent, es respon error perquè la passarel·la reintenti, i es guarda l'identificador de sessió per no fabricar dues vegades.

Capa 3: cada proveïdor parla com pot

Aquí és on «integració logística» deixa de ser una paraula i es converteix en feina. Un proveïdor amb API i webhook (una impremta sota demanda, un transportista gran) s'integra en els dos sentits: se li crea la comanda en cobrar i s'escolta el seu avís d'«enviat» per passar el seguiment al client. Un amb API de dropshipping s'integra en un sentit i es consulta en l'altre: abans de cobrar, la disponibilitat real per país; després, la comanda. I un sense API, que n'hi ha i molts, s'integra reduint el treball humà a un clic: el sistema produeix exactament el correu o el CSV que el proveïdor necessita, i si els seus paquets surten amb un transportista que envia correus, aquests correus es llegeixen i es converteixen en estats.

Dos detalls que només s'aprenen amb comandes reals. Un: el seguiment va per enviament, no per comanda, perquè una comanda amb dos productes de dos proveïdors són dos paquets. Dos: els terminis que diu la documentació del proveïdor no són els que compleix; es mesuren creant comandes de prova i llegint el que retorna, i aquests són els que s'ensenyen al client abans de pagar. Quan el proveïdor és un transportista i la botiga porta Odoo, tot això ja està resolt als connectors de transportista que publiquem: etiqueta, seguiment, manifest i devolució dins de l'albarà.

Capa 4: el que corre sol i el que es reintenta

Una botiga té feina que no pot dependre que algú se'n recordi: buidar la cua de correus, reintentar les comandes cobrades que no han arribat al proveïdor, llegir la bústia del transportista, sincronitzar l'estoc amb els marketplaces. Cadascuna és una tasca programada amb un interval i un registre. La regla de disseny és que cap no crida un servei extern en el camí d'una petició de l'usuari: la pàgina llegeix el que la tasca ha deixat a la memòria cau. Així, si el proveïdor cau a les tres de la matinada, la botiga continua servint pàgines i les comandes es reintenten quan torni.

Capa 5: el frontal, al final i ràpid

Amb les quatre capes de baix resoltes, el frontal és la part més agraïda. Preferim llocs estàtics generats en build (Astro a eclipseando.com) servits per nginx o Caddy: carreguen en no res, no tenen base de dades que atacar i costen el que costa un servidor petit. El dinàmic (cistella, pagament, estat de la comanda) va per una API a part. El multiidioma es fa amb una URL per idioma i textos propis, no amb un traductor automàtic al damunt, i es prova amb tests que comproven que cada plantilla existeix en tots els idiomes. I la velocitat es mesura abans de publicar: pes de pàgina, imatges a la mida en què es pinten, res que bloquegi el primer render.

L'ordre importa: de dins cap a fora

L'error més car que veiem és començar per la capa 5. S'ensenya una web bonica a la segona setmana, el client s'il·lusiona, i les capes 1 a 4 s'improvisen a sota amb pressa. El resultat funciona fins a la primera comanda amb dos proveïdors, o fins al primer webhook perdut. Nosaltres construïm al revés: primer les dades i la caixa amb els seus tests, després les integracions amb comandes de prova reals, després les tasques programades, i el frontal al final, quan ja se sap exactament què ha d'ensenyar. Triga el mateix. Es refà molt menys.

Preguntes freqüents

Enllaços útils dins de FlexigoTech

El que fem sobre això