Laravel 5: App Folders In a Nutshell

App Folders In a Nutshell

Here, you will find some basic explanation as to what are all these folders in directory \app are for.

Console Commands allow to define custom command to be used in Laravel console called Artisan.
This command can do designed by you task.
It is great for defining commands you can then use in scheduling etc.

Event is a predefined activity
Event described here is powered by Event object.
There are other event-like constructs in Laravel, like:

  • Eloquent events
  • Queue jobs – see them as listeners combined with events
  • Schedules – these are events powered by cyclical, Chron-based repetitive pattern

Event is a trigger call, that results in some response action.

sample:
event: order is completed
response (by listener): email notification


Listeners are responding scripts to event.

If you fire and event, as described just above, there are some scripts designed to respond.

example (in addition to one above):
event: user logs in
listener: log user login time and IP etc. to some log or database table


Subscribers is a construct, that allows you to create more than one Listener in single class file.

For me it seems like overkill.

I’d rather place my Listeners inside of sub-directories, as many levels down as needed and follow single responsibility coding rule, than try to clunk Listeners together inside of some surreal ‘animal farm’.

But sometimes, it makes sense to group a few Listeners thematically linked into a single file.
e.g.: login eventing: onUserLogin, onUserLogout …etc.
But then, you start having code doing same stuff in different places (different \app folders) – can get confusing.


This is a totally different kind of events.
They are fired by Eloquent itself.
Of course, you could fire your own events, but you’d have to check e.g. results of query etc.
With Eloquent, you do not have to bother. It is handed to you on a golden platter.


Observers are in a way similar to Subscribers, but ‘only in a way’.
I strongly recommend using Observers.

Reason:
All that Eloquent eventing code goes inside of Service Provider boot() method.
So, some Providers can get awfully crowded.
Observer allows to move all that code elsewhere and replace it with just one line of descriptive code.
This makes code a lot more readable.

Jobs have a lot in common with events/listeners.
They are designed to perform same, or at least similar task.
They even work in a very similar way and both can utilize Queues.

There are some differences thou.

#1.
Job
: helper function dispatch() (job trigger), can call only one job.
Event: helper function event() (event trigger) calls event class, which can call into action more than one listener

job-event
#2
Job Scope

Jobs seem to be created to unload code from Controllers and make them lighter, and seem to be meant for bigger tasks, than Events.

#3
Queue Scope
Events: all you can really do, is that you can enable queuing and that is pretty much it.
Jobs: It is easier to use different connections, like: database, beanstalkd, sqs etc. plus you have bunch of other functionality to mold queue to fit your needs.

So, if you have more than one task to accomplish, use Events, otherwise use Jobs, especially, if you want to unload Controller and push some code into external files – for better readability.

Eloquent scopes are nothing more than a method to append some code to SQL query.

Example:
Lets say, that you want to make sure, that draft posts and disabled posts are never going to be shown up front.
You can use Scope to add by default constrain preventing selection of these posts.

In other words.
You do not have to opt-out to get collection without drafted and banned posts.
You get that by default.
You have to opt-in to get these banned and drafted posts, e.g. for display in the backend.

Library

This is not Laravel standard issue part.

Remember good ole’ global functions from early days?

Functions tucked into some file, required in some application_top.php and available everywhere you needed them.
That is how you can use Library.

So, how to set it up.

Create folder Library inside of folder app/.
Create any number of helper classes you need

e.g. Sorting class, for generalised sorting tools for table listed columns.

How to use it

a. ‘new up’ as you would always do:

b.  automatic resolution (injection) using IoC container:

See this link for more.

This can be very useful, especially in highly compartmentalised project, where all sections may need repetitive functionality – like list sorting by column.

 

Services

This is not Laravel standard issue part.

Also, you may put some task specific code.

This code can do some job for you, so you pull easily result of that job into blade directly, or inject it to Controller via method injection.
This is how you do it in blade directly:

Sometimes, when you have to test your app.
For that you need some data in your database.
Problem is, that when you start developing, usually your database is quite empty.

Seeder is a way to help you.
Especially when used together with standard issued by Laravel library Faker, which can help you to generate thousands of realistic records for testing.

Testing
Seeders are great during unit testing.
You can add DB seeding code to your testing code, add some roll-back utility (or use built-in) and have your database turned back to state before testing for any future testing.
Above is great to avoid skewing testing results due to data difference.

Providers

This folder has to do with:

In general, Service Container is like a factory, which builds for us objects with all dependencies injected into object.
Actually, there is a code design pattern, which is being used just for that – building objects with dependencies.
And this is pretty much, what it is.

Service Provider, to some extent, reminds me of Windows registry.
It is a place to register all important services, like for instance:

  • service container bindings,
  • event listeners,
  • middleware,
  • even routes etc.

See links above in this section.

This is Laravel native way to do Cron tasking.
And much better I must say.
Click ‘Schedules’ link above for more details.
There is an added bonus there for all those, who code on Windows and use some form of LAMP emulator, like XAMPP.
That bonus, I mentioned, is a very detailed way (with images), how to setup Cron-like behavior on Windows, using Windows ‘Task Scheduler’.

Migrations

Migrations allow automation in creating tables.

It is also table version control, that allows to see, to what is being done to table/database over the time.

More here and here.

Mail
config and .env

All configuration values are in config\mail.php file.
It can be overridden in .env file.

Guzzle HTTP Library

You need this library.
Run this code – if you have it already, it’ll just get updated.

generate mail class

There is Artisan command doing it for us:


Detailed example on how to put email code together can be found on this page.

Routes, in general, are like a switchboard.
Request comes in and routing system directs it into a proper resource, that is equipped to handle it.

Middleware provide a convenient mechanism for dealing with HTTP requests entering your application (before middleware), or responses leaving it (after middleware).

Best example of middleware is authorization.

More here and here.

Controllers can group related request handling logic into a single class.
This is a place, where all functionality residing elsewhere is pulled into to serve incoming request.

HTTP request, is exactly what the name suggest.
It is a request sent by client to server for some resource.
It could be anything: text, image, data processing, data stored in database etc.
Of course there is more to it, but in general, above covers it.

Models

These are classes which allow data data flow to and from database tables.

Important:
Read a bit below abut Repositories.
Not all code interacting with Database goes into Model – especially if you are using Eloquent ORM.
And definitely, you do not want to interact with Database (even via Model) from within Controller.
Why?
Well, there is that thing called ‘loose coupling’.
Read about Repos below.

Even best coded app will get in trouble and generate errors.
Your app will have to be able to recover from errors and be able to tell you about them, so you can (possibly) fix them.

Policies are classes that organize authorization logic around a particular model or resource.
For instance, Post model may have PostPolicy class with all you need to authorize post updates, posting, deletion. Naming is arbitrary. It is up to you.
Policies are stored in catalog:  app/Policies/

Repositories help to make your app future-proof, by loosely coupling your controllers to database logic, e.g. Eloquent, so you can switch your data storage anytime without affecting rest of your app.

See here how it is done.

Read and watch more here – especially first one: