apexFMP | Methodology

A FileMaker-first UI architecture using HTML, CSS, JavaScript, and FQL

apexFMP treats FileMaker as the system of record while HTML, CSS, and JavaScript provide the user interface layer. The result is a practical architecture where data integrity, workflow, and business rules stay in FileMaker while the UI becomes modern and code-driven.

Overview

apexFMP is a FileMaker-first methodology for building modern applications using the strengths of FileMaker together with the strengths of the web stack. It treats the UI as an HTML-based presentation layer while keeping data, logic, relationships, and workflow inside FileMaker.

This is not a rejection of FileMaker; it is a way to align FileMaker with the broader software ecosystem without losing the platform's core strengths.

Why this methodology exists

Traditional FileMaker development is powerful, but it is often constrained by layout-based design, object-heavy interfaces, and patterns that do not scale well into modern web workflows.

apexFMP acknowledges that reality and intentionally separates the layers: FileMaker owns the data model and business rules while HTML, CSS, and JavaScript handle the interface and interaction layer.

Core Principle

The core principle is simple: build the UI as HTML templates, inject FileMaker data using merge variables and FQL, and render the result in a FileMaker web viewer.

Build the UI as HTML templates, store them in a central system, inject FileMaker data by merge variables, and render the final page in a FileMaker web viewer.

The architecture

apexFMP is built on a disciplined split between system authority and presentation logic. FileMaker remains the source of truth for data, workflow, rules, and relationship behavior, while the browser is used for rendering, interactivity, and presentation-layer calculations.

HTML for the UI structure
CSS for the design system and layout
JavaScript for interaction and display logic
FQL and JSON for data retrieval and payload contracts
Web viewer for the final render surface

The standards model

The methodology relies on a simple model: a UI repository for templates and a separate form-variable system that maps merge codes to FQL-driven data retrieval.

This creates clean contracts between the browser and the FileMaker engine and reduces the need for layout-specific relationship work just to support the interface.

The lifecycle of a form

Create the HTML template in a modern editor.
Store the template as a central UI asset.
Define merge variables and their FQL query source.
Load the form and resolve merge fields in FileMaker.
Render the final HTML in the web viewer.
Send user actions back through the FileMaker script bridge.

FileMaker technical patterns

FileMaker technical patterns that make apexFMP practical

The methodology is not only conceptual. It is built on specific FileMaker features that make it practical in production: FQL, Set Field By Name, Evaluate, JSON, JavaScript in the web viewer, and the web viewer itself.

FQL: query the exact data needed for a form.
Set Field By Name: map dynamic payloads to record fields.
Evaluate: execute dynamic formulas and logic.
JSON: pass structured data between FileMaker and the browser.
Perform JavaScript in Web Viewer: drive interaction from the browser side.

Why this is powerful

This model separates interface design from data integrity, enables cleaner UI architecture, improves maintainability, and creates a better fit with modern web tools, Git workflows, and code review.

It also reduces the tendency to overuse FileMaker-only relationship patterns for presentation concerns.

Benefits over traditional FileMaker development

Traditional FileMaker development is often layout-driven and visually coupled to the data model. apexFMP shifts the interface toward modern code-based authoring, improved reusability, and cleaner separation of concerns.

Better UI control
Stronger code review and versioning
Cleaner data contracts
Broader hiring flexibility
Better long-term maintainability

Advanced considerations

The most mature form of apexFMP moves the UI into a version-controlled source model and treats the front end like a modern software artifact rather than a rigid set of FileMaker objects.

This aligns the platform with the broader software stack while keeping FileMaker central to data integrity, rules, and workflow.

Git, pull requests, and alignment with the web stack

Once the UI is authored as HTML, CSS, and JavaScript, the project begins to behave like a modern application with code review, branching, and a conventional engineering workflow.

This is a major advantage because FileMaker no longer has to sit apart from the rest of the engineering ecosystem. It can participate in a more familiar, more maintainable, and more scalable development process.

Final summary

apexFMP is a FileMaker-first methodology for building modern applications without abandoning the strengths that FileMaker brings to data, process, and workflow automation.

It is a practical model for teams who want the modernity of web-native UI engineering while preserving FileMaker as the authoritative system of record.

A practical summary of the method

apexFMP combines FileMaker workflow and data control with web-native UI delivery. FileMaker remains the transactional core, while HTML templates, JSON payloads, and JavaScript-driven rendering provide the presentation layer.

FileMaker remains the model, workflow, and transactional engine.
HTML is the form template and presentation layer.
CSS governs consistency and visual control.
JavaScript handles interaction and presentation calculations.
FQL and merge variables form a clear data contract.
The web viewer renders the final user experience.

Benefits at a glance

UI development is faster and more modern.
FileMaker layout mode is no longer the primary UI authoring tool.
Front-end design scales better through code and AI tooling.
A central UI table replaces scattered layout management patterns.
Data contracts become explicit and maintainable.
Forms are easier to reuse and version over time.
FileMaker remains strong for integrity and process control.
The web viewer becomes a full rendering runtime.

Short definition

A FileMaker-driven HTML front-end architecture where templates are authored as HTML, dynamic content is injected via merge codes, FileMaker supplies data through FQL, and the final experience is rendered in a web viewer.