Let's build the last API endpoints for our application:
- Events List - Filtered by attendance status
- Event Details - Loading all Event information
- Event Attendance routes - Marking the Event as "Attending" or "Not Attending"
- Talk Attendance routes - Marking the Talk as "Attending" or "Not Attending"
Let's quickly review what we have.
Event List
First, we'll start with our Events List. We want to have a few features there:
- Filter by the type - Attending, Future Events, Past Events, Upcoming (within 30 days)
- Pagination
- Laravel API Resource formed a response
So let's look at the code:
Greate couse, I like it a lot, I have a use case really similar (sport teams users that attend to races). A question: you create a "desktop" controller and a totally separate api controller for attend/unattend. To avoid some small repetition of code should be a best pratice to offload the business logic in a ServiceClass and use it in both controllers? If I remeber Povilas did something similar in an old video.
Thanks!
In this course, I specifically wanted to showcase it as separate functionality, as someone might want to create only an API app or combine them. This means that the course wasn't really looking into "optimizing the code" as much more could have been extracted.
That said, you can offload the business logic into a service class. In fact, I would even say that it would be better than having everything as separate units. That way, you can avoid mistakes when dealing with changes later on :)