Rob Allen has posted a new tutorial to his site sharing how you can set up route specific configurations in Slim by setting it as a part of the route definition.

A friend emailed me recently asking about route specific configuration in Slim. He wants to be able to set properties when creating the route that he can pick up when the route is matched. The way to do this is using route arguments. I’ve written about route arguments before in the context of setting default values for a route parameter, but you can also use them to set new data for use later.

In this post, I’m going to look at how to use them for configuration data, such as setting required ACL permissions for routes.

He includes code snippets showing how to set the per-route data and how to access it from inside of the request handling via the Request instance. He shows an example of this both in the basic route definition and in middleware.

On the Pineco.de blog there's a tutorial for the Laravel users out there showing how to set up subdomains in your application using the built-in framework functionality (and their setup with Valet/Forge).

Often we need to handle subdomains with our Laravel application. Let’s take a look, how can we treat the routes dynamically and set up the subdomain with Valet and Forge.

The tutorial then walks you through the steps to get subdomains working:

• Defining Subdomains in Our Routes
• Dynamically Generate Subdomains
• Faking Subdomains in Valet
• Setting Up Subdomains in Forge

Each section comes with a brief explanation and any code or configuration changes that would need to be made to make it all work.

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.

In a post to his site Ben Sampson shows how to mask IDs in URLs using hashids in a Laravel-based application. Hashids converts values into strings that can then be decoded back to their original values.

By default a URL generated by a Laravel app will contain the ID of a model like this https://app.name/users/1 where 1 is the ID of the item. Often this is absolutely fine, but sometimes you might want to hide it (or obfuscate it). The two main use cases for this I've come across so far are: Security [and it looks] More professional.

He shows how to use this package to encode and decode ID values in your URLs. He also includes updates to the models, controllers and routing to use route model binding to handle the encode/decode process. He shows how to set up different salts for different data types, setting it on each model and how to correctly bind the functionality in the main route service provider.

On the Laravel News site there's a tutorial showing you how to use a feature that's been added in the latest release of the Laravel framework: signed routes. These signed routes allow you to create routes that work with signatures and help with their validation.

In the latest Laravel 5.6.12 Release a new signed URLs feature was introduced. In this article, we’ll work on enabling signed URLs in an application and look at a few options of how to use them.

The tutorial starts by helping you update your installation to the latest version and change the configuration to add the new ValidateSignature middleware to the route middleware list. They also provide an example of a route definition that contains several "id" type of values that could potentially be modified by an attacker. It then shows how to use the Url helper to generate a new signed route that includes a signature based on the URL contents. The tutorial also provides an example of temporary URL signatures that will include a timeout value as a part of the hash so it will expire after a certain amount of time.

For those out there that are new to using the Laravel framework and are a bit lost in trying to figure out its structure, Laravel News has just the article for you. In this new tutorial they give you an overview of the Laravel codebase and how you should structure your applications to keep everything organized.

Getting started in a new codebase can be very overwhelming, even more so if you are new to programming. So where do you start? Where are the places to look to learn the most about a codebase? Let’s take a look at few common areas for Laravel.

They start by talking about project documentation and how it can play a vital role in the on-boarding of developers new to the application. From there the post goes on to talk about the composer.json configuration, route configurations, service providers, tests and some additional tooling. For each item there's a paragraph or two explaining its place in a Laravel application and, in some cases, links to other resources for more information.

Nwanze Franklin has posted a tutorial to the Dev.to site sharing a deep dive into middlewares in Laravel. Middleware is a powerful tool that can allow you to work with the request and response objects in your application in a more reproducible and contained manner.

What is a Laravel middleware? It is a feature in Laravel which provides a mechanism for filtering HTTP requests entering your application. This allows you to hook into Laravel request processing work flow to perform some kind of logic that decides how your application works.

What would you use middleware for? Protecting your routes, setting headers on HTTP responses, logging requests to your application, sanitizing incoming parameters, enable site-wide maintenance mode [and] manipulating responses generated by your application.

The tutorial then starts in on the code, showing how to create a custom middleware and the code that's generated by the artisan command. It covers the differences between global and route middleware, how to register a middleware and assigning it to a route. It ends with a look at using parameters in middleware and how to access them from the controller.

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.

Rob Allen has posted a quick tip for the Slim framework users out there showing how to use default route arguments in your application.

A friend of mine recently asked how to do default route arguments and route specific configuration in Slim, so I thought I'd write up how to do it.

He illustrates with a simple "Hello world" route that responds using the "name" value from the URL path. He then shows how to modify this example and define a default using the "setArgument" method on the route itself (for both single and multiple values). He ends with an example of how it can be applied for other values needed in the route as well, like a "role" for access control handling.

In a new post to his site Rob Allen talks about how you can speed up the routing in your Slim framework based application using the route cache file.

When you have a lot of routes, that have parameters, consider using the router's cache file to speed up performance.

To do this, you set the routerCacheFile setting to a valid file name. The next time the app is run, then the file is created which contains an associative array with data that means that the router doesn't need to recompile the regular expressions that it uses.

He gives an example of how to enable the setting and makes the recommendation that it's only used in production. He includes a simple example that defines "25 groups, each with 4000 routes, each of which has a placeholder parameter with a constraint." The first run on a route responds in 2.7 seconds but, once the cache file is created, it drops down to just 263 milliseconds - a major improvement.