Let’s Build a CRM using Laravel Passport — Setting up our databases and Eloquent
Creating our migrations and Eloquent models for our Clients, Contact details and Addresses.
Creating our migrations
If you’re brand new to Laravel, migrations could be an unknown term. They are basically ways of writing code to define the structure of your databases. They also give you the ability to make tweaks to tables and columns down the line that can be stored in your version control, really powerful stuff.
Today we’re going to set up the basics of our database structure, ClientsNow has asked us for something simple; clients, contact details and addresses. Not too much effort, but plenty to crack on with.
Before we get anywhere with this, we need to sit and take a minute to decide what is the minimum data required to create one of our models? Can we just have a name for a client or should we split that out into first name, middle name and surname? These decisions will make a big impact down the line.
While we’re thinking about all of this, let’s start creating the stubs for our migrations. As usual, Laravel makes our life so simple and it can be done using a simple command.
This command should make the file database/migrations/<timestamp>_create_clients_table.php containing the stub for creating a table.
A quick tip with creating migrations, if you follow the naming convention as above (create_<table_name>_table) then Laravel will actually give you a more filled out stub than just a class.
So, for the client we are going to separate their name out into 3 parts: firstname, middle_name and surname. We’re also going to accept a title (Mr, Mrs, Ms, etc.) and their date of birth. This is the data that our API is going to interact with.
For good measure, I have added Soft Deletes to this table structure so by default any deleted records are not fully deleted, only hidden from Eloquent queries. I have also included two fields, created_by and updated_by which will allow us to track which requests interacted with our records last.
Next up we have our contacts table. As contacts is a fairly ambiguous model, we’re going to need some form of type attached to determine the difference between phone numbers and email addresses. We’re also going to need the actual value of course, so let’s mark that down. Finally, we’re probably going to want to mark which one of these is the primary method of communication for the client.
Each client can have multiple contacts. We can extract this to be a one-to-many relationship. The easiest way to do this with an Eloquent model is by applying a client_id field to our contact model. Although in the interest of scalability, we could extract this into a polymorphic one-to-many relationship so the client doesn’t always have to be the parent.
Finally, we have the addresses table to consider. I believe the best way to store addresses is the default way of a column per line of the address. Otherwise you go down the territory of having JSON columns that become a pain to query, a bigger pain to update and just more work.
When it comes to the country, I think it would be a good idea to store the ISO alpha-2 country code; this means less storage and consistency of duplicated records. Because of this, we can have country_code as a field and have country as a mutated attribute on the model that fetches the actual name.
As with the contacts table, I believe it is a good idea to have a polymorphic relationship to the client so that we can assign them to other things in the future if need be.
All that is left for your this section is to tell Laravel to make these tables for you and to migrate your database. We do this by using the following command:
Creating Eloquent Models
Eloquent models are my second favourite thing in Laravel (after Collections). The give you the ability to have a class that interacts with your database table and have functions off of it etc. Incredible.
We now need to make models for our Clients, Contacts and Addresses and the relationships between them. On the face of it this sounds like a LOT of work, but don’t worry it’s actually really easy once you’ve seen it once.
The above command will create a new model in our App namespace at app/Client.php and it contains a default stub for an Eloquent model.
As you can see, there isn’t much going on in our class at the moment except for the extends Model which makes this class immensely powerful.
There are a number of properties that we should set on this class to make our lives easier down the line.
As we have our model named Client and our table is named clients, Laravel will transform the class name into the snake case pluralised form of your class name by default, so we do not need to tell the model what table it needs to look at.
We will need to tell the model what fields that we will be filling in and can be “mass assigned”. To do this, we need to have a $fillable property listing what attributes can be modified and updated in the database.
As you can see above, we have added all of the columns that we want to be able to insert/update on our client model. These will needs to match the column names that we created in our migration earlier in this lesson.
I have also added the \Illuminate\Database\Eloquent\SoftDeletes trait to this class so that Laravel can flag items for deletion rather than fully deleting them from the database.
Next up we need to do the same thing for the Contact and Address models. So we run the make model command and create our models.
Now that we have those files created, we need to attach the SoftDeletes trait to the models and then update the $fillable property.
We’ve made a lot of progress in this lesson, we now have a means of communicating with our database and the core of the CRM that we have been asked to build.
In this lesson we have covered migrations and creating Eloquent models, this is the core of any SaaS application that you will be working on. Doing things like this will be like second nature to any Laravel developer given enough time.
In the next lesson we’ll dive into Laravel Passport and start making authorised requests to our API.
Stay tuned, the next lesson will cover a lot of good stuff.
Check out the source code for this lesson here.
Thank you for reading, we’ll pick this up again soon.
Follow me on Medium and Twitter to stay updated on the series.
