Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Jen Segers:
Goodbye controllers, hello request handlers
Sep 26, 2017 @ 11:12:21

In a post to his site Jen Segers says "goodby to controllers" in favor of request handlers. Request handlers are a concept similar to the ideas in the ADR pattern but are defined a bit differently.

If you have worked on large applications before, you might have noticed that you end up with bloated controllers sooner or later. Even if you use repositories or service classes to extract logic from the controller, the amount of dependencies, methods and lines of code will grow over time.

Let me introduce you to request handlers. The concept is very simple, yet very unknown to a lot of PHP developers. A request handler is basically a controller, but limited to one single action.

He suggests using invokable classes to build out request handlers in your PHP code, making use if the magic __invoke method to make them callable. He gives a "hello world" kind of example and talks about how Laravel and Slim already implement this idea in their routing. He then looks at how these responders help you adhere to the Single Responsibility Principle (part of SOLID) and how they make the code easier to test and simpler to refactor.

tagged: controller request handler invokable class example tutorial

Link: https://jenssegers.com/85/goodbye-controllers-hello-request-handlers

Laravel News:
Learn How to Send an Email on Error Exceptions
Apr 18, 2017 @ 10:25:03

On the Laravel News site there's a quick tutorial posted showing you how to send an email when an exception is thrown in your Laravel-based application using the "mailable" functionality.

You’ve created a new Laravel app for your client and deployed it on the production server. Everything was working fine till a customer has a problem with the app because of some buggy code. He immediately leaves the app, and the same thing happens with multiple customers before you know about the bug. You fix the bug, and then everything is on track.

But what if you were notified immediately through e-mail (or another service) about the bug and you fix it ASAP. In Laravel, this can be done easily and in this post, we’re going to learn how.

The post talks about how errors and exceptions are handled in Laravel applications and how, with a bit of custom code, you can create you own handler and a "mailable" class it can use (an ExceptionOccured mailer) to send a full stack trace when an error is thrown. There's also a link to a package that can be installed that helps to make setup even easier.

tagged: send email laravel exception tutorial mailable handler

Link: https://laravel-news.com/email-on-error-exceptions

Master Zend Framework:
Whoops, I Forgot The Error Handler
Sep 21, 2016 @ 12:57:32

The Master Zend Framework site has posted a new tutorial for those out there looking for a bit more from their error handler than just some basic text. In this tutorial Matthew Setter introduces you to the Whoops error handler and how to use it in your Zend Expression application.

Ever experienced HTTP 500’s, but found that your error logs are empty. Ever had no clue why or how this could be happening? Perhaps you forgot to enable the Whoops error handler.

That’s right, perhaps, when you were setting up a Zend Expressive application, you made the mistake which I made recently when you used the Zend Expressive Skeleton Installer. [...] If you chose n, and used a templating engine, then TemplatedErrorHandler, would have been used as PHP's default exception handler.

As a result, no exceptions will be written in your logs. Sure, you’ll see that a 500 error has occurred somewhere in your application. But, the only information you’ll have is [a simple 500 error message].

He notes that the next step for most developers is the log files, trying to find a hint there of what might have broken. If you chose the default logger, nothing will be there as it captures those issues and pushes them to the basic error template (but doesn't output them). He points to where in the configuration you can check to see if you enabled the Whoops error handler and how to test it after you've made the switch. The reason the default is the basic message is that, in production, you don't want information exposed and log messages/code shown to just anyone - that's a big security risk.

tagged: whoops error handler zendexpressive enabled tutorial output

Link: http://www.masterzendframework.com/whoops-errorhandler/

Loïc Faugeron:
Mars Rover, Locating handler
Sep 21, 2016 @ 10:39:30

Loïc Faugeron continues his "Mars Rover" series of posts today with the latest in the series covering the "Locating" handler, the functionality responsible for handling requests for the rover's location.

In this series we're building the software of a Mars Rover, according to the following specifications. It allows us to practice the followings: Monolithic Repositories (MonoRepo), Command / Query Responsibility Segregation (CQRS), Event Sourcing (ES) and Test Driven Development (TDD)

We've already developed the first use case about landing the rover on mars, and the second one about driving it. We're now developing the last one, requesting its location

He makes use of the command bus pattern to create the handling for the module, doing validation in the Command object and a Bus to handle the command and perform its task. He starts, as usual, with the phpspec tests defining a class that can use a "find latest location" type instance and a "find" method to abstract out the location repsonse.

tagged: mars rover tutorial series location handler phpspec

Link: https://gnugat.github.io/2016/09/21/mars-rover-locating-handler.html

Alejandro Celaya:
Creating a content-based Error Handler for Zend Expressive
Jul 29, 2016 @ 09:26:38

In a post to his site Alejandro Celaya shares a method he worked up for creating a content-based error handler in Zend Expressive - a method of changing the error output based on the content it was passed and the Accept header provided.

In one of my tests of the REST API I saw that when an error occurs (404, 405 or 500), I was getting an HTML response, which is not easy to handle when the client is expecting JSON.

I started to dig on how to fix this problem and thought that using ErrorMiddleware (which is invoked in case of an error) should be the solution, but after some tests I saw that it is only invoked if a regular middleware invokes the next one by passing an error as the third argument or an uncaught exception is thrown. When a route is not matched (404) or it is matched with an incorrect HTTP method (405), the error middleware is not invoked.

After confirming (on Twitter) that this was the intended result he went about looking for another option. He looked into using "Final Handlers" that are called when nothing else matches in the middleware execution chain. They didn't provide one for JSON handling, however, so he had to create his own (code is included in the post) and explains a bit of how it's handling the data and HTTP response code. Unfortunately using this handler made the error output always return JSON so another piece was needed, the content-based detection handler that switches between types based on the Accept header.

tagged: content error handler zendexpressive tutorial json output

Link: http://blog.alejandrocelaya.com/2016/07/29/creating-a-content-based-error-handler-for-zend-expressive/

Loïc Faugeron:
Towards CQRS, Command Bus
May 12, 2016 @ 12:07:21

Loïc Faugeron has made a new post to his site talking about moving towards CQRS and Command Bus architecture in PHP applications.

By following the Command / Query Responsibility Segregation (CQRS) principle, we separate "write" logic from "read" logic. This can be applied on many levels, for example on the macro one we can have a single "Publisher" server (write) with many "Subscribers" servers (read), and on a micro level we can use this principle to keep our controllers small.

However, transitioning from a regular mindset to a CQRS one can be difficult. In this article, we'll explore the "Command Bus" pattern, to help us to get the Command (write) part right.

He starts with an example of a "create profile" happens and all logic lives in the controller. He then gets into the basics of the Command Bus handling and how the concept of "middleware" relates. He then shows how to migrate over to the Command Bus handling in his controller example, creating a CreateNewProfile command (with unit tests) and its handler. He then refactors the controller to put it to use. He points out that the initial version is tightly coupled to Doctrine so he refactors it too via some simple interfaces.

tagged: commandbus tutorial cqrs example refactor controller command handler

Link: https://gnugat.github.io/2016/05/11/towards-cqrs-command-bus.html

Matthew Weier O'Phinney:
Serve PSR-7 Middleware Via React
Apr 20, 2016 @ 12:07:56

Matthew Weier O'Phinney has a post to his site showing you how to combine PSR-7 request/response handling (his examples use Zend Expressive) with React and middleawre in your application.

I've been intending to play with React for some time, but, for one reason or another, kept putting it off. This past week, I carved some time finally to experiment with it, and, specifically, to determine if serving PSR-7 middleware was possible.

He starts with a brief introduction to React and what kind of functionality it brings to the table. He includes a bit of sample code showing it in use creating a basic HTTP server responding to any request with a simple "Hello World" message. He then starts on the React+PSR-7 integration, wrapping the request and response handling from one in the other to keep the expected responses the same. He also talks about serving up static files using the React+PSR-7 handling via a middleware on the Expressive side. Finally he shares the work he's done via a library to help make it easier to reuse in other situations. He shows the installation and usage of this library and sample requests you can use to test it out.

tagged: react psr7 request response example library handler static file tutorial

Link: https://mwop.net/blog/2016-04-17-react2psr7.html

Davey Shafik:
Aug 24, 2015 @ 10:54:54

Davey Shafik has published a post about library he's created that's a sort of "recorder" for connections made with the Guzzle HTTP client - the Guzzle VCR.

A few days ago I pushed out a very small library to help with testing APIs using Guzzle: dshafik/guzzlehttp-vcr. [...] This is a simple middleware that records a request’s response the first time it’s made in a test, and then replays it in response to requests in subsequent runs.

The handler works by recording the responses from the API (ex: the JSON response data) and records them to files (again, JSON). A one-line call turns the "recording" on and points to a directory where the cached files should be stored. He shows how to use it in the constructor of your Guzzle client, setting it up as the "handler" for the requests. He also includes an example of a few unit tests that make use of the recording feature to check the response of a /test endpoint.

tagged: guzzle http client vcr recording response json cache handler

Link: http://daveyshafik.com/archives/69384-guzzlehttp-vcr.html

Philip Brown:
Dealing with Exceptions in a Laravel API application
Aug 10, 2015 @ 11:57:43

In a post to his site Philip Brown shows a helpful way to manage API exceptions in a Laravel-based API application. In an API, exceptions are particularly important as they can be a hint to what the problem is and make it easier to return the correct error code to the client.

Exceptions are a very important method for controlling the execution flow of an application. When an application request diverges from the happy path, it’s often important that you halt execution immediately and take another course of action.

In today’s tutorial I’m going to show you how I structure my Laravel API applications to use Exceptions. This structure will make it very easy to return detailed and descriptive error responses from your API, as well as make testing your code a lot easier.

He starts with a brief introduction to HTTP status codes and their role in the interaction between client and server. He then gets into the "exception foundation" and how it will work, providing some basic common functionality (like throwing a 404 when a record isn't found, regardless of the type). He creates a configuration file to define the default error messages, an abstract Exception the custom instances can extend. He creates several of these as an example, such as a "UserNotFound" exception that extends the base "NotFound" exception class. He works with Laravel's own exception handlers and includes the code to catch a few different types inside.

tagged: exception laravel api application custom base handler tutorial

Link: http://culttt.com/2015/08/10/dealing-with-exceptions-in-a-laravel-api-application/

Sameer Borate:
Debugging Laravel with MonoLog and FirePHP
Jun 07, 2013 @ 09:08:37

Sameer Borate has a new post to his site showing you how to debug a Laravel application with Monolog and FirePHP.

By default, Laravel is configured to create daily log files for your application, and are stored in app/storage/logs. All Laravel logging features are handled by the wonderful MonoLog library. Monolog includes various log handlers you can use – FirePHP, ChromePHP, CouchDB, Stream and many more. One of my favorites is FirePHP while debugging PHP apps.

Getting Monolog to write out to FirePHP is pretty easy and he includes the sample code to make it happen - basically pushing a "FirePHPHandler" into the Monolog instance and using it from there.

tagged: debug laravel monolog firephp handler tutorial

Link: http://www.codediesel.com/laravel/debuggin-laravel-with-monolog-and-firephp