Esben Petersen has kicked off his series on creating a modern REST framework in Laravel 5 with part one in the series. This first tutorial focuses on the setup of the application using a "folders by component" approach.

Over time when your API grows in size it also grows in complexity. Many moving parts work together in order for it to function. If you do not employ a scaleable structure you will have a hard time maintaining your API. New additions will cause side effects and breakage in other places etc.

It is important to realize in software development no singular structure is the mother of all structures. It is important to build a toolbox of patterns which you can employ given different situations. This article will serve as an opinionated piece on how such a structure could look.

The tutorial covers structure on three different levels (patterns): application flow, project folder structure and resource folder structure. For each level they cover some of the basic concepts involved and share code showing how it could be implemented including controllers, repositories, middleware and fitting it all into a a resource folder structure.

Matt Stauffer has continued his series looking at Laravel 5.1 with a new post covering the ACL functionality recently added in 5.1.1. This functionality adds on to the pre-existing authentication handling that has been a part of the framework for a while.

The authentication that Laravel provides out-of-the-box makes it simple to get user signup, login, logout, and password resets up and running quickly and easily.

But if you needed to control access to certain sections of the site, or turn on or off particular pieces of a page for non-admins, or ensure someone can only edit their own contacts, you needed to bring in a tool like BeatSwitch Lock or hand-roll the functionality, which would be something called ACL: Access Control Lists, or basically the ability to define someone's ability to do and see certain things based on attributes of their user record. Thankfully, Taylor and Adam Wathan wrote an ACL layer in Laravel 5.1.11 that provides this functionality without any added work.

He talks about the main interface to the ACL system, the Gate class/facade, and gives a simple example of it in use. He then gets into how it works in defining abilities and checking access levels with both the facade and on the model level. He also shows how to use the checks in Blade templates and how to intercept the evaluations for custom evaluation. He ends the post talking about the concept of policies and controller authorization to allow for additional checking.

On NetTuts.com they've posted a tutorial showing you how to create a real-time chat system using Laravel 5, Modulus and Pusher (with a PostregSQL backend).

In this tutorial, I will show you how to implement a real-time chat application with Laravel 5, PostgreSQL, and Pusher. Then we will deploy this application to Modulus together. We will use Laravel 5 for the back-end service, HTML5 and jQuery for a simple front-end application, PostgreSQL for the database, and Pusher for real-time communication between the server and clients.

They start with the scenario they want to solve and a look at the overall architecture of the solution. Then they start setting up the software and services needed to bring it all together:

• installing a fresh copy of Laravel (as a project)
• setting up a new database using the ElephantSQL service
• creating a Pusher account and the credentials you'll need for the application
• creating an Nginx configuration for the Modulus setup

Next comes the design of the application, creating the models for message data (author, content, etc) and the simple controller to handle the requests. They show how to configure the connection to Pusher and build the routes for getting, listing and saving messages. Finally they create the view complete with Javascript to connect it to Pusher and transfer messages back and forth. All that's left then is the deployment using the modulus command line tool (installed via npm).

Jason Gilmore has posted an article to the Easy Laravel Book site with a bit more detail about how the framework prevents some common security issues including SQL injection and cross-site request forgery.

A reader recently e-mailed me and asked about Laravel 5’s native security features. While I talk about various security-related matters throughout the book, this information isn’t consolidated into any particular chapter and so I thought it would be useful to do so in a single blog post. Laravel helps to secure your web application by protecting against three serious security risks: SQL injection, cross-site request forgery, and cross-site scripting.

He goes through each of the types and talks about the built-in functionality Laravel includes to protect against each one. A bit of code is tossed in when needed to help clarify the point too. Fortunately for the user, a good bit of the technical pieces of these protections are behind the scenes and don't need much effort to use.

The "Easy Laravel Book" website has posted a new tutorial today looking at the use of scopes in Laravel, a packaging method for creating reusable chunks of code for use across the application.

Applying conditions to queries gives you to power to retrieve and present filtered data in every imaginable manner. Some of these conditions will be used more than others, and Laravel provides a solution for cleanly packaging these conditions into easily readable and reusable statements, known as a scope. In this tutorial I’ll show you how to easily integrate scopes into your Laravel models.

He starts with a simple example of a "where" clause made into a method having a name starting with "scope". This is a hard-coded scope but he also shows an example of the other option, dynamic scopes, allowing for input from the user as a part of the execution. He also shows a quick example of using these same scopes with relations, making them a part of the "find" result chain.

Matt Stauffer has posted the latest in his "What's New in Laravel 5" series today with a look at the changes in creating Artisan commands with a newer, simpler syntax.

If you're not familiar with Artisan commands, they're command-line functions that you can run to interact with your Laravel application. If you run php artisan from the command line in any Laravel application directory, you'll see a list of all of the Artisan commands available for each app. As you can see, Laravel comes with quite a few enabled out of the box.

He starts with a look at the old way of creating the commands using the "artisan make:console" command to build the class and an example of its contents. This version requires a good bit of extra code to reference things like arguments and define required parameters. He then compares this with the new way with a much simpler syntax and reduced about of code overall. One of the main differences he mentions is the concept of a "signature" for the command - a specially formatted string that defines configuration such as required and optional parameters. He finishes the post with a few examples of these signatures.

SitePoint's PHP Blog has a new tutorial posted showing you how to use event broadcasting in Laravel 5 to perform actions based on events the application issues.

In Laravel 5.1, the framework includes functionality called broadcasting events that makes it easy to create real-time apps in PHP. With this new functionality, an app can publish events to various cloud-based real-time PubSub solutions, like Pusher, or to Redis.

They start you off installing their sample application inside of a Homestead Improved virtual machine. They show you how to use the non-realtime version of the application and how the other parts of the application do not update when changes are made. They then create the ItemCreated, ItemUpdated and ItemDeleted events and the related data provider needed to "boot" the events. From there they walk you through installing the Pusher PHP library, including the matching Javascript file and a bit of code to push events and receive them in other parts of your application.

With the next Laravel release (5.1) coming soon, the Laravel News site has gathered together all of the information that's been shared about what's to come. In this new post they list some of the updates and code where needed to illustrate.

Laravel 5.1 is scheduled for release in May and lots of new features will be included in this release. Here is a list of eight of the big changes and new features.

Their list of eight includes things like:

• LTS, Long Time Support
• Resolve a service from blade
• Middleware Parameters
• Broadcasting Events

You can find out more about these and others on the list in the full post.

Fred Muya has posted a guide to his site today showing you how to configure custom logging in your Laravel 5 application. He replaces the default logging methods with an injected Monolog instance.

I recently started working on a Laravel 5 project, and I’d like to share how I set up my custom file logging. I pooled the information below from several sources (acknowledged at the bottom of the article).

He walks through each step you'll need to configure the logging:

• Overriding the bootstrap ConfigureLogging class (including the code needed)
• Updating your composer.json to change up the PSR-4 autoloading
• Modifying the Kernel.php file to update the constructor for the bootstrap (both HTTP and Console)

With these changes in place you can then use the normal "Log" handling Laravel provides and the magic will all happen behind the scenes. He includes two examples of this, one with a simple log string and another with something a bit more complex (and the resulting log output).

The NetTuts.com site has a new tutorial posted today sharing more information about the authentication facade in Laravel 5 and how to use it to implement simple, custom authentication handling.

Authentication is a part of almost all the web applications you work with. It's really boring to keep repeating all the boilerplate code in every project. Well, the good news is Laravel 5 rids you of this boredom by providing a ready-to-use authentication facade. All you need to do is configure and customize the authentication service provider to your project's needs. In this quick tip, I am going to show you exactly how to do that.

It's a seven step process to get things up and running (it sounds like a lot but all the code is provided):

• Setting Up the Environment
• Setting Up the Migrations
• Configuring the Registrar Service
• Updating the User Model
• Updating the View
• Securing Your Routes
• Modifying the Default Authentication Routes

Each step includes the code needed and a brief summary of what's happening and how it effects the overall authentication setup. He also ends the post with a brief mention of the "password reset" email functionality and where the content for that email is located.