Fat-Free Framework (F3): a PHP micro-framework

Sources and evidence limits

It relies only on the official Fat-Free Framework 3.9 home page, and where that page is silent this guide says unknown.

What this project is

Fat-Free Framework (F3) describes itself as a PHP micro-framework for building dynamic web applications quickly. The page lists these claims:

• a full-featured toolkit,
• a code base of about 90kb,
• easy to learn, use and extend,
• a minimalist approach that avoids structural complexity.

The official wording about size and speed is marketing language. This guide does not independently confirm any performance claim.

Classification: a framework, not a runtime or CMS

F3 is a framework library that runs on top of PHP. It is not a PHP runtime, interpreter, or application server. PHP core provides the language and engine, while F3 supplies routing, caching, templating and data tools written in PHP.

It is also not a CMS. A CMS product such as Drupal ships content types, an admin interface, users and a database schema. Framework components give you building blocks and leave the product design to you. The same separation applies to runtime projects: Swoole and Open Swoole are separate projects, and neither is part of F3. The supplied source does not mention either.

Architecture and feature set

The page lists these built-in capabilities:

• high-performance URL routing,
• a multi-protocol cache engine,
• a template engine,
• multilingual (i18n) support,
• code highlighting,
• SQL and NoSQL support: MySQL, SQLite, MSSQL/Sybase, PostgreSQL, MongoDB, and its own flat-file database called Jig,
• lightweight object-relational mappers,
• DNSBL checks and traffic throttling.

It also lists optional plug-ins: a unit testing toolkit, database-managed sessions, a Markdown converter, a feed reader, an image processor, a validation helper, SMTP over SSL/TLS, and more. Community plug-ins exist as well. Each plug-in's maturity, security and PHP 8.4 behavior are unknown from the supplied source.

Execution model

The page does not describe the request lifecycle in detail. The usual shape of a micro-framework application is the classic one: a web server starts PHP for each request, an entry script loads the framework, routes are registered, one route handler runs, and the process state is discarded.

Persistent workers keep the PHP process alive across requests. The source does not say whether F3 supports them, so treat that as unknown and do not assume it.

If you ever tried a persistent worker, state leakage would be the main risk. Anything held in static properties, singletons, globals, caches or open connections would survive into the next request. Typical failures are one user's data appearing in another user's response, stale configuration, and growing memory. Cleanup would mean resetting request-scoped state at the start or end of every request, closing or validating connections, and testing two consecutive requests with different inputs. F3 is commonly used through a shared application instance, so any worker experiment would need careful review. That caution comes from general PHP practice, not from the source.

Practical use cases

Based on the page, F3 suits:

• small web applications and prototypes,
• learning routing without a large directory structure,
• projects that want one small dependency with built-in templating and data access,
• experiments with SQL, MongoDB or Jig flat-file storage.

It is a poor fit when you need a CMS with an editorial interface. A framework also does not replace your own decisions about authentication, authorization and deployment hardening. The source gives no details on those topics.

Installation approach

The page offers two paths:

• Composer: composer require bcosca/fatfree-core
• a direct download of the latest release, plus a development package with unit tests (Dev-Bench)

It also points to system requirements, changelogs and a Composer package page. The supplied text does not reproduce the requirements, so the supported PHP versions, including compatibility with PHP 8.4 and the planned 8.5, are unknown here. Check the official system requirements before you commit to a PHP version.

The example below uses Composer and PHP's built-in development server. It binds to 127.0.0.1 only. The built-in server is for local learning, not production. This is not a browser exercise: it needs a local PHP installation, Composer and network access to fetch the package.

How the example works

composer.json declares the dependency. public/index.php loads the Composer autoloader, gets the framework instance, registers two routes and calls run. The route and handler calls come from F3's public API as generally known, but the supplied page does not document them. A reviewer should confirm them against the User Guide and API Reference. Handlers write plain text, so no HTML templating is involved. The dynamic route escapes nothing because the output is declared as plain text, but real applications must handle output encoding for their content type.

Strengths

• Stated minimalism and a small code base.
• A broad built-in toolkit for a micro-framework.
• Several database backends listed, including a flat-file option.
• A Composer install path and a direct download option.
• A gentle learning curve, according to the project.

Limitations and unknowns

• Current lifecycle and support status: unknown from the supplied evidence. The page shows a 3.9 documentation selector with earlier releases, but that does not establish maintenance status.
• PHP 8.4 and 8.5 compatibility: unknown.
• License and package version constraints: not stated in the supplied text, so none are invented.
• Persistent worker support: unknown.
• Plug-in quality and security: unknown.
• Marketing statements about speed and ease are unverified.

Deployment notes

The source gives no deployment guide. In general, a classic setup puts a web server in front of PHP-FPM, with the document root pointing at the public directory and only application entry points exposed. Never expose FastCGI to the public network. Keep the vendor directory and any configuration outside the web root where possible, and confirm the official guidance before relying on this.

Where to continue

Use the official home page to reach the User Guide, API Reference, system requirements, changelogs and the Composer package page, and verify every API call in the example against them before relying on it.

{
  "name": "learnphponline/fat-free-demo",
  "description": "Minimal Fat-Free Framework demo",
  "type": "project",
  "require": {
    "bcosca/fatfree-core": "*"
  }
}

<?php

declare(strict_types=1);

require __DIR__ . '/../vendor/autoload.php';

$f3 = \Base::instance();

$f3->route('GET /', function (): void {
    header('Content-Type: text/plain; charset=utf-8');
    echo "Fat-Free Framework demo is running\n";
});

$f3->route('GET /hello/@name', function (\Base $f3, array $params): void {
    header('Content-Type: text/plain; charset=utf-8');
    $name = preg_replace('/[^A-Za-z0-9_-]/', '', (string) ($params['name'] ?? ''));
    echo 'Hello, ' . ($name !== '' ? $name : 'guest') . "\n";
});

$f3->run();

composer install
php -S 127.0.0.1:8080 -t public
curl http://127.0.0.1:8080/
curl http://127.0.0.1:8080/hello/Ada