I’ve been working on an application lately that is heavily dependent on data from a 3rd party API. To make matters more complicated the API terms of use don’t allow my app to store any of the data locally for periods longer than 48 hours. Apart from the API data, I also have a MySQL database where I store application data. Getting the data from the API was easy enough even though the SOAP-based API was absolutely awful.
In order to generate some views for the application, I needed data from my database and several different API endpoints. Oftentimes, before I can present the information to the user, data from the API and our datastore must be merged together. This would be easy if performance wasn’t an issue, I could just make multiple API calls and then based on that data make multiple database calls and have all of the information the app needed. Unfortunately, performance was really bad when I tried that!
Here’s an example of a common request to the application: A client wants to view all of the appointments at their office for a given day. To display this view we need to grab appointments from the API, then we need to grab all of the clients that are booked for those appointments from the API. After we have that data we need to go to our database and grab history, alerts, and notes and attach all of that to each client. Doing this in a procedural way spiraled out of control and became slow and unmanageable right away.
I discovered a great way to handle this type of problem; by extending the collections class. If you didn’t know, you can extend the Illuminate\Support\Collection class from your own class and add methods that are specific to your collection. For my app, I made a custom AppointmentCollection. The custom collection contains methods specific to appointments.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
<?php namespace App; use Illuminate\Support\Collection; class AppointmentCollection extends Collection { /** * Attach the related clients to all appointments in collection. * * @return $this */ public function withClients() { //logic to attach clients to appointments. return $this; } } |
Before using the AppointmentCollection class, when I would get appointments from the API, I would have to loop through them and perform actions on each item in the collection. Now I can call methods on the collection to update all of the contents and return itself. See pseudocode below for example.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 |
<?php namespace App; class AppointmentRepository { /** * Get appointments from the API * * @return AppointmentCollection */ public function getAppointmentsWithClients($params) { $api = new SomeAPIService(); $appointments = new AppointmentCollection($api->getAppointments($params)); $appointmentsWithClients = $appointments->withClients(); return $appointmentsWithClients; } } |
This is a simple concept but very powerful when used to wrap up groups of related objects in your application. Especially when the objects you are containing are not Eloquent objects. Once you have a custom collection you can encapsulate the logic that surrounds those objects. If you find yourself coming up with class names ending in “er”, like “ClientAttacher” as a service to attach clients to appointments, you might be ready for a custom collection.
2 replies on “Custom Collections – Laravel 5.3”
Cool … but the key pieces of logic are missing… namely the code to attach the clients and the code to combine that with the database data.
Hey Dale,
Thanks for the comment. I know that the code to actually attach a client isn’t there. That part of the code wasn’t the point of the article so I truncated it and added a comment to indicate that it would happen there.