Millor estructura del codi: treballant amb pods

Normalment organitzem les nostres apps de javascript segons què són o segons què fan. La primera opció és com rails: directoris separats com components, containers, reducers, etc. I la segona és més o menys com feature/DDD: user, cart, i així. Encara que ambdues opcions són molt esteses i sòlides contenen certes limitacions.

Quan estructures l’arbre de fitxers del codi segons què són tendeixes a mantenir cada component d’una mateixa feature tan distant que resulta molt difícil connectar les peces. Per tant, caus en alguns problemes com l’infern de les rutes; un munt de require('../../../etc') al teu codi. I tot queda extremadament acoblat a l’estructura de directoris.

D’altra banda, quan et guies segons què fan tot està més aïllat i és més mantenible. Però hi ha molta duplicació. I la comunicació entre les features o bé es basa en un contracte feble o bé depèn d’alguna infraestructura. Ambdues opcions són propenses a generar bugs.

Els pods són una evolució de la segona opció. Pots pensar en els pods com els microserveis de les aplicacions front. Un pod és una microapp aïllada i completament independent que es pot comunicar 100% amb altres pods. Per tant, obtens una base de codi que és composable, extensible, reutilitzable i extremadament fàcil de testejar. Tot i això, el principal benefici és que elimines completament els efectes secundaris entre components. Quan un pod falla, tens la certesa total de que és perquè ell mateix té algun problema; no una peça externa.

Un pod és una microapp aïllada i completament independent que es pot comunicar 100% amb altres pods

L’únic requisit dels pods és canalitzar tota la intercomunicació dels pods a través d’un event bus. Si ja estàs utilitzant algun patró, llibreria o framework de Flux serà molt fàcil dirigir aquesta comunicació al dispatcher; que en realitat és un punt únic per als events.

Un pod no té l’obligació de tenir les capes de lògica, presentació i comunicació. Pot tenir totes o només una d’elles. Imagina un pod de router. Té la capa de lògica i comunicació però no exposa cap vista. O al contrari, un pod de formulari que només exposa una capa de presentació i depèn 100% dels arguments rebuts (mira els props de React).

Com que cada pod actua com una aplicació independent, col·loquem els tests dins d’ells. Això significa dues coses: deixar de duplicar l’arbre de fitxers, i fer que la cobertura de codi sigui significativa. Quan tens un 100% de cobertura amb un pod saps que no fallarà. Sense efectes secundaris.　

En resum, treballant amb pods obtens una estructura segura i molt flexible. Molt fàcil de testejar i sense efectes secundaris. Escala de 0 a milions sense preocupar-te de grans refactors, pel fet que cada pod està aïllat però disponible per comunicar-se amb tots els altres pods.

En cas que vulguis veure codi, aquí tens un repositori de Github amb una arquitectura de pods senzilla. Fes-hi un cop d’ull i comprova els beneficis que poden oferir els pods. Si tens algun dubte o proposta no dubtis a obrir un issue o comentar aquí. Aquest és un patró viu. Estem utilitzant els pods a Ulabox i estan demostrant ser la solució a molts problemes estructurals de la base de codi. Tot i així, estem disposats a escoltar les teves opinions i inquietuds.

El viatge és llarg, agafa alguns pods.