Whoa, it's been. A couple of weeks since I posted, it's almost like I bagged myself a gold badge for my consistency and lost motivation or something. 🥇
3 Cheers for Gamification.
Truth be told life got in the way. I'd been putting my learning time into a work project with a tight deadline.
My current day job has me diving headfirst into the no-code Webflow platform to build a mega menu among many things, which has been driving me insane. These no-code tools have me jumping through too many hoops to make changes that would otherwise be a breeze if I had I just had access to the code directly.
I'm not trying to be negative about Webflow or no-code tools, I can see the appeal, it's just I feel you see things a little differently sometimes when you have a little bit of knowledge of what's going on behind the scenes.
Anyway speaking of breezes, I have been spending a bit of time learning Laravel Breeze which is Laravel's basic authentication scaffolding add-on.
So, in the interest of learning by explaining, here are a few things I've taken from my experiences of tinkering with Breeze.
1). It's a scaffolding for Laravel authentication systems; it contains what I need for a login system. A battle-tested tool developers can rely on when starting a project where they will need authentication without having to build it themselves.
2). When installing Laravel Breeze, I can install it automatically when starting a new project.
larvel new ProjectName --breeze --pest
Laravel new ProjectName is standard for creating a new Laravel Installation
--breeze also install Breeze at the same time
--pest sets the project up for Pest testing rather than Unit testing
3). Breeze gives me the middleware functionality for:
A login page
Email a Forgotten Password (this is a whole other upcoming post)
4). Breeze incorporates Tailwind a CSS framework I've been taking a closer look at recently
5). Breeze doesn't initially separate the front-end and back-end views or controllers.
And this is where this intro to Breeze starts to get opinionated. I wanted to clearly define what was the front end and the back end and this immediately meant I needed to customize Breeze and refactor its initial structure so that I had sections I could at a glance see we're going to contain my front end content as opposed to mixing it all together.
I understand why Breeze does things this way; it's a developer's toolkit and was never designed as a fully featured framework. Who's to say the user even intends to have a front end?
But my personal preference was to start by having a clear separation between the two since my project would have a front end.
6). Breeze uses Vite for its development server. I love the hot reload overall, it's a great experience.
Overall, I would recommend Breeze as an excellent starting point for small projects without customization or external dependencies. It's simple and easy to get started.