App Folders In a Nutshell

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.

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

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

#3Queue ScopeEvents: 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.

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.

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:

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.

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.

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/