Harry
Harry

Reputation: 327

Configure a completely separated front and back end web app with Laravel and VueJS

I'm planning on creating a multi-page web app using Laravel as a back-end REST API and a Vue.js front-end to consume this API.

To be clear up front, I'm not interested in code snippets of exactly how to set this up, unless some will help visualize the architecture.

What I would like to know is how this 'Split-Stack' can be deployed in a completely separated manner. I.E. neither stack shares a codebase, and are stored in completely independent repositories.

I'm not very familiar with JavaScript frameworks beyond jQuery, so I think my lack of understanding lies mainly in the Vue.js department. Some questions which stand out in particular are:

Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?

Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?

And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?

After reading many blog posts, it is obvious that this architecture is possible, but I'm struggling to find details on how exactly this is configured to be completely separate.

The tools and technologies don't necessarily matter here, but any specifics for Vue.js and Laravel are appreciated.

Upvotes: 2

Views: 5291

Answers (2)

fred
fred

Reputation: 1303

I think using Firebase or Auth0 Authentication is one of the best ways to do this. Firebase or Auth0 will take care of all the authentication for you and allow your backend to verify the authenticity of your front end. So that makes it much easer to separate the two.

There is an admin SDK for connecting Laravel to Firebase and there are templates and existing authentication SDK's for Vue. There are a few articles which sort of describe it but I haven't seen anything that pieces it all together yet. I was able to figure it out from 2 or 3 different articles and it ended up being easier than I thought it would be.

Upvotes: 0

I have a VueJS Front-End set up with an ExpressJS Back-End, which is very similar to what you are talking about. And yes, it is entirely possible. So let's take a look at each of your questions individually.

Can a Vue.js application be hosted by a web server to serve static HTML files, if so, which one is compatible?

Yes, when you run VueJS, you can either build it as a static application or serve it as a NodeJS Application.

See the Deployment section of the Vue CLI 3 documentation here. It explains how the /dist directory is used to serve the VueJS Application in the manner you are intending to.

Can both the front and back end services run on the same server, on different ports for example, and what would be any best practices for this?

I recently posted an example of how to host both your Front-End and API on the same server here. (Includes Coding Examples and Explanation). This answer references ExpressJS as the API, but the principles are the same. Really, just have your Front-End listening on port 80 and have your API operating on a different, unused port (ie: 8081).

And how is login authentication affected by running a web app in this way, and should I be looking into creating some kind of OAuth authentication between the front and back ends?

I handle all authentication on the back end. Basically, in the Vue Router, you can set a secure parameter. Then declare a router.beforeEach((to,from,next) => {}); call towards the end. This call should then check to see if the user has a valid login token and redirect them to the applications login page after setting a cookie with the URL the user was asked to login from so that they can be sent back to it after logging in.

In our case, we have the user redirected to the VueJS Route /saml/login. The /saml/login component. This component makes a call to the API and returns the address the user should be redirected to to login. In our case, it is the API (which is running on the same server, but a different port [see answer above]), www.example.com:8081/api/v1/saml_login. This then works with the IDP and receives the token and user data. This is also where you would perform you ACS functions (provisioning the user, updating the login time or user data, etc.) After receiving the token, it is placed into a cookie or other placeholder so that it can be used to validate against the token stored in the Database when the user was validated initially. (It is a best practice to set expiration's on your tokens). The user is then redirected to the url stored in the cookie that lets us know where they were asked to sign in from so they can view their content without having to look for it again. (Happy to share code on this if you want)

Upvotes: 5

Related Questions