Baserow i n8n: la font de veritat que manté la gent, no el programador

Quan vaig escriure sobre Supabase i n8n, la pregunta que ho ordenava tot era tècnica: on viu l’estat i qui el mou.

Aquest article respon una pregunta diferent, i sovint més important:

Qui manté aquesta dada quan resulta estar malament?

Si la resposta és «el programador, amb una consulta», Supabase. Si la resposta és «la Marta, que és qui sap si aquell client encara està actiu», llavors el que necessites no és una base de dades amb API. És una base de dades amb oficina.

Això és Baserow.

Les dues eines no competeixen

Val la pena tenir clara la diferència abans de triar, perquè no és de mida ni de potència:

La conseqüència pràctica: Baserow no és per a les dades transaccionals. Les comandes, els moviments i els registres d’esdeveniments van a Postgres. Baserow és per a les dades mestres: el catàleg, els actius, els clients de referència, els contractes. El que canvia poc, importa molt i necessita algú que hi pensi.

Què t’hi trobes

Baserow és programari lliure —el nucli amb llicència MIT— i es pot allotjar amb un contenidor de Docker. A sota hi ha Postgres; a sobre, una interfície que qualsevol persona que hagi tocat un Excel entén en cinc minuts.

Les peces que importen per al que explicaré:

Tipus de camp amb significat. No hi ha només text i número: hi ha selecció única amb opcions tancades, selecció múltiple, data, fitxer, valoració, durada, col·laborador, i sobretot enllaç a una altra taula. Amb count, rollup i lookup una taula pot mostrar dades calculades de les seves relacions sense duplicar-les.

L’important és que la selecció única és una restricció: si el camp Estat té quatre opcions, ningú hi escriurà una cinquena. És el mateix que un check a Postgres, però el manté qui gestiona el procés, no qui gestiona la base de dades.

Vistes com a interfície per rol. Una taula, moltes vistes. Cada vista té els seus filtres, la seva ordenació, els seus agrupaments i els seus camps amagats. Això vol dir que la mateixa taula d’actius és tres eines diferents:

• La vista «Per renovar aquest trimestre», filtrada per data, per a qui gestiona compres.
• La vista «Sense assignar», per a sistemes.
• La vista «Tot», ordenada per centre de cost, per a finances.

Cap d’aquestes tres persones ha de veure les columnes de les altres dues, i cap ha de recordar cap filtre. La vista de graella, la de galeria i la de formulari són al nucli lliure; la de kanban, la de calendari i la d’enquesta són de la capa de pagament.

Formularis públics. Una vista de formulari és una URL que qualsevol pot omplir i que escriu una fila a la taula. Sense muntar res. És la porta d’entrada més barata que existeix per a una alta de proveïdor, una sol·licitud d’equip o un avís d’incidència.

Historial i comentaris per fila. Cada fila guarda qui ha canviat què i quan, i admet una conversa al costat. Això és el que Postgres no et dona de franc i el que en un procés de dades mestres val or: quan algú pregunta «per què posa que aquest client està de baixa?», la resposta és a la fila, no a la memòria de ningú.

La superfície tècnica

Tot el que es veu a la interfície té API. Tres coses que has de saber per treballar-hi des d’n8n:

Les claus són d’abast limitat. Un database token es crea per a una base de dades concreta i s’hi marca, taula per taula, si pot llegir, crear, actualitzar o esborrar. Un flux que només ha de llegir el catàleg rep una clau que només pot llegir el catàleg.

Aquesta és una diferència pràctica important respecte de Supabase, on la clau de servei se salta tots els permisos i has de posar tu la disciplina.

curl "https://baserow.exemple.com/api/database/rows/table/412/?user_field_names=true&filter__Estat__equal=Actiu&order_by=-Actualitzat&size=200" \
  -H "Authorization: Token EL_TEU_TOKEN"

user_field_names=true no és opcional. Sense això, la resposta et torna field_5231 en comptes de Estat, i el teu flux es trenca el dia que algú toqui l’ordre dels camps. Amb això posat, els filtres també s’escriuen amb el nom visible: filter__Estat__equal=Actiu.

Un avís: els filtres sobre camps d’enllaç a una altra taula han donat problemes amb els noms visibles. Si un filtre de relació no respon com esperes, prova-ho amb l’identificador del camp abans de tornar-te boig.

Escriu per lots. La paginació torna 100 files per defecte i 200 com a màxim, i el punt final de lots accepta també 200 files per crida:

curl -X POST "https://baserow.exemple.com/api/database/rows/table/412/batch/?user_field_names=true" \
  -H "Authorization: Token EL_TEU_TOKEN" -H "Content-Type: application/json" \
  -d '{"items":[{"SKU":"A-100","Preu":19.9},{"SKU":"A-101","Preu":24.5}]}'

Escriure 3.000 files d’una en una són 3.000 crides i uns quants minuts. En lots de 200 són quinze crides. n8n té un node de Baserow per a les operacions bàsiques; per als lots, el node HTTP Request amb el node Loop Over Items configurat a 200.

Els webhooks són per lots també. A cada taula hi pots configurar un webhook cap a n8n. Els esdeveniments actuals són rows.created, rows.updated i rows.deleted —en plural— i la càrrega porta un array items i, a les actualitzacions, un array old_items amb l’estat anterior.

Aquest old_items és la peça que fa possible reaccionar a un canvi concret:

// Node Code d'n8n: només segueixen els que han canviat d'estat
const sortida = [];
for (const [i, fila] of $json.items.entries()) {
  const abans = $json.old_items?.[i];
  if (abans && abans.Estat !== fila.Estat) {
    sortida.push({ json: { id: fila.id, de: abans.Estat, a: fila.Estat, sku: fila.SKU } });
  }
}
return sortida;

Les versions singulars (row.created…) estan desaconsellades: si en trobes en un flux antic, migra’ls.

El patró: la taula de referència

Aquí hi ha la idea central de l’article, i és la resposta a «com faig una font de veritat entre l’ERP i el CRM».

L’error habitual és intentar que un dels dos sistemes sigui la veritat. No funciona, i la raó és que cap dels dos té totes les dades ni tots els permisos. L’ERP sap què s’ha facturat però no sap si el contacte encara treballa allà. El CRM sap qui és l’interlocutor però no sap si el client té deute. I hi ha un tercer grup de camps —el responsable intern, el nivell de servei acordat, si volen factura en PDF o per EDI— que no viu enlloc, i acaba en un Excel al portàtil d’algú.

La taula de referència a Baserow és el lloc on viuen aquests camps i on es resol qui té raó sobre els altres.

La matriu de propietat

Aquest és el document que has d’escriure abans de tocar res, i sol caber en mitja pàgina:

No hi ha columna de conflictes perquè no cal: el propietari és, per definició, qui guanya. Si dues fonts diuen coses diferents sobre la raó social, mana l’ERP i s’ha acabat la discussió. La columna de conflictes només seria necessària si un camp tingués dos propietaris, i això és exactament el que la matriu existeix per impedir.

Tres regles que en surten i que has de respectar sense excepcions:

1. Cada camp té un propietari i només un. Si dos sistemes poden escriure el mateix camp, tard o d’hora un sobreescriurà l’altre i ningú sabrà quan va passar.
2. Els camps de lectura es marquen com a tal. A Baserow, camp de fórmula o vista amb el camp amagat. Si es pot editar, algú l’editarà.
3. Baserow només és propietari del que no té casa. Si un camp ja el manté bé l’ERP, no el moguis. La temptació de portar-ho tot a Baserow és la manera de convertir-lo en un tercer sistema desincronitzat.

La cua de conflictes

Aquí ve la part que fa que això sigui una eina i no un mirall.

Quan els sistemes discrepen en un camp on la regla no és automàtica —un nom escrit diferent, una adreça que ha canviat a un costat—, el flux no decideix. Escriu una fila a una taula de conflictes:

Una persona obre la vista «Pendents», veu les dues versions una al costat de l’altra i tria. Un webhook de rows.updated engega el flux que aplica la decisió al sistema que toca i marca la fila com a resolta.

Això és el que separa una integració que aguanta d’una que no: les excepcions tenen un lloc on esperar i algú que les resol, en comptes de fer petar el flux o —pitjor— triar en silenci.

Els números manen a favor d’aquest disseny: el 95 % de les files se sincronitzen soles i ningú les mira. El 5 % que necessita criteri és exactament el que Baserow fa bé i el codi fa malament.

Tres casos

1. El catàleg d’un ecommerce

La botiga —Shopify, WooCommerce, PrestaShop— és bona venent i dolenta com a lloc on preparar producte. Editar 400 fitxes al seu administrador és una tarda perduda, no hi ha historial de qui va canviar què, i no pots tenir un producte «gairebé llest».

Amb Baserow al davant:

Taules: Productes, Variants (enllaçada a Productes), Proveïdors, Imatges, Traduccions.

El camp que ho canvia tot és un Estat de selecció única: esborrany → pendent de foto → pendent de text → a punt → publicat → descatalogat. El producte existeix i es treballa abans d’arribar a la botiga.

Vistes per feina:

• «Pendent de foto», per a qui fa fotografia — amb el camp de fitxer i poc més.
• «Pendent de text», per a qui redacta, amb el nom, la categoria i les característiques.
• «A punt per publicar», per a qui revisa.

Els fluxos d’n8n:

• Publicar. Webhook de rows.updated; si Estat passa a a punt, crear o actualitzar el producte a la botiga per API i escriure l’identificador retornat a la fila. La fila passa a publicat.
• Preus del proveïdor. Cada nit, llegir la llista del proveïdor, calcular el PVP amb el marge de la fitxa i escriure per lots de 200. Els que es desvien més d’un llindar no s’apliquen: van a la cua de conflictes.
• Estoc a la inversa. La botiga notifica una venda; el flux actualitza l’estoc a Baserow. Aquí Baserow no és la veritat de l’estoc en temps real —això és transaccional i va al sistema que vengui—, però sí que és on es veu quins productes cal reposar.

El resultat és un PIM que ha costat dos dies i que fa que publicar un producte deixi de dependre de qui té accés a la botiga.

2. Els actius de la companyia

Aquest cas gairebé sempre parteix d’un Excel que ningú manté, i és el que dona resultat més ràpid.

Taules: Actius, Persones, Ubicacions, Contractes (llicències, garanties, lloguers), Assignacions (l’historial de qui ha tingut què).

El detall que fa la diferència és que Assignacions sigui una taula pròpia i no un camp a Actius. Amb un camp només saps qui té l’ordinador ara. Amb una taula saps qui l’ha tingut, des de quan i fins quan, que és el que et demanaran el dia de l’auditoria.

Vistes: «Per renovar en 90 dies», «Sense assignar», «De baixa pendent de retirar», «Per centre de cost».

Els fluxos:

• Avisos de renovació. Cada dilluns, llegir Contractes amb Venciment dins dels 60 dies següents i enviar un resum a qui toqui, amb l’enllaç directe a la fila.
• Alta i baixa de personal. Un formulari públic de Baserow recull la sol·licitud; el flux crea les files d’assignació, obre les tasques als sistemes corresponents i escriu a la fila què ha quedat fet. A la baixa, el mateix a l’inrevés, amb una llista de comprovació del que s’ha de recuperar.
• Conciliació amb la realitat. Un flux mensual creua l’inventari de Baserow amb el que veu l’eina de gestió d’equips. Els que hi són a un lloc i no a l’altre van a la cua de conflictes perquè algú ho miri.

Aquest darrer flux és el que converteix un inventari en un inventari de veritat. Sense ell, qualsevol llista d’actius es podreix en sis mesos.

3. L’activitat de clients entre l’ERP i el CRM

El cas que motivava l’article, i el més delicat dels tres.

Taules: Clients (la de referència), Comptes vinculats (l’identificador de cada client a cada sistema), Activitat i Conflictes.

Comptes vinculats és una taula que la gent oblida i que resol el problema real: el mateix client és C-0042 a l’ERP i acc_9f3b al CRM. Amb una taula de correspondències, canviar de CRM demà no obliga a tocar cap identificador d’enlloc més.

Els fluxos:

• Ingesta per sistema. Un flux per origen, cadascun amb la seva clau limitada, que actualitza només els camps dels quals aquell sistema és propietari segons la matriu.
• Difusió. Quan un camp propietat de Baserow canvia —el responsable intern, el nivell de servei—, un webhook escampa el valor als sistemes que l’han de tenir.
• Detecció de discrepàncies. Nocturn: comparar els camps que arriben dels dos costats i escriure les diferències a Conflictes.
• Aplicació de decisions. Quan algú marca una decisió, aplicar-la al sistema perdedor.

I Activitat, que és el que dona sentit a tot plegat: una fila per contacte rellevant —una visita, una incidència, una renovació— amb qui, quan i el resultat. L’ERP no ho sap i el CRM ho sap a mitges. Amb això, la vista «Clients sense contacte des de fa 90 dies» és una consulta d’un segon i no un projecte.

Les cinc regles que eviten el desastre

He vist prou instal·lacions d’aquestes que han acabat malament. Sempre per les mateixes cinc coses:

1. Una taula, un concepte. La temptació de fer una taula «Coses» amb un camp Tipus és forta i sempre es paga. Si dos registres no tenen els mateixos camps, són dues taules.

2. Els identificadors no els posa una persona. Fes servir un camp UUID o autonumber com a clau tècnica i deixa que el nom sigui només per llegir. Qualsevol clau que algú pugui escriure a mà acabarà tenint espais, majúscules i duplicats.

3. Les fórmules calculen, no decideixen. Una fórmula que digui «dies fins al venciment» és perfecta. Una fórmula que digui si un client s’ha de bloquejar és una regla de negoci amagada dins d’una cel·la, i el dia que canviï ningú sabrà on és. Les regles van als fluxos, on es poden llegir i versionar.

4. Les còpies de seguretat existeixen. Baserow té paperera i instantànies, però la paperera caduca. Si t’ho allotges tu, el que has de tenir és la còpia de la base de dades Postgres de sota, i comprovada, no suposada.

5. Escriu la matriu de propietat abans del primer flux. Aquesta és la que més s’ignora i la que més cara surt. Sense ella, al cap de tres mesos ningú sap per què un camp diu el que diu.

On no arriba

Per honestedat, i perquè aquesta part decideix si el projecte és bona idea:

El volum. Baserow va bé amb desenes de milers de files per taula. Amb centenars de milers, la interfície pateix i les consultes creuades comencen a ser lentes. Els registres d’esdeveniments, l’històric de vendes i qualsevol cosa que creixi cada dia no hi van: van a Postgres, i a Baserow hi vius el resum.

Les transaccions. No hi ha manera de dir «apunta aquestes tres files o cap». Si el teu procés necessita aquesta garantia, la peça no és aquesta.

Els permisos fins. El nucli lliure té permisos per espai de treball. Si necessites que cada persona vegi només les seves files, això és capa de pagament o una altra eina.

La lògica de servidor. No hi ha res equivalent als disparadors ni a les funcions de Postgres. Tota la lògica viu a n8n, i això vol dir que si n8n cau, la lògica cau. Val la pena assumir-ho conscientment.

La sortida, que sempre s’ha de tenir prevista

Aquest és el criteri que faig servir per recomanar-lo sense por: a sota hi ha Postgres i tot té API. El dia que el volum creixi o els permisos no arribin, les dades surten per l’API o directament de la base de dades, i els fluxos d’n8n canvien de destinació sense refer-se.

Comences amb un lloc que la gent manté sense demanar permís a ningú, i si el projecte creix prou per necessitar una altra cosa, la migració és de fontaneria i no de replantejament.

Que és, gairebé sempre, la manera correcta de començar.