Rob Allen has published another post covering the use of serverless technology and PHP to run your applications. In this new post he shows how to use img2lambda to publish your Serverless PHP layer out to an AWS Lambda instance.

[The] img2lambda tool will take the layers of a Docker container and convert them to AWS layers for use in Lambda.

I poked around with Clare’s example and updated my lambda-php project in order to understand how it works. I also rewrote my runtime’s bootstrap to make it clearer.

The clever thing from my point of view is that you can build your PHP runtime layer locally using Docker and then publish the layers to AWS for use in your Lambda functions. This means you can now use the layer in different projects and have them all reference the same PHP runtime.

He digs deeper into the tool, looking at the "magic" happening under the covers using Docker. He provides an example of the Dockerfile it creates and walks through what it does. He then shows how to create the layer in AWS and use a serverless framework and a PHP runtime to execute the "hello world" application. He wraps up the post showing how to test it locally, building from the Dockerfile and using a docker run on the result with simple user input.

Rob Allen continues his series of posts covering the use of PHP on the OpenWhisk platform. In his latest post he shows how to usr Fractal as the view layer for your application (as installed via Composer). Fractal is a project from the PHP League that "provides a presentation and transformation layer for complex data output, the like found in RESTful APIs, and works really well with JSON."

When writing an API, it’s common to produce an output that conforms to a known media type such as JSON API or HAL, etc. I’m a strong believer that even though I’m writing an API, my application has a view layer. It’s not the same as building an HTML page, but you still need to separate out the code that creates the structured output from your model layer. For a couple of APIs that I’ve written recently, I’ve used Fractal for this.

He starts with some example code showing how to use Fractal to transform data that's come from his datasource. This includes both the script to use the Manager and the class defining the "transformer" for the todo data. He then moves this over and integrates it with an OpenWhisk application, making use of the dependency injection container to create transformer and manager instances. His final example shows this setup in action as the result of a call to fetch all current todo items.

Geoff Wozniak has written up a post on the "Curried lambda" site sharing his opinion on ORMs (object relational mappers) for working with databases and how, after using them in his own development work, that they're a good side benefit but shouldn't replace knowing SQL.

I've come to the conclusion that, for me, ORMs are more detriment than benefit. In short, they can be used to nicely augment working with SQL in a program, but they should not replace it.

[...] Neward, in his well known essay, lays out many cogent reasons why ORMs turn into quagmires. In my experience, I've had to deal directly with a fair number of them: entity identity issues, dual-schema problem, data retrieval mechanism concern, and the partial-object problem. I want to talk briefly about my experiences with these issues and add one of my own.

He breaks the rest of the article up into several sections, for each sharing some of his own experiences with the feature and how it could be resolved using other query methods:

• Partial objects, attribute creep, and foreign keys
• Data retrieval
• Dual schema dangers
• Identities
• Transactions

He ends the post with a look forward, thinking about where he'll end up, mentioning stored procedures, queries as APIs and how "easy" isn't always best when it comes to ORMs.

Alejandro Celaya? has a post to his site sharing some of his experience and advice about how to properly pass data from the outer layers of an app to the "use case" layer. In this situation, the "use case" layer is where most of the processing is happening (versus controllers, views, etc).

Lately, I've been digging a lot in different ways of improving software architecture. Mainly subjects like Clean Architecture, Domain Driven Design, and such.

Those topics cover a lot of advanced and complex practices, but today, I want to talk about a simpler subject. What is the best approach to pass data from outer layers of the application (actions, controllers, async jobs, CLI commands...) to services that are part of the use case layer, by taking advantage of some of the practices promoted by those subjects.

That's a task which is present in any kind of application and is very important to get properly done. You usually need to get data from different origins (a HTTP request, the input of the command line...), filter and validate it, and then use it to perform some kind of task.

He starts off by talking about some of his own previous attempts, starting with a tweet asking where filtering and validation should happen in applications. He then talks about a better approach that makes use of value objects for moving data between service layers. He then walks through a more real-world example (case study) making use of these value objects to handle a user password change.

Matthias Noback has a series of posts on his site sharing some of his thoughts around layers, ports and adapters in application architecture:

Looking back at my old blog posts, I think it's good to write down a more balanced view on application architecture than the one that speaks from some of the older posts from 2013 and 2014. Before I do, I allow myself a quick self-centered trip down memory lane.

He's posted all three parts of the series, each providing either some background on him and his previous work or principles and architecture suggestions:

• Layers, ports & adapters - Part 1, Foreword
• Layers, ports & adapters - Part 2, Layers
• Layers, ports & adapters - Part 3, Ports & Adapters

Each part includes code and/or structure suggestions to help clarify points made along the way.

The Toptal.com blog has a tutorial posted by Elvira Sheina showing you how to keep a framework project "slim" and manageable in a MVC pattern using a "layered" structure. This structure adds a few extra components to the traditional MVC design to keep functionality cleaner and easier to maintain.

Fat controllers and models: an inevitable problem for most large-scale projects based on MVC frameworks such as Yii and Laravel. The primary thing that fattens controllers and models is the Active Record, a powerful and essential component of such frameworks.

She starts by talking about one of the main issues in MVC applications - "fat" controllers. In this example the controllers contain the bulk of the logic for the application making it difficult to modify and potentially reuse in other places. This is particularly bad when the Active Record pattern is used and the problem of it violating the SRP (Single Responsibility Principle of SOLID development). Instead she promotes the idea of the "layered" design using controllers, a service layer, DTOs, view decorators and a repository layer. She then shows how to implement this kind of structure and tie each of the pieces together with code examples for each piece.

On the BitExpert.de blog there's a new post from Stephan Hochdörfer covering the enforcement of software layer dependencies with the help of the deptrac tool from Sensiolabs.

Deptrac is a tool recently announced by Sensionlabs. It helps you keep dependencies between the different layers in your architecture under better control by providing insight into the current state of the dependencies and warns you when unwanted dependencies get introduced.

He gives the commands to get the tool installed and how to initialize the repository with a default configuration file. He then provides an example using the Adrenaline framework and how the request/response relate to the HTTP handling. He includes the configuration changes to make for these relationships and, finally, how to run the analysis on your code to ensure the dependencies are correct.

NetTuts.com has posted part seven in their "Refactoring Legacy Code" series today, continuing on with the refactor of their example application to improve maintainability and testability. In this latest article they focus in on the presentation layer.

In this seventh chapter of our refactoring tutorials, we will do a different type of refactoring. We observed in the past lessons that there is presentation related code scattered all over our legacy code. We will try to identify all the presentation related code that we can and we will then take the necessary steps to separate it from business logic.

The tutorial starts with a look at the Single Responsibility Principle (part of the SOLID design principles) and how it relates to the idea of clean architecture. They continue down the path of separating out the business logic and isolating it from the presentation layer (the display* handling). They create an "Extract" class that combines the logic and presentation though combination functionality. They walk you through the code, showing the changes you'll need to make and the tests to match.

Paul Jones has a new post to his site today with his thoughts about where dependency injection belongs in the application layer structure.

James fuller asks: "any thoughts about which layer of the application we should be using a DI container like Aura.Di? Highest layer possible?" Twitter is too constrained and ephemeral for a good response, so I’ll answer that question here.

Based around his definition of a dependency injection container (and service locator), he suggests that the DI container should reside outside of the normal application structure, possibly created in the bootstrap. He also talks some about class inheritance and the use of dependencies passed through from parent to child classes (and how common practices can break this).

Joshua Thijssen has posted a walk-through of some work he's done to create a TLS decoder in PHP. TLS (Transport Layer Security) is a method for encrypting data being sent back and forth between the client and server, similar to how SSL is used.

As a proof of concept I wanted to see in how far I could decode some TLS data on the client side. Obviously, this is very complex matter, and even though TLS looks deceptively simple, it isn’t. To make matters worse, PHP isn’t quite helping us making things easy neither.

His solution (code posted here) goes through a few steps to finally get to the actual data:

• Capturing TLS data
• Gathering all the necessary fields
• From pre-master-secret to master-secret (decoding TLS_RSA_WITH_RC4_128_SHA)
• Partitioning our master-secret
• Decoding our data
• Verifying message integrity

For each step along the way he shares the relevant code and a brief description of what's happening. If you want to see the end result and try it out for yourself, check out his repository.