WebFluid Documentation
This is the first public alpha of WebFluid. The core runtime, the CLI, the Additive system and the full battery set are in place. APIs are settling but may still shift before the stable release, so pin your version while the alpha runs.
New Features
Integrated runtime orchestration
Your application has its own lifecycle, going through startup and shutdown hooks
as well as the serving stage entirely self-managed. It all initiates by calling
just fluid.mix() (assuming fluid = Fluid(__name__)).
Additive module system
Build features as self-contained sub apps with their own routes, templates and static
files. Base Additives can be extended, and a manifest.json declares id,
version and requirements for Hub distribution.
CLI-first workflow
The wf CLI scaffolds projects, manages Additives and runs the
config-driven runtime. Features and modules toggle through env flags.
Bundled Node and Tailwind
A single (dev) server drives SSR Jinja2, API-only modules, or parallel Vite based frontends. Standalone Node and the Tailwind CLI download on first use if necessary. The Framework orchestrates them for you.
HMR across frontend modules
Hot module replacement runs more or less cleanly across multiple frontends. An integrated proxy utility manages the communication between the frontend and the Vite dev server.
Batteries: mailer, JWT, i18n, cache, migrations
A built-in mailer, a JWT manager with rotating cached secrets, db-backed and runtime-cached i18n, a cache that swaps between in-memory and Redis behind one API, and migrations wired to the SQLAlchemy extension.
Async-first runtime with sync counterparts
Every battery exposes an async API and a matching synchronous one. The SQLAlchemy
extension, for example, gives you both executor() and
async_executor() over the same bind set.
Fix Fixes
This is the first public release, so there are no prior bugs fixed.
Bug Known issues
Interactive Runtime
The built-in interactive runtime wf run [app] --interactive does not
work properly on NT based systems due to process management issues.
Version representation
Currently version resolving and representation is not able to handle pre-release stages and builds. Version requirement checks of Additive manifests (especially framework version declarations) may fail on startup.
Static serving
Fluid itself requires a static folder to work, since it has no auto detection to skip the StaticFiles setup on initialization. In this version only Additives do have optioned setup of StaticFiles based on the existence of the static folder.
Break Breaking Changes
This is the first public release, so there is no prior version to break against. As an alpha, APIs may still change between alpha builds. Watch this page on each release for the running list of breaking changes.