← Back to posts
Mar 02, 2026
The Rejection of the Red Dot
Why I’m building a Laravel sanctuary that doesn’t want your "attention.
Hey Friends,
We have become Pavlovian dogs to the "Red Dot." That tiny, circular notification badge has hijacked our relationship with our hobbies. We no longer read for the story; we log pages to see a number go up or to keep a "streak" alive.
I continue this week on Alcove. As we are completing our first sprint in building this application together. I want to recap on what we have done so far.
1. We have completed setting up our Laravel app,
2. Deployed our Repo
3. Created our first “Bookshelf” Migration that is going to hold our data.
I will mention that I am using SQLite instead, because it’s private and there is zero configuration needed. Completely frictionless with Laravel, and great for development.
With that said, our Next Step follows in our Development Cycle.
------------2. The Intellectual Core (The Book Model)-----------------
We must create the shelves, but now we have to tell Laravel how to interact with the “books” we decided to place in them.
This is where the Model comes in, it’s the communicator as it handles all data and logic.
If you have not made your first migration, I recommend that you create them both at the same time by running:
``php artisan make:model Book -m``
“Book” creates the Logic for App/Models/Book.php
“-m” creates the xxxx_create_books_table.php file in database/migrations (Which is the Database Structure)
-------------3 . Protecting The Model----------------------------------
We would hate for our “librarian” to come into contact with the incorrect information. Therefore, we need to protect our model so that hackers cannot inject random information into our database.
This is where we open up our Book Model (Eloquent) to specify which fields are allowed to be filled.
``
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class Book extends Model
{
// These are the only fields we allow to be mass-assigned
protected $fillable = ['title', 'author', 'total_pages', 'current_page', 'notes'];
// This links the book back to you (the Owner)
public function user()
{
return $this->belongsTo(User::class);
}
}
``
Right now, I have set this privately to myself by calling the belongsTo method. Later, once we add user Auth, we can set this up for anyone who logs into the app to see only their own books.
This is the special part about Laravel. Methods, as such defines an Eloquent Relationship. On the back end, it’s the bridge in the code that tells Laravel how to translate your PHP objects into SQL queries.
But Relationships are a two-way street.
------------4. The Inverse-------------------------------------------
We have to tell the User Model (Already built into most startup Laravel Projects) that it (will own) owns many books.
``
public function books()
{
return $this->hasMany(Book::class);
}
``
We are saying here that the many books added belong to this user. This will ensure data Integrity.
Now we
``php artisan migrate``
What is happening under the hood?
Laravel connects to your SQLite database (managed by Herd), checks the migrations table to see what hasn’t been run yet, and executes the SQLite to create your books table.
If you want to see your database store a new book, you can do so by using Laravel’s Tinker.
Run
``php artisan tinker``
Once Inside Run:
``$book = new App\Models\Book(['title' => 'Any Title You Want', 'author' => 'The Author']);``
You will be able to see the output inside your terminal. It won’t save permanently because it is not attached to a user. Though it works! If you are building along all of the items above can be replaced with your specifics.
If you run into any issues with SQLite, it could be due to you building a table that already exists. If that happens, use:
``php artisan migrate:fresh``
Warning! Use this only if you do not have any data, or it’s a fresh project like this one. This clean and simple fix is telling Laravel to wipe all data and rebuild everything from scratch.
--------------------------------------------------------------------------------------------
What we’ve accomplished in Sprint 1 so far:
1. Environment Setup: We’ve got the Laravel ecosystem (Herd, SQLite) running.
2. The Schema: We’ve designed the database “shelves” (Migrations).
3. The Logic: We’ve defined the objects (Models and Relationships).
The next steps to close out Sprint 1:
1. The Controller: The “Researcher” who handles requests (e.g., “Add this book”).
2. The Routes: The “Front Desk” that leads users to the right pages.
3. The View: The “Reading Room “Where you get to interact with the app.
I believe it is easy to stress about the intricacies of building a new app. I encourage you to enjoy the process and take the experience in the same way a student would.
We can’t ``php artisan migrate: fresh`` our brains, so we are left simply with being the best version of ourselves in this craft.
I’m carving out a digital space where the only metric that matters is how many chapters I enjoyed.
What is one hobby you refuse to ‘track’ or ‘gamify’ because the joy is in the doing, not the data?
Let’s Build it Beautifully,
Fab
We have become Pavlovian dogs to the "Red Dot." That tiny, circular notification badge has hijacked our relationship with our hobbies. We no longer read for the story; we log pages to see a number go up or to keep a "streak" alive.
I continue this week on Alcove. As we are completing our first sprint in building this application together. I want to recap on what we have done so far.
1. We have completed setting up our Laravel app,
2. Deployed our Repo
3. Created our first “Bookshelf” Migration that is going to hold our data.
I will mention that I am using SQLite instead, because it’s private and there is zero configuration needed. Completely frictionless with Laravel, and great for development.
With that said, our Next Step follows in our Development Cycle.
------------2. The Intellectual Core (The Book Model)-----------------
We must create the shelves, but now we have to tell Laravel how to interact with the “books” we decided to place in them.
This is where the Model comes in, it’s the communicator as it handles all data and logic.
If you have not made your first migration, I recommend that you create them both at the same time by running:
``php artisan make:model Book -m``
“Book” creates the Logic for App/Models/Book.php
“-m” creates the xxxx_create_books_table.php file in database/migrations (Which is the Database Structure)
-------------3 . Protecting The Model----------------------------------
We would hate for our “librarian” to come into contact with the incorrect information. Therefore, we need to protect our model so that hackers cannot inject random information into our database.
This is where we open up our Book Model (Eloquent) to specify which fields are allowed to be filled.
``
namespace App\Models;
use Illuminate\Database\Eloquent\Model;
class Book extends Model
{
// These are the only fields we allow to be mass-assigned
protected $fillable = ['title', 'author', 'total_pages', 'current_page', 'notes'];
// This links the book back to you (the Owner)
public function user()
{
return $this->belongsTo(User::class);
}
}
``
Right now, I have set this privately to myself by calling the belongsTo method. Later, once we add user Auth, we can set this up for anyone who logs into the app to see only their own books.
This is the special part about Laravel. Methods, as such defines an Eloquent Relationship. On the back end, it’s the bridge in the code that tells Laravel how to translate your PHP objects into SQL queries.
But Relationships are a two-way street.
------------4. The Inverse-------------------------------------------
We have to tell the User Model (Already built into most startup Laravel Projects) that it (will own) owns many books.
``
public function books()
{
return $this->hasMany(Book::class);
}
``
We are saying here that the many books added belong to this user. This will ensure data Integrity.
Now we
``php artisan migrate``
What is happening under the hood?
Laravel connects to your SQLite database (managed by Herd), checks the migrations table to see what hasn’t been run yet, and executes the SQLite to create your books table.
If you want to see your database store a new book, you can do so by using Laravel’s Tinker.
Run
``php artisan tinker``
Once Inside Run:
``$book = new App\Models\Book(['title' => 'Any Title You Want', 'author' => 'The Author']);``
You will be able to see the output inside your terminal. It won’t save permanently because it is not attached to a user. Though it works! If you are building along all of the items above can be replaced with your specifics.
If you run into any issues with SQLite, it could be due to you building a table that already exists. If that happens, use:
``php artisan migrate:fresh``
Warning! Use this only if you do not have any data, or it’s a fresh project like this one. This clean and simple fix is telling Laravel to wipe all data and rebuild everything from scratch.
--------------------------------------------------------------------------------------------
What we’ve accomplished in Sprint 1 so far:
1. Environment Setup: We’ve got the Laravel ecosystem (Herd, SQLite) running.
2. The Schema: We’ve designed the database “shelves” (Migrations).
3. The Logic: We’ve defined the objects (Models and Relationships).
The next steps to close out Sprint 1:
1. The Controller: The “Researcher” who handles requests (e.g., “Add this book”).
2. The Routes: The “Front Desk” that leads users to the right pages.
3. The View: The “Reading Room “Where you get to interact with the app.
I believe it is easy to stress about the intricacies of building a new app. I encourage you to enjoy the process and take the experience in the same way a student would.
We can’t ``php artisan migrate: fresh`` our brains, so we are left simply with being the best version of ourselves in this craft.
I’m carving out a digital space where the only metric that matters is how many chapters I enjoyed.
What is one hobby you refuse to ‘track’ or ‘gamify’ because the joy is in the doing, not the data?
Let’s Build it Beautifully,
Fab