Giel Bildwelten

Mit FileMaker durchsuchbare Daten im Internet veröffentlichen

Viele Unternehmen, die FileMaker einsetzen, haben ihre Daten bereits gepflegt,
strukturiert und aktuell – in FileMaker. Was fehlt, ist ein einfacher Weg,
diese Daten sauber im Web zu präsentieren. Ohne eine zweite parallele
Datenhaltung, ohne CMS, ohne einen Entwickler, der eine Serveranwendung wartet.

Genau das war mein Ausgangspunkt bei einem konkreten eigenen Projekt – und das
Ergebnis ist ein Architekturprinzip, das weit über das ursprüngliche Projekt
hinausgeht.


Das Projekt: Bildarchiv ohne Piwigo

Mein öffentliches Bildarchiv lief jahrelang auf Piwigo – einem etablierten Open-Source-System für Bildgalerien.

Gepflegt wurde das Archiv parallel in FileMaker, die Daten wurden also doppelt
gehalten. Piwigo brauchte regelmäßige Updates, eine Datenbank auf dem Server
und eine PHP-Umgebung.

Ich habe das System komplett abgelöst. Was heute läuft, ist schlanker, schneller, sicherer – und lässt sich mit ein bis zwei Skript-Schritten aktualisieren.


Wie es funktioniert

Das System besteht aus zwei klar getrennten Teilen.

FileMaker als Datenzentrale

Alle Pflege, Verschlagwortung und Verwaltung läuft lokal in FileMaker Pro –
so wie bisher. Ein Skript exportiert die Daten vollautomatisch als JSON-Datei.
FileMaker muss nichts vom Web wissen, der Webserver muss nichts von FileMaker
wissen.

Statische Website als Ausgabe

Auf dem Webserver liegen genau drei Dateien: eine HTML-Datei, eine
JavaScript-Datei, eine JSON-Datei. Keine Datenbank, kein PHP – nur normaler
Webspace. Der Browser lädt die JSON-Datei einmalig – und führt danach alle
Suchen vollständig lokal aus, ohne eine einzige weitere Abfrage an den Server.
Einzig die Bilder werden natürlich vom Server live übertragen.

FileMaker (lokal)
  |
Skript exportiert → bildarchiv.json
  |
liegt auf dem Webserver
  |
Browser lädt JSON einmalig
  |
Suche läuft im Browser
  |
kein Server beteiligt

Der Update-Prozess: FileMaker-Skript ausführen, fertig.

Aktuell habe ich den Update-Prozess in zwei Schritte aufgeteilt:

Upload der Bilder

Von den Bildern gibt es auf dem Webserver zwei Versionen: eine kleine Vorschau
mit 300 Pixel für die Übersicht und eine 1000-Pixel-Variante für die
Detailansicht. Beide Ausgabegrößen lassen sich mit FileMaker-Bordmitteln
erstellen. Zusätzlich bekommt das große Bild noch ein Wasserzeichen – dieses
erstelle ich, ebenfalls in diesem Skriptschritt. Der Upload
auf den SFTP-Server erfolgt ebenfalls vollautomatisch in diesem Schritt. Im
Datensatz wird dann noch die URL zum Bild gespeichert, für eine eindeutige
Zuordnung und den anschließenden JSON-Export.

Export der Metadaten

Hier habe ich mich dazu entschieden, bei jedem Update nicht nur einzelne
Änderungen zu exportieren, sondern die aktuellen Daten aller Datensätze
einzusammeln. Der Export von über 80.000 Metadaten dauert zwar wesentlich
länger, ich habe jedoch den Vorteil, dass immer alle Datensätze den aktuellen
Stand haben. So muss ich in meiner Datenbank nicht kompliziert Änderungen
tracken, um diese bei einem Export aufwändig zusammenzusuchen. Und da ich
nicht mehrmals am Tag aktualisiere und das Skript als Serverskript läuft,
spielt die Dauer dabei für mich keine Rolle.


Was das konkret bedeutet

Performance

Klassische Webanwendungen fragen bei jeder Suche eine Datenbank ab:
Browser → Server → Datenbank → Server → Browser. Dieses System macht nach dem
ersten Laden: Browser → fertig. Die Suche über den gesamten Datenbestand
dauert Millisekunden.

Sicherheit

Es gibt keine angreifbare Serverkomponente. Keine Datenbank, kein
Login-System, kein PHP. Die Angriffsfläche ist praktisch null.

Allerdings liegen alle Daten öffentlich auf dem Webserver. Die Metadaten, URLs
und die Bilder sind öffentlich zugänglich. Das kann ich verschmerzen, da ich
will, dass meine Bilder gefunden werden, und ich ohnehin nur kleine Dateien
mit Wasserzeichen verwende. Bei diesem schlanken Ansatz sollte man sich darüber
jedoch im Klaren sein.

Betriebskosten

Normaler Webspace für wenige Euro im Monat reicht vollständig. Keine
Datenbanklizenzen, keine Server-Software, keine Sicherheitsupdates für
serverseitige Komponenten.

Wartung

Datenpflege läuft wie gewohnt in FileMaker. Es muss nichts konfiguriert,
nichts geupdatet, nichts überwacht werden.


Das eigentliche Potenzial: weit über Bilder hinaus

FileMaker wird zum vollständigen Redaktionssystem für statische Webanwendungen.
Alles, was sich in FileMaker pflegen lässt und öffentlich zugänglich sein soll,
kann mit diesem Ansatz durchsuchbar ins Web gebracht werden:

In jedem dieser Fälle gilt dasselbe Prinzip: FileMaker kennt die Daten. Der Browser zeigt sie an und macht sie durchsuchbar. Der Webserver ist nur der Speicherplatz.


Was FileMaker hier leistet, das andere nicht können

Keine Doppelpflege – FileMaker ist und bleibt die einzige Quelle. Kein
WordPress, kein Typo3, kein Contentful. Kein Hosting-Paket mit Datenbank,
kein Agenturvertrag für Updates. Kein technisches Wissen nötig für den
laufenden Betrieb nach der Einrichtung.

Wer seine Daten bereits in FileMaker hat, zahlt nicht für ein zweites System.
Er nutzt einfach das, was schon da ist.


Die ehrlichen Grenzen

Das Konzept ist nicht für jeden Anwendungsfall die richtige Wahl. Das sollte
man wissen:

Für alles, was diese Grenzen nicht berührt – und das ist ein sehr großer
Bereich – ist es eine extrem schlanke, günstige und wartungsarme Lösung.


Interesse an einer ähnlichen Lösung?

Wenn Sie FileMaker im Einsatz haben und Daten strukturiert im Web
veröffentlichen möchten, sprechen Sie mich gerne an. Ich zeige Ihnen, ob und
wie dieses Konzept für Ihren konkreten Fall passt.

Mehr zu FileMaker & Workflow

Telefon: 0171 837 87 58

oliver@giel-bildwelten.de

© Oliver Giel | oliver@giel-bildwelten.de | Telefon: 0171.8378758

Auf dieser Seite werden keine Cookies oder andere Analysetools eingesetzt. Für die Pflege wird ein selbstentwickeltes CMS-System auf Basis von FileMaker Pro verwendet.

Gehostet wird die Seite von walkingtoweb in der Schweiz.