Introduction
Frontbacked lets frontend developers publish complete, data-backed website themes without turning every project into a backend project. A theme starts as the stack you already know: HTML, CSS, JavaScript, assets, and a small runtime that connects your UI to the Frontbacked platform.
The core idea is simple:
- Build your theme as static frontend files.
- Use Frontbacked Query Language (FQL) in HTML to declare state, data fetching, and DOM updates.
- Push to GitHub and publish the theme from the platform.
- Add Frontbacked Rule Language (FRL) when your theme needs stronger validation, permissions, and data protection.
What Theme Developers Build
A Frontbacked theme usually contains:
| File or folder | Purpose |
|---|---|
index.html, signup.html, signin.html, and other pages | The pages site owners and visitors will use. |
| CSS and JavaScript assets | Your design system, interactions, helper functions, and page behavior. |
skins/ | Optional CSS skin files and skins/manifest.json for alternate visual looks. |
| Frontbacked CDN script | The frontend runtime loaded from https://cdn.frontbacked.com/frontbacked.js to read FQL declarations and talk to the platform API. |
backend/index.rules | The single FRL file where the theme developer declares rules for the theme data. |
backend/paths.json | Optional FQL-friendly route mappings for clean URLs such as /blog/:slug. |
| Images, fonts, and media | Theme assets committed with the project. |
The Two Languages
Frontbacked themes are powered by two small languages.
Frontbacked Query Language (FQL) runs in the browser through frontbacked.js. It lets you declare state in the page, bind form events to state, render values into the DOM, fetch settings and posts, repeat list templates, and call auth/post APIs.
Frontbacked Rule Language (FRL) runs behind the scenes when your theme writes data. It defines which fields are accepted, what is required, who can create/read/edit/delete, how fields are normalized, and what extra writes should happen after an action.
How Publishing Works
When you connect a GitHub repository to Frontbacked, the platform processes commits for a selected theme root path. Default branch commits become production versions that site owners can upgrade to. Non-default branch commits can still be processed as preview versions so a theme developer can test them before merging.
For a developer, the practical workflow is:
- Build locally with
frontbacked-server. - Commit and push your theme to GitHub.
- Connect the repository on Frontbacked.
- Select the root path for the theme.
- Test preview versions.
- Publish production versions from the default branch.
The best path is to learn FQL first so you can build pages, forms, and dynamic UI quickly. Then learn FRL to make those same experiences safe when they start accepting user data.
For a fuller working reference, use themes/example-theme-01 in the Frontbacked repository. It contains the image, video, upload, auth, and FQL lab pages used for runtime testing.
What This Lets You Ship
A theme can stay frontend-first while still offering serious app behavior:
| Theme capability | Where it comes from |
|---|---|
| Dynamic forms, live validation, and loading states | FQL state, DOM bindings, and Frontbacked.checkState() |
| Authenticated dashboards and protected pages | FQL auth roots, f-access, and auth helpers |
| Lists, detail pages, route params, and aggregates | FQL data roots and theme routing |
| Nested post uploads with files, progress, and resume | Files API plus uploadPost and updatePost |
| Responsive images and adaptive video players | Files, Image Resizing, and Adaptive Video |
| Site-owner editable settings and visual skins | Settings bindings and Theme Skins |
| Strict data contracts and ownership rules | FRL schemas, immutable fields, and require[...] |
| Derived fields, audit records, and related writes | FRL process blocks, after hooks, and triggers |
| Delayed workflows and custom JSON routes | FRL async resolution and endpoints with idempotency |
The docs are split so you can learn in that same order: start with FQL for the page experience, then use FRL to define what the theme is allowed to store, expose, and automate.