The Pineco.de blog has a tutorial posted showing Laravel users how to append API and web routes to Eloquent models directly without the need for setting up additional route handling.

As a level zero, we can agree on using the RESTful URI scheme. That means every model has an associated route. We can perform different actions on the model, depending on the request type.

It can be a bit painful to concatenate the strings and IDs all the time, so we could append this URL as an attribute of the model. That means we could calculate the URL behind the scenes, and use it on the PHP or the JS side as well. [...] Then only difference (in this simple example) between the API and the web routes is that the API routes have a /api prefix in the URL.

The tutorial then introduces their custom Routable trait that can be included in any model to handle requests on both the API and web side (differentiated by the "api" prefix). The last step is to append the routes to the model itself using the appends Eloquent property.

Sergey Zhuk has posted the third part of his series covering the use of ReactPHP to scrape content from another source on the web. In this third part of the series he improves on his scripts from before (scraping from the IMDB site) to add in a proxy server.

n the previous article, we have created a scraper to parse movies data from used a simple in-memory queue to avoid sending hundreds or thousands of concurrent requests and thus to avoid being blocked. But what if you are already blocked? The site that you are scraping has already added your IP to its blacklist and you don’t know whether it is a temporal block or a permanent one.

Such issued can be resolved with a proxy server. Using proxies and rotating IP addresses can prevent you from being detected as a scraper.

He then shows how to use the clue/reactphp-buzz package to write an asynchronous HTTP request to google.com making use of promises rather than normal synchronous request handling. He then installs the clue/reactphp-socks package to make the connection to the proxy server(s) and modifies the Buzz client to use that as a connection. After finding a proxy server to use, he updates the scraper code created previously with the new Buzz+Socks combination and shows it in action scraping data. The post finishes with a look at adding some error handling and how to handle when the proxy requests authentication before use.

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 Rob Allen talks about getting up and running with "serverless PHP" using the Apache OpenWhisk cloud platform that executes as events are fired rather than sitting as an entire application.

I've been interested in Apache OpenWhisk for a little while now and recently submitted a new feature to add PHP support to the project. As OpenWhisk is a serverless environment, most users do not run their own copy and instead use a commercial provider with IBMs Bluemix available now along with Adobes I/O Runtime and RedHat coming soon. As a result, my contribution, isn't practically useful until it's in production with a provider.

Fortunately, and remarkably quickly, IBM have added support for PHP to the Bluemix "IBM Cloud Functions" platform, so now we can use PHP to develop serverless applications and deploy them into the wild! This is a rebranding, so you'll see this referred to as "Bluemix OpenWhisk" around the web too.

He walks you through the setup of an account on the bluemix.net service and how to install OpenWhisk locally rather than the IBM "Bluemix CLI" tool. He then shares the code to create a simple "Hello World" function in PHP (7.1) and push it up to your account. He then executes the action from the command line, returning his JSON formatted greeting. Next he shows how to set this function up as a web action and give it a URL for the outside world to access. He finishes the post with some examples of calling the URL and how it would receive parameters via a POST or a GET.

Fabien Potencier continues his look at what's coming in the next major release of the Symfony framework (v4) in this new post to his site. In it he talks about changes to the default directory structure that Symfony 4-based applications will use.

Symfony 3 came with a slightly different directory structure than Symfony 2. Symfony 4 will also come with a reworked directory structure. Mostly incremental adjustments to support new features and best practices.

The Symfony 3 directory structure introduced a more standard Unix-like directory structure, with less sub-directories. Symfony 4 keeps going in that direction.

There's six changes he mentions specifically, each with a brief summary of what they'll contain:

• Tests under tests/
• Templates under templates/
• Configuration under etc/
• Source Code under src/
• Temporary files under var/
• Web files under web/

He ends the post with a quick note that, while these will be defaults, all of it is optional and these directories will be created automatically if they don't exist.

In a previous post Loïc Faugeron showed you how to take all of the components he'd talked about so far and make a simple API endpoint. In this latest post he takes the same functionality and makes a web-facing example instead.

In this guide we've explored the main standalone libraries (also known as "Components") provided by Symfony to help us build applications: HTTP Kernel and HTTP Foundation, Event Dispatcher, Routing and YAML, Dependency Injection and Console. We've also seen how HttpKernel enabled reusable code with Bundles, and the different ways to organize our application tree directory.

Finally we've started to put all this knowledge in practice by creating a "fortune" project with an endpoint that allows us to submit new fortunes.

In this article, we're going to continue the "fortune" project by creating a page that lists all fortunes.

He goes through a similar process as before, but with a few changes to make it output a web page instead of API (JSON) results:

• Create the Controller
• Configure related routing
• Create the logic to list all current fortunes
• Putting the "wiring" in place to connect it to the database
• Creating the view to output a simple page with the fortune list

It's that last step that's different, resulting in a simple (non-templated) page being output with HTML markup. He then refactors this to use Twig as the templating output layer, removing the output generation from the application logic.

Luciano Mammino has posted six tips for blazing fast web applications to his site. These tips aren't as much specific to the code (though they're related) as they are general good practices around architecture, development work and common issues.

In this post I will try to highlight some of the most common principles that you have to take under consideration when you want to achieve a great level of performance while building a web application (specifically on the backend part). I believe the concepts discussed here can be applied to any language and framework even if, due to my specific experience, I will mention some examples, design patterns, conventions and tools that are mostly used in the PHP world.

His post lists out six main rules along with some description and links to other tools for each:

• Avoid premature optimization
• Do the minimum amount of work to solve the problem
• Defer the work you don't need to do immediately
• Use cache when you can
• Understand and avoid the N+1 query problem with relational databases
• Prepare your app for horizontal scalability when possible

There's lots of good tools mentioned here so find one that fits your needs and helps solve the issue. There's also some good articles mentioned, giving more information about a particular topic or other perspectives on how to solve it a different way.

The Acquia blog has posted a few helpful usability tips for developers to help you think about how users will be interacting with the systems they create. This post is the first in a four part series and kicks off the content with four good tips.

Creating the code that makes a website accessible to all visitors doesn’t have to be as time-consuming or resource-intensive as you might think. All you need to do is follow some simple steps that require a little extra time and effort. [...] It’s up to both the developer and the client to achieve site accessibility. Although they usually work together in the planning and later stages of website creation, a developer and client also have separate responsibilities in making a site accessible.

In this post they touch on points around the use of "read more", clear requirements for input and good error messaging practices.

The SitePoint PHP blog has a new tutorial posted by i>Miguel Ibarra Romero showing how to use the PsySH tool to do some interactive debugging of your PHP applications via both the command line and a web frontend.

It’s 1:00 a.m., the deadline for your web application’s delivery is in 8 hours… and it’s not working. As you try to figure out what’s going on, you fill your code with var_dump() and die() everywhere to see where the bug is. [...] Is this situation familiar to you? PsySH to the rescue. PsySH is a Read-Eval-Print Loop (or REPL). You may have used a REPL before via your browser’s javascript console. If you have, you know that it possesses a lot of power and can be useful while debugging your JS code.

He walks you through the install via Composer and some of the basic commands and syntax for executing PHP code inside its shell. Command line testing is good, but debugging full applications is a bit more difficult. He shows how to integrate the tool into a sample application that calls PsySH via a "debug" call and output via a set of "window" objects. He also includes a bit close to the end about debugging with unit tests, executing them from inside the shell as well.

The Three Devs & A Maybe podcast has posted their latest episode (#32) with guest Kris Jeary to discuss "all things design" in web development.

This week we are lucky to have Kris Jeary on the show to discuss all things design. Starting off with how he got introduced to the world of web design, we move on to discuss the process he uses to create websites. We then touch upon where he gets inspiration from, and how the emergence of responsive and SPA ideologies has changed the way we think about the web. Finally, we wrap up the show with some good advice to anyone looking into getting into web design.

The show includes mentions of cron expressions in PHP, Modern.IE and CodeKit. You can listen to this latest episode either by downloading the mp3 directly or using the in-page player. If you like what you hear, consider subscribing to their feed too.