Hi ha un moment que tot desenvolupador de FileMaker coneix. Estàs tres scripts endins d’una rutina de sincronització. Estàs parsejant JSON a mà, fent malabars amb camps globals com a contenidors d’estat, construint bucles niats que tenien sentit a les 2pm i són il·legibles a les 5pm. La lògica funciona — amb prou feines — i ja saps que d’aquí a sis mesos ningú la tocarà. Ni tan sols tu.

Aquesta sensació no és un problema d’habilitat. És un problema d’entorn.

FileMaker és brillant. En allò que és brillant. #

Deixem alguna cosa clara abans de seguir: això no és una crítica a FileMaker. FileMaker és una eina excepcional. És un constructor ràpid d’interfícies, una capa de persistència fiable, una plataforma que permet a equips petits construir solucions de negoci reals més ràpid que gairebé qualsevol altra cosa. Dècades de solucions desplegades ho demostren.

El problema no és FileMaker. El problema és usar FileMaker com una cosa que mai va ser dissenyat per ser: un entorn d’execució de lògica complexa.

Els scripts són lineals i monolítics. La lògica de negoci es dispersa entre disparadors de script, càlculs, funcions personalitzades i paràmetres de script fins que cap fitxer individual et diu què el sistema realment fa. No hi ha ecosistema de paquets. No hi ha pipeline testable. No hi ha depuració nativa que sobrevisqui a una pila de crides complexa. Un agent de codi et pot ajudar a escriure els scripts — però els scripts segueixen sent l’eina equivocada per a la feina. Has fet que la cosa equivocada sigui més ràpida de construir, no correcta.

El reflexe #

La solució viu a FileMaker, doncs es construeix a FileMaker. Ningú ho qüestiona. Aquest és el reflexe.

El desenvolupador apreta més. Més scripts. JSON parsing més enginyós. Una altra capa d’ocurrències de taula. Més camps globals mantenint estat intermedi. S’entrega. El client està content. I dotze mesos després el desenvolupador que ho va construir — potser tu, potser algú que ho va heretar — obre aquell fitxer i sent aquell temor familiar.

El reflexe no és peresa. És lleialtat a la plataforma. Però la lleialtat a una plataforma no hauria de significar ignorar allò que la plataforma fa malament.

La inversió #

Abans d’escriure el proper script, fes-te una pregunta: aquesta lògica ha de viure aquí?

En la majoria d’escenaris d’integració — rutines de sincronització, transformació de dades, orquestració d’APIs externes, consultes geoespacials, pipelines de classificació — la resposta honesta és no. La lògica pot viure a qualsevol lloc que pugui llegir i escriure dades de FileMaker. I FileMaker, des de la versió 19, exposa una API OData neta i compatible amb estàndards que qualsevol sistema extern pot invocar.

El que significa que la teva lògica pot viure a Node. A Python. A qualsevol entorn on els agents de codi treballen lliurement, on npm i PyPI et donen un paquet per a gairebé qualsevol cosa, on escrius funcions testables, fas commit al control de versions i iteres sense barallar-te amb la plataforma.

FileMaker es converteix en allò que sempre ha estat millor sent: un magatzem de dades fiable i una superfície de disparador. La complexitat es mou a un terreny on la complexitat és barata.

Aquesta és la inversió. No un workaround. No un últim recurs. En molts escenaris, hauria de ser el primer instint.

Tres vegades que aquesta va ser la decisió correcta #

Sync amb PrestaShop — Inversió per complexitat estructural #

Sincronitzar un catàleg de productes de FileMaker amb una botiga PrestaShop és, sobre el paper, una integració directa. A la pràctica significa manejar variants de producte niades, jerarquies de categories, actualitzacions d’stock, regles de preus i resolució bidireccional de conflictes — tot a través d’una API REST amb el seu propi model de dades que es mapeja imperfectament sobre el de FileMaker.

Pots construir això en scripts de FileMaker. Molts desenvolupadors ho han fet. El resultat és típicament milers de línies de lògica de script repartides entre desenes de passos de script, amb JSON parsing manual a cada capa, maneig d’errors afegit com ocurrència tardana, i sense forma realista que un agent de codi pugui navegar-lo o estendre’l.

La versió invertida: un mòdul personalitzat al costat de PrestaShop conté tota la lògica de sincronització. Llegeix i escriu dades de FileMaker via OData. La solució de FileMaker dispara operacions i emmagatzema resultats — res més. El codi de sincronització és net, testable, i una cosa que un agent de codi pot estendre en una tarda.

Consultes geoespacials cadastrals — Inversió per absència de capacitat #

Una solució immobiliària necessitava permetre als usuaris dibuixar un polígon en un mapa i recuperar totes les propietats cadastrals dins d’aquell perímetre, filtrades per un conjunt de criteris. Útil. Potent. I completament impossible dins de FileMaker.

FileMaker no té tipus geomètric. No pot evaluar ST_Within. No hi ha índex espacial, no hi ha PostGIS, no hi ha resposta a aquesta classe de problema dins de la plataforma — i punt.

La solució: PostgreSQL amb PostGIS a l’exterior, una interfície de mapa allotjada en un WebViewer, i una API lleugera propietària connectant ambdós. FileMaker emmagatzema les propietats i l’historial de cerques de l’usuari. PostgreSQL respon a les preguntes espacials. Cada sistema fent exclusivament allò que només ell pot fer.

La inversió aquí no va ser una decisió per conveniència. El sostre de capacitat era absolut.

Classificador d’activitats CNAE — Inversió per impossibilitat d’UX #

Les empreses espanyoles han de declarar la seva activitat econòmica usant un sistema de classificació jeràrquic — el CNAE, la implementació espanyola de l’estàndard europeu NACE — amb cinc nivells seqüencials: secció, divisió, grup, classe, descripció. Per navegar-lo correctament necessites conèixer les categories de nivell superior prou bé com per descendir a través d’elles en ordre. Gairebé ningú ho fa.

La implementació a FileMaker és un patró ben conegut: llistes de valors en cascada, camps globals mantenint codis intermedi, relacions filtrant cada nivell segons la selecció del nivell superior. Es pot construir. Funciona. I produeix una interfície que els usuaris reals, especialment professionals sense paciència per a taxonomies burocràtiques, simplement no usaran.

La versió invertida: un chatbot connectat a una base de coneixement que conté les taules oficials completes del CNAE. L’usuari descriu la seva activitat de negoci en llenguatge natural. El bot retorna la cadena de classificació completa en segons. Tota la infraestructura de FileMaker — taules, llistes de valors, camps globals, relacions, cinc nivells de filtrat condicional — va ser reemplaçada per una conversa.

Només la neteja del FM ja va valer la pena.

Com és l’altra resposta #

Val la pena reconèixer un enfocament alternatiu — i un de bo. Wim Decorte i l’equip de Soliant Consulting van publicar un framework detallat per fer que el codi agèntic funcioni dins de FileMaker: skills que li diuen al model què pot fer FM, eines deterministes que assemblen XML en lloc de deixar que el model al·lucini estructura, resolució d’identitat per a navegació d’esquema. És enginyeria rigorosa i reflexiva per a un entorn genuïnament restringit.

Però nota què és: un arnès. Una inversió significativa en scaffolding construït perquè un sistema capaç funcioni dins d’un format binari tancat que no va ser dissenyat per a això.

Aquell arnès és la resposta correcta si has de treballar dins de FileMaker. La pregunta que l’estratègia d’“Inversió” planteja és si mai vas haver de fer-ho. Per a lògica d’integració — sincronització, transformació, orquestració, consultes geoespacials — la resposta sol ser no. L’arnès és la resposta correcta a una pregunta que mereix ser reconsiderada.

Què realment guanyes #

Moure la lògica fora de FileMaker no es tracta només d’escapar de la fricció. Es tracta d’arribar a un lloc genuïnament millor.

Fora, els agents de codi naveguen codebases lliurement. Llegeixen funcions, rastregen crides, proposen refactors, escriuen tests. npm i PyPI et donen un paquet per a gairebé qualsevol cosa — autenticació, lògica de reintents, operacions geoespacials, gestió de cues — sense construir des de zero. Ho versiones tot. Ho testes de forma aïllada. Pases el codebase a un altre desenvolupador i el pot llegir sense conèixer FileMaker en absolut.

El costat de FileMaker també se simplifica. Menys scripts. Menys estat. Menys fragilitat. Una superfície més neta que fa allò que FileMaker fa bé i res més.

OData és el pont en ambdues direccions — compatible amb estàndards, documentat, estable. FileMaker el publica. El sistema extern el consumeix. Les dades flueixen netament sense connectors personalitzats ni middleware propietari.

Quan no invertir #

La inversió no és per a tot.

Si la lògica és simple i les dades viuen a FileMaker, queda’t a FileMaker. Resumir un camp de notes, classificar una queixa de client, traduir un camp de text, extreure dades estructurades d’una adreça enganxada — aquestes són operacions atòmiques on una crida API surt, un resultat torna, i aterra en un camp. Net, ràpid, sense raó per afegir infraestructura externa.

La inversió és per quan la lògica desborda l’entorn. Quan et sents construint scaffolding per suportar el scaffolding. Quan el recompte de scripts puja i la mantenibilitat baixa. Quan un agent de codi necessitaria un mapa només per entendre què el sistema fa.

Allà és quan t’atures, fas la pregunta, i mous el treball a on pertany.

Tancament #

FileMaker és on viuen les teves dades i on treballen els teus usuaris.

No ha de ser on els teus problemes es resolen.