Paul M. Jones

(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.

I.

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.

II.

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.

III.

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.)

IV.

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.”)

V.

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.

Read the Reddit discussion about this post here. They are ... illustrative.

Imagine, then, Culture A, with 10,000 enumerable cultural features. Because they are broadly shared by all, nobody is much offended by any of them, and so all of these features can be expressed as naturally in the public square as in the privacy of the home.

Now add a second culture, B, to the Venn diagram. The overlap is close, but not perfect; of the set of 10,000 properties in the first culture’s circle, the second culture shares 9,000 of them. However, because public expression is to be limited to the intersection of the two cultures’ properties, we have now, from the perspective of Culture A, reduced its freedom of public cultural expression by ten percent -- from its full set of 10,000 properties down to 9,000.

Now add a third culture to the mix (and a third circle to the diagram). Because the third culture is distinct from each of the other two, it will, necessarily, further shrink the number of properties common to all three sets -- and thus will further reduce the collection of common beliefs and behaviors that are available for public expression.

This means two things: first, that the more cultures you add to a society the narrower, not broader, the range of public expression becomes; and second, that there will be an ever-increasing disparity between private life (which is now the only place where the full range of cultural life is possible) and public intercourse (which necessarily grows more and more restricted).

Source: The Narrowing Effect Of Diversity – waka waka waka

The simplest form of moral behavior occurs when a man fights for his own survival. Of course it is selfish ... but selfishness is the bedrock on which all moral behavior starts and it can be immoral only when it conflicts with a higher moral imperative.

The next higher level is to work, fight, and sometimes die for your own immediate family. This is the level at which a mother or father dives into a flood to save a drowning child ... and it is still moral behavior even when it fails.

The next higher level is to work, fight, and sometimes die for a group larger than the unit family - an extended family, a herd, a tribe. (The traits of duty and loyalty.)

The next level in moral behavior higher is that in which duty and loyalty are shown toward a group of your kind too large for an individual to know all of them. We have a name for that. It is called 'patriotism.'

Behaving on a still higher moral level were the astronauts who went to the Moon, for their actions tend toward the survival of the entire race of mankind. As a direct result of what they did, it is now possible that the human race will NEVER die.

(Pacifists may contend that THEIR actions are on this highest moral level. They want to put a stop to war; they say so. They live in a world of fantasy. If the human race managed its affairs sensibly, we could do without war. Yes - and if pigs had wings, they could fly. I don't know what planet those pious pacifists are talking about but it can't be the third one out from the Sun. The seeds of war are everywhere; the conflicts of interest are real and deep, and will not be abolished by pious platitudes. The best we can hope for is a precarious balance of power among the nations capable of waging total war - while endless lesser wars break out here and there.)

Excerpted, and edited to condense. (Note: Heinlein is speaking of a Nation, not a State. The two might not be interchangeable.) Via The Pragmatics of Patriotism (by Robert Heinlein)

The xkcd cartoon conflates the particular and narrow protections of the 1st Amendment of the U.S. Constitution with the older, broader, more general (and, if we’re honest, somewhat nebulous) principle of freedom of speech.

It is a great mistake to imagine that these things are the same. Doing so ignores the existence of non-governmental forms of censorship, including corporate censorship (e.g. internet filtering), and popular censorship via the tyranny of the majority -- or, for that matter, the tyranny of powerful minorities!

In an open society, you personally are supposed to recognize the freedom of others to speak. Via Why I think xkcd is wrong about Free Speech – Pat Kerr – Medium

[Frank Sinatra] is idolized -- and obsessively studied and massively imitated -- not merely for the creation of art but for the creation of public self, for the confection of affect and biography that the artist projects onto the national screen.And what Frank Sinatra projected was: cool. And here is where the damage was done. Frank invented cool, and everyone followed Frank, and everything has been going to hell ever since.

In America, B.F., there was no cool. There was smart (as in the smart set), and urbane, and sophisticated, and fast and hip; but these things were not the same as cool.

The pre-Frank hip guy, the model of aesthetic and moral superiority to which men aspired, is the American male of the 1930s and 1940s. He is Humphrey Bogart in The Big Sleep or Casablanca or Archie Goodwin in Rex Stout's Nero Wolfe novels.

He possesses an outward cynicism, but this is understood to be merely clothing; at his core, he is a square. He fights a lot, generally on the side of the underdog. He is willing to die for his beliefs, and his beliefs are, although he takes pains to hide it, old-fashioned. He believes in truth, justice, the American way, and love. He is on the side of the law, except when the law is crooked. He is not taken in by jingoism but he is himself a patriot; when there is a war, he goes to it. He is, after his fashion, a gentleman and, in a quite modern manner, a sexual egalitarian. He is forthright, contemptuous of dishonesty in all its forms, from posing to lying. He confronts his enemies openly and fairly, even if he might lose. He is honorable and virtuous, although he is properly suspicious of men who talk about honor and virtue. He may be world-weary, but he is not ironic.

The new cool man that Sinatra defined was a very different creature. Cool said the old values were for suckers. Cool was looking out for number one always. Cool didn't get mad; it got even. Cool didn't go to war: Saps went to war, and anyway, cool had no beliefs it was willing to die for. Cool never, ever, got in a fight it might lose; cool had friends who could take care of that sort of thing. Cool was a cad and boastful about it; in cool's philosophy, the lady was always a tramp, and to be treated accordingly. Cool was not on the side of the law; cool made its own laws. Cool was not knowing but still essentially idealistic; cool was nihilistic. Cool was not virtuous; it reveled in vice.

Before cool, being good was still hip; after cool, only being bad was.

Much though I would like to be Frank, I might actually be more Bogart. Source: Things Worth Fighting For - ABC News

To learn six subjects without remembering how they were learnt does nothing to ease the approach to a seventh; to have learnt and remembered the art of learning makes the approach to every subject an open door.

Source: The Lost Tools of Learning

Selling is a pure popularity contest. Awards are pure popularity contests. Once you get over that, the better your friends will do and the better you will do.

...

When you want to do something with the culture, post your memes, be funny, be quick witted. That’s all that matters in this internet era. If you want to see change, it starts there.

Source: How I Use Rhetoric To Sell Books | The Writings of Jon Del Arroz

From an email conversation with a reader:

Hi Paul,

I’ve been following your writing and examples about the ADR pattern for some time now. It’s taken me awhile to wrap my head around it but ADR has really added a lot of structure to my code and I’m thankful for your work!

One dilemma that I’ve been struggling with is how to organize emails that are sent out by my service classes. Currently my business logic dictates when to send an email and most of them contain html and text templates. It just feels wrong to include those email templates within the Domain. Do you have any recommendations? Any help you can provide would be greatly appreciated.

In a somewhat related question - Recently I’ve been organizing my “views” folders within the folders of their parents (Http, Mail). I think I based it on your ADR example on github. Do you still prefer this method or do you lean towards organizing within a “resources” folder?

My intuition is that you are right to keep the email templates out of the domain.

In a way, sending an email as part of a web request/response cycle is like sending two responses: the normal HTTP response, and the email response. With that in mind, it might make sense to think of the HTML + Text email templates as part of a presentation layer. Or, as a combination of infrastructure (the email-sending client) plus presentation (the templates). That would be how to think about the separation of concerns there.

Here’s an example of what that separation of concerns might look like in a package directory structure:

resources/
    templates/
        web/
            # web page templates
        email/
            message-1/
                message-1.html
                message-1.txt
            message-2/
                message-2.html
                message-2.txt
src/
    Domain/
        AppService/
            FooAppService.php
            BarAppService.php
        EmailInterface.php
        # ... other domain classes
    Infrastructure/
        DataSource/
            # ... mappers, tables, etc
        Emailer.php # implements Domain\EmailInterface
    Web/
        Foo/
            FooAction.php
            FooResponder.php
        Bar/
            BarAction.php
            BarResponder.php

The specifics of directory structure are not important, as long as you see that the Emailer class is separated from the Domain application services (or use cases, or whatever).

The Emailer class, for its part, might be a facade [1] that coordinates between a “real” emailer (e.g. Swiftmailer or PhpMailer) and a template class, to put together and then send the email. You could configure the Emailer class with the template location (resources/templates/email/*) and inject it into your application service (which depends on the EmailInterface).

Now, sending emails inline as part of the web request might be fine in a lower-traffic situation. But as volume scales up, this kind of separation will make it easy to extract all email-sending to a workers. Then the Emailer can queue emails to the workers instead of sending them inline with the web request; the email-sending can become the job of a queue worker, and the template work will go there instead.

As far as where to put templates for views:

The extended example ADR code on GitHub is a few years old at this point. I still think it’s a reasonable setup, especially for people transitioning out of pseudo-MVC toward ADR, but it might do well to receive an update (or some examples of variations).

I don’t prefer any particular method or structure on where to put templates. Sometimes it makes sense to keep templates near the things using them, sometimes it makes sense to collect them all one place. The needs of the system, and the prior experiences of the developer(s), will be the deciding factor as far as I’m concerned. I had PHP-PDS on the brain when I replied, so the pds/skeleton with its “resources” directory was at hand.

[1] A real facade, not a Laravel one. ;-)

Read the Reddit discussion about this post here.

The cold biological truth is that sex changes are impossible. Every single cell of the human body remains coded with one's birth gender for life. Intersex ambiguities can occur, but they are developmental anomalies that represent a tiny proportion of all human births.In a democracy, everyone, no matter how nonconformist or eccentric, should be free from harassment and abuse. But at the same time, no one deserves special rights, protections, or privileges on the basis of their eccentricity. The categories "trans-man" and "trans-woman" are highly accurate and deserving of respect. But like Germaine Greer and Sheila Jeffreys, I reject state-sponsored coercion to call someone a "woman" or a "man" simply on the basis of his or her subjective feeling about it. We may well take the path of good will and defer to courtesy on such occasions, but it is our choice alone.

A wide-ranging interview. Source: Camille Paglia: On Trump, Democrats, Transgenderism, and Islamist Terror | The Weekly Standard

The fact that the two deadliest attacks upon the U.K. in recent memory were at the hands of Islamic terrorists is not simply pub trivia. I mention it because when these apologists for Islam get bored of claiming that jihadists are incessantly and inexplicably lying about their religious motivations, they invariably engage in the crass exercise of throwing around skewed data in a desperate attempt to deemphasize the danger posed by Islamic terror. this is not due to some well-meaning concern for people worrying unnecessarily, or to ensure that counter terrorism strategy is accurately focused upon the most serious threat, it seems rather to be a tactical attempt to prioritize the protection of odious 7th century folklore over the welfare of real human beings.

In the not uncommon event of an Islamic lunatic slaughtering a crowd of innocent people, Americentric articles and tweets lying about the likelihood of this happening to you, instantaneously begin to surface, like gunk from the ocean floor after a depth charge detonation.

Source: No, You’re Not More Likely to Be Killed by a Right-Wing Extremist than an Islamic Terrorist – Areo Magazine