On the Pineco.de blog they've posted a tutorial for those out there using Laravel's request and response handling to add in macros to modify the information in the request/response based on custom logic.

We’ve already talked about the power of the collection macros. Now let’s take a look at the request and response macros as well to explore the possibilities that extending their functionality offers.

The tutorial starts by showing the creation of a filter request macro. This macro pulls the information out of the response and removes data that contains null values. Similarly, they show how to create a toSpecialFormat macro on the response, formatting the response as a JSON message rather than normal output.

In a post to his site Matthew Weier O'Phinney shares some notes about GraphQL usage that he's gathered over the last week or so of working with it.

The last week has been my first foray into GraphQL, using the GitHub GraphQL API endpoints. I now have OpinionsTM.

The promise is fantastic: query for everything you need, but nothing more. Get it all in one go. But the reality is somewhat... different.

He talks about his experience working with the results and the amount of data manipulation that was required to actually get at what he wanted. He shares the query he used, the result the API provided and what he ultimately wanted. He also mentions the less than useful documentation, issues with pagination and an update based on comments of pulling data from the GraphSQL API versus the REST API.

In a new post to his site Matthias Noback shares some of his recent experience working with a multi-tenant application and the current "contexts" that exist during the user's session. In the most he makes some suggestions about how to generate this context on each request without having to resort to a "data clumping" approach.

In the beginning we start out with a framework that has some authentication functionality built-in. We can get the "current user" from the session, or from some other session-based object. We'll also need the "current company" (or the "current organization") of which the current user is a member.

In the web controller, we take this information out of the session (which we can possibly reach through the "request" object passed to the controller action as an argument). Then we start doing the work; making queries, making changes, sending mails, etc. All on behalf of the current user and the current organization. [...] Soon this starts to feel like a code smell known as a Data Clump: the same data hanging around together.

He offers a few different steps to follow to make sure you're correctly implementing this functionality and not violating the SRP (Single Responsibility Principle):

• Injecting the session
• The Context class
• Passing contextual values on a need-to-know basis
• Fetching more data when needed

For each item on the list there's a paragraph or two explaining the changes and functionality with code examples included where necessary for illustration.

Sergey Zhuk has posted the second part of his "fast web scraping" series that makes use of the ReactPHP package to perform the requests. In part one he laid some of the groundwork for the scraper and made a few requests. In this second part he improves on this basic script and how to throttle the requests so as to not overload the end server.

t is very convenient to have a single HTTP client which can be used to send as many HTTP requests as you want concurrently. But at the same time, a bad scraper which performs hundreds of concurrent requests per second can impact the performance of the site being scraped. Since the scrapers don’t drive any human traffic on the site and just affect the performance, some sites don’t like them and try to block their access. The easiest way to prevent being blocked is to crawl nicely with auto throttling the scraping speed (limiting the number of concurrent requests). The faster you scrap, the worse it is for everybody. The scraper should look like a human and perform requests accordingly. A good solution for throttling requests is a simple queue.

He shows how to integrate the clue/mq-react package into the current scraper to interface with a RabbitMQ instance and handle the reading of and writing to the queue. He includes the code needed to update the ReactPHP client. The mq-react package makes the update simple with the HTTP client reading from the queue instance rather than the array of URLs. One the queue is integrated, he then shows how to create a "parser" that can read in the HTML and extract only the wanted data using the DomCrawler component.

In a new post to his site Matthew Weier O'Phinney, lead developer on Zend Framework and representative in the PHP-FIG, covers the acceptance of PSR-15 by the group. PSR-15 relates to the creation of server request handlers and middleware that can use PSR-7 formatted messages.

Yesterday, following a unanimous vote from its Core Committee, PHP-FIG formally accepted the proposed PSR-15, HTTP Server Handlers standard.

This new standard defines interfaces for request handlers and middleware. These have enormous potential impact on the PHP ecosystem, as they provide standard mechanisms for writing HTTP-facing, server-side applications. Essentially, they pave the way for developers to create re-usable web components that will work in any application that works with PSR-15 middleware or request handlers!

He starts with a bit of background around the initial idea of the standard and some of the discussions that came up around it. The initial draft of the standard was modified to more correctly handle issues around response modification and the use of "handlers" for request/response manipulation. He then covers the final version of the standard, defined in the standard's documentation and enforceable via the psr/server-handler interface. Finally he covers how to use this to create re-usable middleware and an example using Expressive.

Sergey Zhuk has a new post to his site showing how to define and use middleware in your ReactPHP application.

What exactly is middleware? In real application when the request comes to the server it has to go through the different request handlers. For example, it could be authentication, validation, ACL, logger, caching and so on. Consider the request-response circle as an onion and when a request comes in, it has to go through the different layers of this onion, to get to the core. And every middleware is a layer of the onion.

He starts off with a simple example of a ReactPHP-based server that just responds to all requests with a "Hello world" message. I includes some logging functionality that he then refactors out into middleware. This logging records the HTTP method used, time of the request and the URL requested - all things the code can get from the request object. Code is included showing the refactoring out to the middleware and injecting it into the ReactPHP application. He then updates it to check for the existence of a file and, if so, returns the results as a stream. Finally he covers updates to the response inside the middleware, changing the HTTP status code and content returned based on the results of various checks.

The Cloudways blog has posted a new tutorial for the Laravel users out there showing you how to create a "live search" box for the contents of your site. They use an e-commerce example and make use of some simple Javascript to return results from a backend script.

Whether you have a blog or an ecommerce store, a search bar is always an essential component of the UI. However, the days of simple search bar is over. These days, a live search bar is much more efficient than a simple search bar because it displays similar content in real time. This increases the chance of landing a sale because the customer could see the largest selection of related products.

The article starts off with the prerequisites for following along including an installation of PHP, MySQL, Apache and Laravel. They include an optional step of setting it all up on a Cloudways server but this isn't required if you want to do it locally. The tutorial then walks through the setup steps and creating the migration for the "products" table it will search. It also shows the creation of the controller and routes for the search endpoints and the view with the Javascript to make the Ajax request. It finishes with a way to test the result and a screenshot of what should be returned.

On the Laravel News site there's a quick tutorial posted showing you how to use named routes in Lumen in writing tests for your application.

When writing tests in Lumen, I recently discovered that the route() helper doesn’t work with tests out-of-the-box.

I prefer to define named routes and make requests against them in my tests. If you follow the Lumen documentation, the typical way that you make a request for a test [of the return of a JSON endpoint results in an error message]. [...] If you inspect things a little closer, you can see the issue: [...] Interestingly, the route doesn’t look quite right, and the router is returning the / route. It looks like the localhost part of the request isn’t being set, and the route isn’t matching. We can fix that by bootstrapping the request as Laravel does.

The post then walks you through the manual process of bootstrapping things so that routes are correctly resolved. This includes changes to the code for the base test case to handle the "boot" and set the path value for the request correctly.

Sergey Zhuk has kicked off a series of posts to his site showing how to create a ReactPHP memcache client that can work as a streaming client for your PHP application rather than single get/set requests.

Before writing any code we should think about our future client’s API: how we are going to use it [and] what methods it is going to have.

The client is going to be used in ReactPHP asynchronous ecosystem, so I’m going to provide a promise-based interface for it (when methods return promises). Also, we are building a streaming client. Under the hood, we will open a socket connection and use it as a stream. The client itself will be a wrapper on this binary stream communication. That means that it is our job to manually parse Memcached protocol to write and read data with sockets. So, having all of this in mind, let’s start.

He then starts in on the development of the base for the client including the factor class that will create the client (connector) with the provided Loop instance. He includes an example of this in use to create the client and point it to a local memcache server. Next he creates the client class that will use the stream to send requests and a parser to work with the responses and resolve actions that need to be taken based on their contents.

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.