DEV Community: Damilola Emmanuel Olowookere

Laravel Starter Kits: Which One Should You Choose?

Damilola Emmanuel Olowookere — Thu, 30 Oct 2025 10:01:21 +0000

If you are starting a new Laravel project righ now, you're immediately faced with a choice: React, Vue, or Livewire?

All three starter kits give you authentication scaffolding out-of-the-box, but they take very different approaches.

The Quick Decision Matrix

Choose React/Vue if:

You want a modern SPA experience
Your team has JS framework expertise
You need rich component ecosystems (Shadcn, etc.)

Choose Livewire if:

You prefer staying in PHP
You want faster prototyping
Your team is comfortable with Blade

React vs Vue?

Both use Inertia.js, TypeScript, Tailwind, and include Shadcn components.

The difference? Team preference.

React: Larger ecosystem, steeper learning curve
Vue: More approachable, especially Vue 3's Composition API

Want the Deep Dive?

I've written a complete breakdown covering:

Code examples for each approach
When to use Inertia vs Livewire
Quick start commands for all three
Project structure walkthroughs
How Livewire's new JS APIs compete with React/Vue

Read the full article on my blog →

Which starter kit did you choose for your last Laravel project? Drop a comment below! 👇

AI deserves your job

Damilola Emmanuel Olowookere — Sun, 31 Mar 2024 22:56:41 +0000

In the Beginning...

OpenAI released ChatGPT in November of 2022. This arguably marked the beginning of mainstream adoption of Artificial Intelligence (AI) in our world as we know it.

It is now well over a year since this event happened, and there are lots of persons whose response to date is to panic into a BSOD with the error message "AI is taking our jobs".

The Thieves Parallel

Interestingly, this behavioral response resonated with my childhood. Some years back growing up, I lived with my parents in a middle-class enclave in Nigeria. It was commonplace for armed thieves to come to "operate" in our area or surrounding communities. However, some daredevil-level thieves communicate their visitation ahead of time. They would write ahead of time that they were coming to a particular area to operate. Yes, you read that right. They will write in plain black-and-white that they were coming to some named place for "operation", and sneakily paste the notice on paper on a community gate or some other conspicuous place. I have a theory for such a bold move, but I digress.

However, it was interesting how our local chiefs handled such messages back then. Usually, when they receive such message, they rally the men in the area, arm them, and establish a schedule of local vigilante operations. Temporary vigilante groups comprising heads of local families will then take turns to keep watch at nights for agreed periods of time. I was old enough to recall how my mom stayed awake at nights my dad's group watch the night.

The Weak Response

We can draw similarities between "AI is taking our jobs" and the thieves that announced to come operate at our area in the experience I shared above. If you are ever afraid of AI taking your job, then AI does indeed deserve to take your job. In my opinion, there is an abysmal level of "skill issue" and resistance to change that will make an individual think that an automated system could render them redundant. This will remain true for as long as we are yet to record some significant level of sentience in AI tech. And that honestly doesn't sound like a panic-worthy problem.

In the experiences I explained previously, such response is similar to one in which our local chiefs back then folded their hands instead, and the local community joining them in accepting fate and resigning to some unavoidable doom.

A Stronger Response

It is much better to give a stronger response to this fear. Why not Embrace, Extend, and Extinguish (EEE) your fear of AI? Embrace the fact that AI is here to stay. Leverage it to "extend" yourself, i.e. be able to do what you previously were unable to do before your knowledge of AI. Then extinguish the fear completely.

You need to find your own EEE strategy. For some, it may be upskilling. For others, it may be to intelligently apply the knowledge of AI to one's routines and workflows. Just do anything better than gloating over AI.

Finally

AI is actually powered by some code written by guess who? Correct! Humans like you! Look at the bigger picture of what you can do to, and with AI. Think of the million and one ways AI can make you more efficient and much better. If AI takes your job, you gave it away.

PS: Don't forget to share it with your peeps. Also, please share your thoughts in the comments section below.

Auto-loading databases in VS Code using DevDb

Damilola Emmanuel Olowookere — Tue, 09 Jan 2024 11:23:46 +0000

There is a non-zero chance that if you use VS Code, you are using the integrated terminal rather than the system terminal/cli app. This is because we love and appreciate the advantages that such an integration brings, e.g.:

Less context-switching. There is less distraction especially when you want to really focus on the task at hand. The lesser you have to switch from one app to another, the better the DX (Developer Experience). Switching to-and-from apps is obviously not good when trying to focus on a database related coding/dev task.
Contextual integration. Another advantage is that VS Code is able to provide integrations related to the currently opened workspace. e.g. The cwd defaults to the project root, you can click on links to files from the terminal to open it in the IDE, etc.

The above are just a few of the advantages when VS Code provides integrations for tools.

Now, why can't we have the same experience when working with databases? Why do we have to configure our database credentials in our project (e.g. .env in Laravel) and also configure it in another database GUI desktop app? Why do we have to switch from VS Code to TablePlus/phpmyadmin/whatever-your-favourite-database-desktop-app-is? Ask no more, because you can now use DevDb!

DevDb is a framework- and language-agnostic VS Code extension that auto-loads your database without the need for configuring database connection separately from what you already configured in your application code. It currently supports SQL, MySQL, and Postgres databases, with plans to support more databases in the future.

DevDb features

It auto-loads your database and shows your data right inside VS Code. In a Laravel project, this is done by processing some files like config/database.php, docker-compose.yml, and .env
If it cannot auto-load your database (yet 😉), you simply provide a .devdbrc file in the root of your application. This is why you can use it in any framework and any programming language
In any tool, framework, or programming language, you can open any table using the provided context menu feature. The example below is from a Node JS project:
It provides Code Lens in Laravel Eloquent models
It has a nice and intuitive interface, and makes navigation a bliss!
It has dark mode! I mean, why not? 😜
When you're not in a hurry and idle, it tells actual dad jokes:
And what's more? It's Open Source! You can tinker with the source code and PR anything you're missing as long as it's okay 😊.

You can start using DevDb right now. Check it out in the VS Code marketplace.

Understanding Composer's Dev Environment: A Beginners' Guide to Dependency Management in PHP

Damilola Emmanuel Olowookere — Fri, 23 Jun 2023 12:45:38 +0000

Let's imagine for a moment that you're building your dream house. Before you can start, you'll need a lot of different tools and materials. Now, wouldn't it be nice if you could write down a list of everything you need and someone magically brings it all to you? This is precisely the purpose of Composer in the PHP world. Do you know JavaScript's NPM? Yes, it does the same. essentially.

Composer is a tool that manages dependencies in PHP projects. Think of it as a helper who takes care of the heavy lifting when it comes to finding, downloading, and setting up the libraries your application needs to run.

The composer.json File: Your Project's Shopping List

So, how does Composer know what your project needs? The answer lies in a file named composer.json. This file, typically located at the root of your project, is like a shopping list for your project's dependencies.

In the composer.json file, there are two important sections to be aware of:

require: This section lists the libraries and packages that your application needs to function correctly. These are the dependencies that are absolutely necessary for your project.
require-dev: This section, on the other hand, lists the dependencies that you need during development. These typically include tools like unit testing libraries and debugging tools. They're not necessary for your application to run, but they make the development process much smoother.

How Does Composer Know the Development Environment?

When installing or updating the packages, Composer checks the environment by looking at the --dev or --no-dev flag provided in the command. By default, Composer assumes the development environment and installs both require and require-dev dependencies.

To install only the production dependencies (the ones listed in require), you need to specify the --no-dev flag:

composer install --no-dev

On the other hand, if you want to install both production and development dependencies, you can use the --dev flag or simply run the command without any flag:

composer install --dev

composer install

Why Should You Specify the Appropriate Environment Flag?

You asked? I knew you would. There are a few reasons:

Optimizing Dependencies: Specifying the correct environment flag ensures that your project has the necessary dependencies for the given environment. This prevents unnecessary packages from being installed in production, leading to a leaner and faster application.
Reducing Resource Usage: Development dependencies often include packages that consume system resources, such as memory and CPU. By avoiding their installation in production, you can save resources and improve the performance of your application.
Enhanced Security: Limiting the installed packages to the ones needed for the production environment can reduce the potential attack surface. This makes it harder for attackers to exploit potential vulnerabilities in the development packages that are not needed in production.

Conclusion

Understanding how Composer knows the development environment and manages the dependencies is essential for PHP developers. Composer doesn't "know" your environment by itself. Instead, you provide this information through the use of flags when running Composer commands. By specifying the appropriate environment flag, you can optimize your application's performance, reduce resource usage, and enhance its security.

PHP's First-Class Callable Syntax

Damilola Emmanuel Olowookere — Fri, 23 Jun 2023 01:43:47 +0000

This awesomess introduced in PHP 8.1 does not get the attention it deserves, IMO. I intend to use this post to show how cool it is!

PHP 8.1 introduces a more streamlined way to create callable functions, called the "first-class callable syntax". Let's dive in a littel bit into this syntax.

A little backtrack...

Previously, we use Closure::fromCallable to turn a function or method into a callable object. This function takes in a PHP callable (which could be a function name, a method, or even an anonymous function) and spits out a Closure object. A typical example would be converting the strtoupper function into a callable:

$callable = Closure::fromCallable('strtoupper');
echo $callable('foo'); // Outputs 'FOO'

This method gets the job done, but isn't it a bit too verbose? Or perhaps we can make it a tad better. PHP 8.1's new syntax seeks to eliminate this extra clutter.

The new sauce 🪄

With the new syntax, you simply call the function or method followed by ellipsis (...) to create a first-class callable. That way, you can create a callable from the strtoupper function like this:

$callable = strtoupper(...);
echo $callable('foo'); // Outputs 'FOO'

Now I will say that is so much more cleaner! You can create first-class callables from function names, class methods, static methods, and anonymous functions. Just remember that the ellipsis (...) isn't a placeholder for any specific parameter.

Hold up now, soldier!

Here's where you need to be careful though. While the new syntax seems to hint at partial function application (the idea that you can fix a number of arguments to a function), PHP doesn't currently support it. So, attempting to pass any parameters to the callable would result in a syntax error.

// Assume $text is a defined variable

$callable = str_contains($text, ...);
// A syntax error, as partial function application is not supported.

Other Considerations

The ellipsis (...) have other uses as well. One is in creating 'variadic functions', or functions that can take an indefinite number of arguments. The ellipsis also comes in handy when we want to 'spread' or distribute elements of an array or object to a function.

However, even with the introduction of first-class callables using the ellipsis, these existing uses of the ellipsis in PHP remain unchanged. So, there's no need to worry about the new callable syntax causing any disruptions to your previous work.

Also note that you can't use the syntax to instantiate new objects with the new keyword, or to declare null-safe methods or attributes.

Scope

One cool aspect of first-class callables is that they carry the scope of the location where they were created. This means a first-class callable can access private methods, as long as it's created within the object's scope.

Compatibility

This feature is new to PHP 8.1 and so can't be used with older versions. If you need to maintain compatibility with older versions, you'll have to stick with Closure::fromCallable. But if you're using PHP 8.1 or later, you'll surely love the simplicity and efficiency the first-class callable syntax brings to your coding!

I hope you found this explanation both interesting and informative. You can read more in the official docs. The journey of PHP continues, and I can't wait to see where it takes us next. Keep coding, keep learning!

Laravel migration squashing and use of SQLite in automated testing

Damilola Emmanuel Olowookere — Fri, 17 Sep 2021 22:40:21 +0000

I recently started taking more conscious efforts of improving the confidence I have in my deployments by writing automated tests.

However, since the introduction of Laravel's migration squashing, I have been having a hard time writing tests that use the RefreshDatabase trait. This is particularly because my development is typically with MySQL and testing is with SQLite.

The pains that this new squashing feature brings to sqlite testing is well documented, and Taylor himself acknowledges this, because he recommended against using in-memory sqlite db during testing (btw, in-memory sqlite db is usually the go-to solution for db testing in Laravel.)

Assuming you have already squashed your migrations into dump file and you have something like your mysql-schema.dump file, then the way I approach tests that includes migration is to:

Step 1. Convert the mysql-schema.dump SQL content to SQLite's SQL, and save the file. I typically use this tool

$ mysql2sqlite.sh mysql-schema.dump > converted.sql

Step 2. Move the new dump to Laravel's schema dump folder, and ensure to name it appropriately with the connection name.

When I follow these steps, it is now much more comfortable writing tests that use the RefreshDatabase trait with SQLite as testing db. For as long as I do not come across a better way to handle this migration-squashing-sqlite-testing thingy, I may end up re-visiting this post. So, it is a note to future self!

I hope this post saves you a few minutes of debug time. See you in the next 😎

MongoDB, Mongoose, and MongoDB Atlas (Cloud Service)

Damilola Emmanuel Olowookere — Mon, 06 Sep 2021 11:09:25 +0000

If you, like me, like short, succinct tech articles (like my previous write-up on a JS spread syntax gotcha and use cases of VueJs mixins); and you like daring tech adventures, then you are going to love this piece of The Three < insert-anything-here™️ > - eers.

IMHO, MongoDB is not just a document store, but one that is great for fast bootstrapping, especially at the ideation stage of a project. This is because at this stage, there may be no concrete decision about db schema, etc.; and things may be changing very fast with respect to db schema.

I recently used MongoDB in a project; and being my first time of using it in production, I must say it really helped in bootstrapping. This advantage of MongoDB was made more obvious to me this time around because I used it alongside PostgreSQL in this same project. The overhead I had in swapping things around in PostgreSQL was relatively higher than in MongoDB.

The part of Mongoose in all these is the awesomeness and ease it brings to using Mongoose in NodeJS apps. However, I find that it does not play nice with MongoDB Atlas, especially that a weird behaviour is not documented.

Specifically, when you need to use Mongoose to connect to a remote MongoDB Atlas db instance, you must set your authSource and ssl connection parameters appropriately, so that you won't spend a decade debugging and wiring things up.

So, there it is. I hope you enjoy this piece. See you in the next one!

Practical use-cases of Vue.js mixins

Damilola Emmanuel Olowookere — Mon, 30 Aug 2021 13:32:32 +0000

I love Vue.js, as I guess you do too (yeah, because you want to read this article). I poured this same love into the reading of the official documentation: a love commensurately reciprocated by the Vue docs team.

If you can, by all means possible, you should be using Vue 3 in your new projects

However, for some reasons that are beyond the scope of this post (/coughs/ laziness /coughs/) I somehow almost always consciously skip the mixins section. That weird voice in my head always whisper things like "here goes all these unnecessary framework over-complication stuff"

So, if you are like me, you have been using Vue for a while now, and you absolutely have not used mixins nor considered using it, then these 2 reasons are the advantages I have gained in using mixins in my Vue 2 projects:

1. De-congestion of Single File Components (SFCs)
When I code SFCs, I like to keep the <script> section as lean as possible. I like keeping the cognitive load of parsing my SFCs to the minimum, and mixins help a lot in this regard. Immediate advantages of this practise include:

Better code organisation
Perfect for filters (for Vue 2)
Icing on cake: easier modular development

2. Escape route for better TypeScript support
Well, Vue 3 brings better support for TypeScript. For Vue 2, the most optimal TS experience is gotten by setting up Class-Style Components.

However, with mixins, I can have a .ts mixin file and do all my Safe Coding™️ there without worrying about limited TS support in SFC files.

These above are the strongest reasons I have for using mixins in my Vue 2 projects.

I hope you learned something in this piece, too.

JavaScript spread syntax gotcha

Damilola Emmanuel Olowookere — Mon, 30 Aug 2021 07:26:20 +0000

Well, we all like spreads of all kinds. But this type of spread's got a gotcha.

While it may seem obvious, it really did not occur to me until I traced a bug to it.

Consider a scenario whereby you are keeping a collection of programming/scripting languages. You now defined something like this:

const languages = {
    "interpreted": ['php', 'javascript'],
    "compiled": [
        "java", 
        {"name":"c#","preferred":true},
        "rust"
    ]
}

Now, you've got yourself a beautiful collection of languages. Suppose you want to send Bob your language collection, and you don't want whatever Bob does to his own copy of this language collection to affect yours, how do you do that?

Well, for me, as a JavaScript Senior Dev Super-guru™️ that I am, I will spread the butter on the bread, like this:

const bobsCopyOfLanguages = {...languages};

Well, suppose I know that Bob does not like C#; and I do not want Bob to know about my secret affair with Miss C#, so I smartly and swiftly coded in my lie, like so:

bobsCopyOfLanguages.compiled[1].preferred = false;

Yeah. Done and dusted. Now Bob has a Certified True Copy™️ of my Certificate of non-preference for C#. Cool!

Well, now I've sent bobsCopyOfLanguages to Bob. Now lemme get on with my own life. I'll start my life by logging my preference for C# and admire the truthiness in my deep love for C#...

console.log(languages.compiled[1].preferred);

...and lo and behold, my log shows:

false

What, when did#$%!^#&**#...

Well, curse not.

This behaviour of Spread Syntax may be obvious to many, but for me, I had to sleep over it to think this through with fresh mind this morning.

The key here is to not forget that:

Objects are passed by reference in JavaScript

So, as long as you have that cleared, then you know that what you "spread" or "copied" to Bob is effectively a copy of your languages object. However, the nested object is still copied by reference.

So, yeah, it is what it is.

One way I deal with this kind of Truly Copying™️ a light-weight object like this is:

const bobsCopyOfLanguages = JSON.parse(JSON.stringify(languages));

I hope you like my style of tech writing and learned something today!

P.S.: confession: C# is not my preferred language.

P.S.: If you do Vue, yo might be interested in my article about the Practical Use-cases of Mixins in Vue 2