Build a Livewire App With Me! - Refactoring Migrations and Methods

Episode - https://laracasts.com/series/lets-build-a-livewire-app/episodes/5

This episode is about thinking at the business logic to create a listening party and the podcast episode that goes with it.

When a user creates a listening party, he will provide also the url of the podcast the party will be about. With that url our app will fetch the episode’s meta data and will be able to define how long the party will be. Fetching the meta data will be done through a queue, so the user will not have to wait to get a feedback from the app when the party is being created.

With this in mind, the migrations created in a previous episode can be refactored. When they were created, the perspective was that of “static data“. But now, with the extra information about business logic, we can think of “data in movement“.

How does this translate in a migrations refactor?

Main example is the endDateTime field for the listening_parties table. At first that field was not nullable, but now it must be.

When the user creates a new listening party this is what happens:

1. A listening_party record is created

2. An episode record is created

3. A job is dispatched on the queue to fetch the episode’s meta data

4. The listening_party record is updated with a value for endDateTime since we now know how long is the episode by reading its meta data

I find working on these type of changes early on in the app development pretty fun. Laravel makes super easy to run fresh migrations and experiment with different database setups.