The “Micro” Framework As “User Interface” Framework

(The following is more exploratory than prescriptive. My thoughts on this topic are incomplete and in-progress. Please try to treat it accordingly.)

tl;dr: “Micro” frameworks are better described as “user interface” frameworks; perhaps there should be corollary “infrastructure” frameworks; consider using two frameworks and/or two containers, one for the user interface and a separate one for the core application.


When we talk about “full stack” frameworks, we mean something that incorporates tools for every part of a server-side application:

  • incoming-request handling through a front controller or router
  • dispatching routes to a page controller or action (typically a class constructed through a DI container)
  • database, email, logging, queuing, sessions, HTTP client, etc.; these are used in a service, model, controller, or action to support business logic
  • outgoing-response creation and sending, often combined with a template system

Examples in PHP include Cake, CodeIgniter, Fuel, Kohana, Laravel, Opulence, Symfony, Yii, Zend Framework, and too many others to count.

When we talk about “micro” frameworks, we mean something that concentrates primarily on the request-handling and response-building parts of a server-side application, and leaves everything else out:

  • incoming-request handling through a front controller or router
  • dispatching routes to a page controller or action (typically a closure that receives a service locator, though sometimes a class constructed through a DI container)
  • outgoing-response creation and sending, often combined with a template system

Slim is the canonical PHP example here; others include Equip, Lumen, Silex, Radar, Zend Expressive, and (again) too many others to count.


I have asserted elsewhere that, in an over-the-network HTTP-oriented server-side application, the View (of Model-View-Controller) is not the template. The View is the entire HTTP response: not just the HTML or the body, but the status line, the headers, all cookies, and so on. That is, the full HTTP response is the presentation; it is the output of the server-side application.

If the HTTP response is the output, then what is the user input into the server-side application? It is not the form being submitted by the user, per se. It is not a key-press or button-click or mouse-movement. The input is the entire HTTP request, as sent by the client to the server.

That means the user interface for a server-side application is not “the HTML being viewed on the screen.” The user interface is the HTTP request and response.

Now, for the big jump:

If the user interface is the request (as input), and the response (as output), that means micro-frameworks are not so much “micro” frameworks, as they are “user interface” frameworks.

Consider that for a moment before continuing.


If it is true that “micro” frameworks are more accurately described as “user interface” frameworks, it opens some interesting avenues of thought.

For one: it means that full-stack frameworks combine user interface concerns with other concerns (notably but not exclusively infrastructure concerns).

For another: perhaps in addition to user interface (“micro”) frameworks, it would be useful to have something like a separate “infrastructure” framework. It might not even be a framework proper; it might only be a container for shared services that have no relation to any user interface concerns. (I can imagine extracting such a toolkit collection from any of the full-stack frameworks, to be offered on its own.)


Speaking of containers:

It is often the case, even with user interface (“micro”) frameworks, that developers will store their infrastructure and services objects in the framework-provided container. Or, that they will build “providers” or “configuration” for the framework-provided container, so that the container can create and retain the infrastructure and services objects.

But if it is true that the “micro” framework is a “user interface” system, why would we manage infrastructure and domain objects through a user interface container? (This a variation on “Why is your application/domain/business logic in your user interface controller?”)

Perhaps it would be better for the infrastructure and/or domain objects to be managed through a container of their own. Then that completely separate container can be injected into any user interface container. The benefit here is that the infrastructure and/or domain objects are now fully separated from the user interface layer, and can be used with any user interface framework, even one that uses a completely different container for its own user interface purposes. (This is a variation on “composition to reduce coupling.”)


To conclude:

It might be worth considering the use of two frameworks in server-side applications, each with its own container: one for the user interface concerns, and a separate one for infrastructure/domain concerns. (The latter might be composed into any user interface framework, whether one for the web or one for the command line.)

And, given that lots of application work starts mostly as infrastructure coordination, with little domain logic, having a second framework separated from the user interface makes it easier to put a boundary around the infrastructure-based application code, separating it from the user interface code. The work on each can proceed in parallel; the user interface coders can mock the results from the application layer, and build everything out on their own path, while the application coders don’t need to worry too much about presentation concerns (whether HTTP or CLI based).

Unlike some other people, I am not my code, or my books, or my blog posts. Given the tentative nature of the above essay, review and criticism (especially substantial criticism) are vital. It won’t hurt me in the least bit; indeed, I encourage it.

Thanks for reading.

UPDATE: The Reddit comments regarding this post are … illustrative.

Are you stuck with a legacy PHP application? You should buy my book because it gives you a step-by-step guide to improving your codebase, all while keeping it running the whole time.
Share This!Share on Google+Share on FacebookTweet about this on TwitterShare on RedditShare on LinkedIn

7 thoughts on “The “Micro” Framework As “User Interface” Framework

  1. My intent to create my micro framework ( was to build a presentation layer which is designed to support both HTTP and CLI. Infact it uses VC of MVC which is art of the presentation layerThe code does has some ugly code smells. I’ll refactor it to build a clean micro framwork for the presentation, in fact for the user-interface.

    If I think about a framework espcially for infrasturcture, I would use any container componet / or custom factories for IoC concerns (and don’t violating the DIP of SOLID) and then build factories for my disired components which builds the infrastructure. But their are that many componets for infrastructure out there.

    Therefore the infrastructre framework is the sum of components used by the application managed by an infrastructure specific di component.

  2. Whilst I like your general idea of separating the web concern from the business concern, I don’t think that separating containers makes sense to solve that problem. I still could expose – create a new entry – for an action in the container of my business logic. It might make more sense to use a tool like deptrac to enforce structural rules and therefore the decoupling of both concerns.

  3. inspiring thoughts, I like to describe microframeworks as a glue to tie the UI, infrastructure and the domain together, they can get input (request) process the input depending on the use case and return and outcome (response) as a result.

    For the infrastructure, I think components projects like Aura, Zend Framework, Symfony ..etc are the best fit, all we need is to build some ports and adapters to use them.

Leave a Reply

Your email address will not be published. Required fields are marked *