We've all been there. You have that Idea that's been bouncing around inside of your head for so long, you just don't know how to put it onto the screen. You don't know how to take that code and actually break it down piece by piece to a working product. Because the toughest part is actually just starting and figuring out, okay, how am I actually going to make this happen? And we're going to be taking that journey together. We're going to be starting piece by piece together, and there are going to be some ebbs and flows along the way. We can iterate, and we can adjust, and we can move forward together. So we're going to be building a Livewire application from start to finish with this Idea that's been bouncing around inside of my head. So why don't we start with something that all of us should start with, Laravel GNU. So in your terminal, wherever you store your

been bouncing around inside of my head. So why don't we start with something that all of us should start with, Laravel GNU. So in your terminal, wherever you store your projects, I store mine in the code folder. Go ahead and let's start with the Laravel GNU command. We're going to call this project Listening Party. Now we're going to start with Laravel Breeze, and we're going to use Livewire Volt. We're going to use the class API. If you're not familiar with Volt, Volt is a single file component structure for Livewire. So instead of having your logic in one file and your view, your blade template in another, Volt just squishes them together. The class API is going to feel very familiar if you have worked in Livewire. If you have not, well, hopefully we can walk through that together. So Livewire Volt API, and we're not going to use any dark mode. We're probably not going

have worked in Livewire. If you have not, well, hopefully we can walk through that together. So Livewire Volt API, and we're not going to use any dark mode. We're probably not going to do any testing, but we will initialize a new Git repository. So we'll go ahead and let this install. We're going to get started with a SQLite database, and we'll run the database migrations. We can create it. We're going to start with npm run dev. I always like to do this. That way we have it just up and running. When we do make changes, we can see them live on the screen. Now I can open my code editor. I'm using VS Code, but if you're using PhpStorm, that's perfectly fine. When I'm taking an Idea that I have in my head and I want to put it into code on the screen, the first thing I like to do is just get something on the screen in general. In this case, because we have our web routes,

in my head and I want to put it into code on the screen, the first thing I like to do is just get something on the screen in general. In this case, because we have our web routes, I'm going to go ahead and remove most of this because I want to see something on the screen. I want to start with a Livewire component because most of what we're going to have is that functionality. We need to create a room for people to be able to listen to podcasts together, so we can start with the actual functionality of that Livewire component. Instead of this welcome.blade.php view that we have here, resources/views/welcome, I'm going to actually rename this to, why don't we call this home. Why don't we go ahead and gut this home.blade.php. I'm just going to remove pretty much everything here. Then I'm going to create a new Livewire volt component that we can then start building our application.

and gut this home.blade.php. I'm just going to remove pretty much everything here. Then I'm going to create a new Livewire volt component that we can then start building our application in this home.blade.php view. We can do that by running php artisan make volt. Again, Livewire volt is that single file component structure for Livewire. Because we ran the breeze implementation for class components, we don't have to actually append the --class option. It will just automatically create and scaffold out the class stub for us. We're going to call this, why don't we call this the Dashboard? Because I believe what we'll start with is perhaps a screen, even if you're not logged in, you'll see the ability to add and create a new podcast listening party, but you might see either other ones that are in progress or maybe about to start. In this case, we need a dashboard to see that view. We'll go ahead and create the Dashboard.

listening party, but you might see either other ones that are in progress or maybe about to start. In this case, we need a dashboard to see that view. We'll go ahead and create the dashboard. Just because we have additional views here, the only reason we started with Breeze is so that way we can use authentication if it comes up in our project. Maybe we want to authenticate users so that you can have your listening stats maybe tracked with that user. Again, this is future proofing this. I just like to have the ability to have users and all those pages scaffolded out for me already. But since we have this Livewire dashboard component here, we also have this dashboard Blade view. I don't know if I like the clashing of names. I'm just going to go ahead and delete that for now. We don't necessarily need that route. We have the dashboard Livewire component. Why don't we go ahead and say hello world here. And in our home Blade view, why don't

and delete that for now. We don't necessarily need that route. We have the dashboard Livewire component. Why don't we go ahead and say hello world here. And in our home.blade.php view, why don't we go ahead and put the Livewire dashboard component here. That way we have something on the page, something ready to go. So if we go back into our terminal, I have Laravel Herd installed, which runs the local development server for me. If you're using something like Docker with sail, then you can run the sail up command and have that in your localhost. If you are using valet or using something like php artisan serve, go for that. I'm using Herd, which gives me the ability to use herd open. And I have this right here. Okay, welcome not found. That's good because we don't actually want the welcome. So in our routes, we're going to change this to home. That's looking good. We have our hello world. So now we have something on the page. Now we have

don't actually want the welcome. So in our routes, we're going to change this to home. That's looking good. We have our hello world. So now we have something on the page. Now we have in our dashboard ready to go. We can start building this project because we know that it's going to be a real time application. Why don't we get that piece in place in this case, have a broadcasting server ready to go for us so that when we do need it, when we do start building in it, it's already installed in our application. And in that case, we're going to use Laravel Echo. So if I was to go to reverb.laravel.com, we have the Laravel Echo site for us, which we can then read the docs and install this. So the first step is to run this php artisan broadcast:install command. I'm going to do that in my terminal, we would like to install Laravel Echo. And then we'll install the node dependencies as well. Now I'm using Laravel Herd to run the service of Laravel Echo

I'm going to do that in my terminal, we would like to install Laravel reverb. And then we'll install the node dependencies as well. Now I'm using Laravel herd to run the service of reverb behind the scenes. But if you don't, then you will have to set up your credentials as well as use the reverb start command to start the reverb server in your application. And since I'm using herd, I have these environment variables right to go for me for the service that it has started. So in my environment variable, I can go ahead and replace this reverb app here with my Laravel herd service. Before we move any further, I like to start taking notes for this application because this Idea that's been bouncing around inside of my head, I want to make sure that I start by breaking it down. What pieces do I absolutely need to start working on? And maybe this is where the Idea starts to ebb and flow, maybe it starts to take shape in a different way than I thought it.

by breaking it down. What pieces do I absolutely need to start working on? And maybe this is where the idea starts to ebb and flow, maybe it starts to take shape in a different way than I thought it would, when it was kind of bouncing around inside of my head. So let's create a new notes.txt file where we can start getting this out from our head and onto the page. So in the root directory, I'm going to create a new notes.txt file. And here we can start building the listening party real time podcast app. And it's kind of long, but I do have this domain that I've been sitting on for a while called audio. And I don't know if that's going to fit perfectly, but I might. So what do we need to have up and running and what can we start with? Well, a User needs to be able to create a listening party and that listening party has a podcast. In this case, it's a podcast episode, but maybe we want to create a new podcast when a User creates a new listening party. That

to create a listening party and that listening party has a Podcast. In this case, it's a PodcastEpisode, but maybe we want to create a new Podcast when a User creates a new listening party. That way you can kind of see which listening parties are available by Podcast maybe. And a User needs to be able to then set the time for when that Podcast listening party goes live time to go live. For example, the User needs to be able to start a listening party. So it has a PodcastEpisode, has a time to go live, and it has perhaps a link to the media file. So that could be the PodcastEpisode file. It could be a YouTube video to listen to this. Now, what happens when the listening party actually starts? In this case, when the listening party starts, then Users can chat during the party. In this case, they can chat in real time while the PodcastEpisode is played. And that's a good point to add. The PodcastEpisode plays in real time. So it's not able to

chat during the party. In this case, they can chat in real time while the podcast episode is played. And that's a good point to add. The podcast episode plays in real time. So it's not able to be played or paused individually on each screen. It's played on the server. So in this case, we can say that's played on the server. And then users can also react. So they can add hearts to individual parts of the podcast in real time. So users can react in real time. So once the listening party starts, anyone who joins, joins at the exact time that the podcast is being played on the server. And then perhaps we can show the live listening parties on the dashboard page. So that way, if anyone accesses the page and they don't want to start a listening party, they can see maybe ones that are currently in progress. So why don't we think about some models that we would want to create? Well, we would need a User model, but we already have that created for us. And maybe these

that are currently in progress. So why don't we think about some models that we would want to create? Well, we would need a User model, but we already have that created for us. And maybe these are just unauthenticated users for now. So we do need a ListeningParty model. And in this case, maybe that's just part of the Episode. I don't know just yet. We have the Episode model. We have a Podcast model. If we wanted to group Podcasts together, if someone started a ListeningParty for multiple episodes of a Podcast, then you can say kind of show maybe in stats or analytics of how many episodes from a single Podcast have been listened to in real time. And then maybe we have reactions and messages, in this case, chats. Okay. I think this is actually starting to take shape because now we have this simple process that I think is starting to come into fruition where we can say, we'll start with maybe creating our models and then get away for a User to create

shape because now we have this simple process that I think is starting to come into fruition where we can say, we'll start with maybe creating our models and then get away for a User to create a listening party. So now we have solid next steps for how to build this application.