We are planning to develop a web application for job applications. In the first two years we expect the traffic to be about 3'000 - 6'000 visitors per day. At a later stage the traffic will grow up to 10'000 - 20'000 visitors per day.
Is there an advantage in separating frontend and backend (frontend standalone vue.js which calls the REST-API of Laravel) in compare to a all-in-one Laravel application which includes Vue inside the blade templates?
Thank you
If you plan on delivering your product in the form of:
a REST API,
and a frontend application
Then you should definitely come up with two different repositories/project.
Starting with an "all-in-one" application for both backend REST API and frontend application looks simpler, as Laravel comes with Vue.js out of the box. But even if it's helpful regarding frontend, it is focusing on backend, PHP, and Laravel. I bet on your developers mixing backend and frontend pretty soon :)
Consider bootstrapping your frontend application with vue-cli as a standalone project, to get huge benefits from its webpack configuration, and a top-notch (frontend) developer experience. Your frontend application will be better from day one, focusing on its prerequisites: delivering high quality user experience.
laravel is a very performant framework and if you use caching techniques with a good backend architecture it will support the load without issues.
That being said, a client/API will de facto be more performant, since the only thing that will occup the bandwith will be json object instead of full pages, and for the client side you rely upon the client hardware.
Another big win for a client/API approach is for when you will want to develop Ur Mobile/Desktop apps. The API will be ready and you'll be focus on just the new clients u'll have to develop. If u were on a server serving pages and a lot done within the controller/actions returning those computed pages, you will have to extract the API from those controllers and makes those calls the API instead.
Related
I want to use laravel(as backend) and angular(as frontend).
As far as I know I can use 2 methods :-
1) I can integrate both frameworks by using API service or
2) I can use monolithic architecture style (using angular with blade template)
As per my requirements 2nd option is better because in it I can use laravel's default functionalities in angular like (Auth, user roles and permissions etc).
But I afraid that 2nd option makes the project complex and messy in future.
which is the better option?
I have used myself Laravel with Angular v2+, the way I did was to make two separate projects, one which creates the API's (The Laravel app) and one which consumes the API's (Angular v6 app). That is how it is meant to work and that is how you should approach it.
If you want to integrate the front with the back end, and still have a powerful SPA, then you can go with VueJS, there are vast resources when it comes to the Laravel Vue combination.
another thing to consider is what is this project about?
is it a client website? or just a web app? does it require SEO? beware.
make sure you fully understand (angular) universal and it's current limitations/problems.
UPDATE: I am currently using Angular 6 with with Server side rendering(universal) and a Laravel API as a Backend solution for a complex & highly ranked website in the UK.
You have API routes available which doesn't look for CSRF tokens. Use any JWT package for web token authentication implementation. Host your Angular app separately and send request to API routes.
Your Angular apps are standalone applications. They don't need Laravel for running on server. You just need to use API routes for working with data.
I'm new to Laravel.
I'm working on a project which involves a public facing website and back-office application. Both are web applications and suppose to be hosted on different domains.
Website - the Public facing website using the database to pull data.
Back-Office - Backoffice or Admin app to create/update/delete stuff again using the same database should have it's own RBAC.
The reason for keeping these two apps separately is so that on the public facing website we don't push unnecessary code and keep it lean and clean. However, both of them are using the same database so I want to create a module/app/plugin (Not sure how to name it in Laravel) which can be shared among both applications for database models or any other business logic which can be shared between both apps.
Any idea how to achieve that with laravel framework?
Based on my experience, the most obvious approach would be to have one backend (API) used by the two frontends.
API : Exposing REST endpoints, configured with proper authorizations (some endpoints would only be for admins users).
Website : A classic website (SPA or not) interacting with the business logic through the API.
Back-Office : Same story as the website.
It's somehow a microservice architecture. There is a lot of pros and cons for it, but considering you don't want to push unnecessary code, spreading into different apps seems like appropriate.
If you want to keep one code base, I would consider having a load balancer (like HaProxy or Nginx) in front of your Laravel app to handle requests from configured domains to appropriate routes. For example :
acme.com root would be / for Laravel
bo.acme.com root would be /admin for Laravel
My main application is being built with Vue (mydomain.com), I also have a REST API (api.mydomain.com) and then my assets (assets.mydomain.com).
The API is unlikely to be used by other developers, and is only for my convenience when building the spa with Vue. Considering this: would it be better to build a single Laravel application that handles all three subdomains OR have a Laravel application that handles the API, a standalone Vue build for my main application and then serve the assets as a seperate build entirely?
What are the pros/cons for a single build vs three?
I haven't used Laravel in that context but I sure prefer the more modularized approach of having different builds for different functionality.
I normally use the approach with Node.js where I have both assets and api handled by the backend. (Express app etc) and then separate build fetching the data to render in the spa using React.
This build benefits scalability since you can easilly maintain, track and debug the code. Obviously it makes it also easier for unit testing. And the performance of the SPA isn't affected by the payload routing in the backend since it runs separately and only interact upon request (REST API in my case).
I hope I provided useful insight.
I found myself in several discussions throughout the week regarding a web application under development and whether it should leverage an API that is being created.
Here's the situation. I have a PHP MVC web application with a MySQL DB as well as several mobile apps all being developed in house. For the mobile apps we're building a rest api. The big question is why should my PHP web application now use that rest api? I've always expected the use of an API to be for third party systems that need to interface with my database or for systems built on a different technology. The web app is certainly not a third party system and the services are in PHP. If the API is on a different server than the web app then I guess it could be considered a third party system... which has not been decided yet.
To me, it just seems strange to leverage the API for the web app especially since the APIs services are going to be limited to about 50% of the functions available in the web app leaving me to build the other 50% that would be unique to the web app. I also foresee a performance hit to the web app stepping through the service layer rather than just accessing the DB directly. On the other side I see more maintenance having a code base for my web app hitting the DB and similar functions built into the api for mobile apps.
Has anyone found themselves in a similar situation and can provide some technical pros and cons to why I should just use the API or can point me to a solid case study?
Pros:
What if one day you decide to move the backend app to another machine? With an API, your app code won't need to change.
What if one day you grow, and need to scale to 10000 backend apps instead of 1? With an API, your app code won't need to change.
What if one day you decide to swap out MySQL for Mongo? With an API, your app code won't need to change.
^ Enforced separation of concerns between data access layer (DB) and application
Cons:
More code up front when writing the app layer
More incremental work when you need to support a new app layer feature that your API doesn't support yet
To me, the pros clearly win.
For implementing a real-time application in Laravel like Gmail or Github, in which all things (such as opening new page, sending mail, inbox, submit forms and etc) occur in one page, I did a lot of research and found that I should use Laravel Pusher package. But I think it is not free for large projects.
Also I read https://www.codetutorial.io/laravel-5-and-socket-io-tutorial/ article (and many other articles) that uses redis with NodeJs.
Regardless of Laravel Pusher, my Question is what is best and usual way to implement real-time apps via Laravel?
I am using Laravel 5.2
As #gurghet pointed out, there is a difference between a SPA and a realtime application. Gmail is indeed a real time application instead of a SPA.
API Comes first:
If you are looking into creating REALTIME Applications, then first of all you have to create an API (REST/SOAP). Laravel and Lumen both provide an excellent code base to start your api in no time.
Choosing the right JS framework:
Once you have an API, you will need a JS framework. When it comes to REAL TIME applications, there are just a hand full of frameworks that will give you true flexibility. Angular being on the top, followed by REACT, BACKBONE and meteor.
Angular has lots of fan following/community, so it should be the appropriate choice.
The Perfect PHP Stack:
Laravel + Angular stack is great. Laravel is very flexible so you can do almost any kind of server side scripting with it. It also keeps on inspiring you to write cleaner code each time. While angular is very good with 2 way bindings. Which means that when you pass the same data to a view in different places, angular keeps track of all the changes made to the data. It also has features like PROMISES, where angular doesn't wait to get real data from the db, instead it just assumes that the data should have been updated to the db and just shows you the changes (the ones that it keeps track of) in real time.
The Authentication: The most frustrating part of the whole process, is securely authenticating users i.e passing data from angular to laravel. You will have to use OAUTH or JWT for authenticating users. Although both have been around for a while, but you wont find any good code/guides regarding authentication. I have spent lot of time here, but you can always purchase some bootstrapped / properly configured projects on codecanyon.
Sockets are the key:
No Real Time system can exist without sockets, you cant just keep hitting the db on regular intervals to check for updated values. Here sockets save the day by informing the system that updates are available, upon which you can grab the updated values from db.
Now a days services like pusher, have solved most of the problems and laravel also comes with a built-in api-client for pusher. But you are always free to use opensource softwares to create your own socketing system eg. socket.io.
What you are calling real-time apps are really called single page applications or SPAs. Real-time applications are things such as software for airplanes, trains and stock exchanges.
If you want to create SPA you don't necessarily need pushing services. I would suggest you to take a look at these front-end projects:
Angular js
React js
Vue js