Warum es Fóir gibt
Acht Jahre Softwareentwicklung für andere und in fast jedem Projekt dieselbe Lücke. Ein Content-Management-System bringt Sie ein gutes Stück weit. Der Teil, den es nicht abdeckt, ist der, in den das Budget fließt.
Es begann als Kundenarbeit
Fóir stammt aus einem Studio, das Software für Kunden liefert. Die Produkte unterschieden sich von Projekt zu Projekt. Darunter brauchte jedes dieselben Teile: Inhalte, die eine Redakteurin oder ein Redakteur ohne Entwickler ändern konnte, Daten, die bestimmten Nutzern gehörten, Anmeldung, Dateispeicher, geplante Aufgaben und Regeln darüber, wer was sehen durfte.
Wir haben diese Teile in Projekt um Projekt gebaut, und jedes hat uns etwas darüber gelehrt, wie sie zusammenpassen sollten. Nach genügend Projekten änderten sich die Muster nicht mehr, und es ergab immer weniger Sinn, sie für jeden Kunden neu zu bauen.
Die letzten zehn Prozent
Ein fertiges CMS erfüllt die Anforderungen fast. Dann kommt der Teil, den es nie leisten sollte: der angemeldete Bereich, die Inhalte, die sich je nach Kunde unterscheiden, der Workflow, der in ein anderes System greift.
An diesem Punkt gibt es drei Wege weiter, und jeder kostet. Zwei Systeme betreiben und die Integration dazwischen schreiben. Das Backend bauen und ein CMS eines Drittanbieters daneben anflanschen. Oder das Backend bauen und die Bearbeitungswerkzeuge nachbauen, die das Team schon kannte. Wir haben alle drei mehr als einmal angeboten, und keines davon ist das, was jemand kaufen wollte.
Ein Agent baut es jedes Mal neu
Günstigere Entwicklung hätte diesen letzten Teil bezahlbar machen sollen. Sie hat ihn häufig gemacht. Ein Agent, der eine Anwendung bauen soll, setzt in jedem Projekt dieselben fehlenden Teile zusammen: Anmeldung, eine Datenbank, Dateispeicher, Berechtigungen, eine Job-Queue. Die meisten davon sind sicherheitskritisch, und man vertraut darauf, dass er jedes davon jedes Mal richtig verbunden hat, in einer Codebasis, die niemand von Anfang bis Ende gelesen hat.
Mit Fóir kommen diese Teile bereits verbunden an, und wir betreiben sie. Der Agent schreibt, was Ihrem Produkt eigen ist, auf einem Backend, dessen Zugriffsregeln er nicht weglassen kann.
Die Fehler in diesem Code sind Abwesenheiten
Die Fehler in einem zusammengesetzten Backend sind leise: eine Prüfung auf einem Pfad, den niemand ausgeführt hat, eine Abfrage, der eine Klausel fehlt, ein Schlüssel, der weiter reicht als die Person, die ihn hält.
Zu etwas, das nicht da ist, kann man sich kein Vertrauen erlesen. Was funktioniert, ist ein System, in dem die Prüfung nicht weggelassen werden kann. In Fóir werden die Zugriffsregeln in die eigene Row-Level Security der Datenbank kompiliert, sodass eine Abfrage, die eine Prüfung vergisst, nur zurückgibt, was ihr Aufrufer sehen darf, und eine neue Tabelle unsere Tests nicht besteht, bis jemand entschieden hat, wie sie geschützt wird. Die Engine, die das Kompilieren übernimmt, ist Demesne, und sie ist Open Source.
Wir bauen selbst darauf auf
Fóir ist die Grundlage, von der aus wir unsere eigene Arbeit beginnen. Diese Website läuft darauf, und dort werden unsere neuen Kundenprojekte ausgeliefert. Die Entscheidungen, die wir früher bei jedem Build neu getroffen haben, etwa wie Inhalte modelliert werden und wie die Daten eines Nutzers seine bleiben, sind einmal getroffen und bleiben bestehen.
Ein Backend muss betrieben und nicht nur geschrieben werden, deshalb ist Fóir ein verwalteter Service. Der Teil davon, der entscheidet, wer Ihre Daten sehen darf, ist für jeden zum Lesen veröffentlicht.
Also haben wir das gebaut, für das wir immer wieder Angebote geschrieben haben
Jedes Projekt hat dafür bezahlt, dieselbe Grundlage noch einmal bauen zu lassen.
Fóir ist diese Grundlage, für Sie betrieben: strukturierte Inhalte und Anwendungsdaten in einer Runtime, mit gehosteter Anmeldung, Medien, Personalisierung, Automatisierung und einer erzeugten API, die bereits zusammengeschaltet sind. Sie beginnen mit Ihrer eigenen Geschäftslogik.
Was es ersetzt
Die Abonnements und Build-Projekte, die es ersetzt, an einem Ort und auf einer Rechnung.
Ein Headless-CMS
Die Redaktionsoberfläche, das Schema, die Entwürfe und der Versionsverlauf.
Ein Auth-Anbieter
Anmeldung für Ihre eigenen Nutzer, auf Ihrer eigenen Domain, mit den dazugehörigen Rollen.
Speicher und ein CDN
Uploads, Bildtransformationen, Video-Streaming und die Auslieferung davor.
Ein Suchdienst
Volltext über Ihre Datensätze und Vektoren für den Abruf nach Bedeutung.
Ein Job-Runner
Zeitpläne, Hintergrund-Operations, Wiederholungen und ein Ort, an den Fehlschläge gehen.
Ein Messaging-Anbieter
Transaktionale E-Mails, In-App-Nachrichten und Push, mit Präferenzen pro Kunde.
Die Integrationsschicht
Der Code, der diese sechs sonst zusammenhalten würde, und der Drift zwischen ihnen.
Die Leute, die es patchen
Es gibt keinen eigenen Server, den Sie aktuell halten müssten, und kein Upgrade-Wochenende.
Prüfen, ob es standhält
Jede Fähigkeit und die Vergleiche, in denen wir klar sagen, zu welchem Werkzeug wir stattdessen greifen würden.