You are viewing the website for BitFrame v1. BitFrame v2.0 was released on 11-May-2020 — new documentation and website will be available soon!

Getting Started

Learn about the motivation, goals and concept behind BitFrame


What Is BitFrame?

BitFrame is a highly customizable and event driven PSR-15 and PSR-7 compatible middleware microframework for PHP that's meant to facilitate:

  1. Receiving an HTTP request;
  2. Returning an HTTP response.

It follows the PSR standards and integrates the best of existing opensource frameworks wherever possible.

Why Choose BitFrame?

BitFrame's approach of making the middleware dispatcher the core component of the framework encourages the developer to use middleware-based services that plug right-in with ease. This allows for greater flexibility especially in terms of debugging, replacements and updating. While this design pattern may not suit the needs of all projects, it certainly has its advantages for long-term and strategic ones because as they grow in complexity the underlying framework helps keep things well-organized, easy-to-manage and very simple.


At the core of our development, we've tried very hard to abide by some simple rules that we've mostly found missing in other microframeworks:

  • Be well-documented and intuitive;
  • Facilitate the developer and be nonintrusive;
  • Be free of unnecessary bloat;
  • Promote modularity to allow any component of the framework to be easily replaced;
  • Provide the flexibility of using existing PSR-15 / PSR-7 middlewares that plug right in easily;
  • Provide the ability to share variables and application data seamlessly across all the middlewares.

How It Works:

  1. We start by defining a queue of middlewares required by our application/api (such as a router, error handler, response emitter, etc.).
  2. When the application executes, it delegates the request to the queued up middlewares starting from the outermost middleware (i.e. the one you added first).
  3. This creates a chain of middlewares that are executed successively, where each middleware can manipulate the request/response before passing it along to the next one. Any middleware in the chain may choose to stop execution at any point by returning a response which would prevent any lower layers from ever seeing the request.

Visually, your application ends up at the center, and middleware is wrapped aroud it like an onion. For example, in the following illustration we can see an application wrapped with Router, Error Handling and Response Emitter middleware:

This gives us the ability to compose our application in a way that's well-organized, and easy to understand, update and debug.


Let us know if you have something to say or add