⇨ Click here for the Laravel article index

When creating a service or portfolio with Laravel and Vue, there are roughly two types of configurations. I think each has its merits, so I'll summarize them.

Introduction

This article is for those who are unfamiliar with terms like API or hosting.

By reading this, you might start to connect the numerous articles on Laravel × Vue that exist online.

Why did I write this?

If you don't know there are two types,

You might miss the articles you refer to

I feel like if you mix both, you might end up in a swamp.

(Simple) Pattern where Vue is inside Laravel

This means that you just need to upload a Laravel project to a server.

In Laravel, there is a package called laravel-ui that allows you to easily use Vue. By using this, a Vue template with authentication set up in about three commands is generated.

This is the pattern where Vue is inside Laravel.

In this pattern, you can import Vue components into Blade, allowing you to use CSRF tokens,

Can be easily secured

Authentication can be implemented simply with sessions

You don't have to worry about CORS

⇨ Setting up Laravel + Vue.js + Vue-Router + Vuetify

⇨ How to introduce Vuex into Laravel

(Complex) Pattern where Laravel and Vue are completely separated

On the contrary, there is also a pattern of complete separation.

Isn't this more common for the large services we see?

You create separate projects for Vue and Laravel, upload them to separate servers, and set them up to be allies to each other for security.

Representative packages used in this pattern are,

For Laravel, Laravel-Passport

For Vue, Auth-module

In this pattern, API authentication becomes essential.

⇨ Setting up Nuxt3 and Laravel8 (API) to retrieve data

Which one should you choose?

I think it depends on the person's skills, the phase of the service, and what you want to do.

Skills

The first option of Vue inside Laravel is easier.

If you lack confidence, I think it's better to start with the first option.

Phase of the service

When it comes to stages, when there are a reasonable number of engineers and the front-end and back-end are separated, I think the second option is better.

Since the first option doesn't require much time for setup, it might be better for services in the hypothesis stage.

However, if you aspire to maintain a service for a long time with high maintainability, I think it's a common sense as an engineer to start with the second option, and I personally respect that approach a lot.

And I understand the desire to create and test hypotheses quickly as well.

Therefore, no conclusion for this item!

What you want to do

Due to its nature, Vue is not suitable for SEO.

SEO refers to increasing rankings in searches like Google.

This is because Vue creates displays using JavaScript in single-page applications (SPAs),

So, if you are conscious of search rankings, the first option is not suitable.

If you are conscious of search rankings, I think it's better to use the second pattern and use the Nuxt.js framework for Vue.

What should you do for a portfolio?

I recommend the first option.

Because, at first, no matter what you do, it's difficult.

I think even creating a list page by syncing data between Vue and Laravel is tough.

With the second option, creating functions for authentication is the most difficult throughout the project,

You will fall into the pattern where the beginning is the most difficult.

Also, apart from that first part, the rest is almost the same.

If you can create the authentication part, the rest is almost the same in terms of implementation.

In Laravel, you just need to create a JSON response
In Vue, you just need to fetch data with Axios and create a display with that data

So,

"I want to be able to do it in separate patterns!"

There may be motivated people like that, but start with the first option initially, and then, as a study, only learn about authentication,

Setting up separate projects for Laravel and Nuxt.js is not slow at all.

Lower the difficulty level at first and step up to the next step once you get used to it

That's my recommendation.

(I also think Docker should be done later for similar reasons)

Reference

Laravel Official

Conclusion

That's all.

I ended up talking about something a little sensitive,

I want you to start with the lowest difficulty level as much as possible!

For feedback or complaints, please contact me via Twitter DM.

That's all!

Popular Articles

Deploy a PHP7.4 + Laravel6 project to AWS EC2

Implementing Breadcrumbs in Laravel with laravel-breadcrumbs