I have a Laravel application which is using Blade as the frontend. I'm feeling the better (more future proof) option would be to switch to Angular, Vue or React, (not entirely sure yet which one I will use but that's not the question of this post)
I've always thought that the backend code should expose an API in order for these JS frontend frameworks to work. I currently don't expose any sort of API.
I basically designed it in the normal way:
define route pointing to controller
create controller function and direct it to a view
create the Blade view
Couple of questions:
Should I redesign my backend to expose such an API?
Can I call Angular/Vue/React code from my controllers, similar to what I'm
doing with Blade?
In case the answer is yes to question 1,
shouldn't I consider changing to Lumen then?
using frontend framework means you would most likely build you backend as an API,
a common scenario is:
a single route the points to a controller which loads the angular/vue app
the angular/vue app would handle views and templates.
once the app is loaded you only need to communicate with the server through the exposed api's
you can't call you js code from laravel controller and you probably won't need to.
as for your question lumen vs laravel, I think it's up to you to decide that. both have pro's con's.
Related
I'm developing a personal project using Laravel with Inertia.js. I tried retrieving data from back-end to front-end through HandleInertiaRequests Middleware. I was wondering how will malicious people could get advantage of the data I show up in front-end. Inertia.js webpage discourages retrieving sensible data in this way, but I can't figure out how that will be possible. I apologize if my answer sound a little naive, still pretty new to Laravel ad never used Inertia before. Thanks for your time!
The HandleInertiaRequests Middleware is nothing but a way to merge data into the array that will be available to your JavaScript components (Vue, React, Svelte) on the client side.
It is just a way to avoid repeating yourself on every controller for things that you'll probably need on a lot of pages. For example, instead of getting the data for a Menu component on every controller, you do this only in the HandleInertiaRequests Middleware.
So, they only warn you to be careful with what type of data you put into it. For example, you probably don't want to pass the user password through this in the same way you wouldn't do that using a Blade view instead of Inertia.
I have a question about the use of the Laravel API.
I have a simple application where logged in users can post messages with VueJS and the Laravel API.
What is the best practice to do it?
Use the web.php router with a standard controller, example:
Route::get('/posts', 'PostController#index')->middleware('auth');
The api.php router where I insert the user token with every VueJS request, eg.
Route::get('/posts', 'PostController#index')->middleware('auth:api');
In my opinion, the use of the api.php router is only a good solution for external use (if another application wants to use my application).
Is that correct?
Yes, the api.php routes are meant to be used for any other front end that is not built in the same folder where that laravel instance is (even though there is nothing wrong using the api.php like that also)
So if you are using the views you have built in resources/views/ or as vue components inside the same app then use web.php for routes, and for "external front end" use api.php.
True. From my experience api.php is really best place in Laravel to write api end points to be consumed from external apps like android app or even for AJAX calls from within the same Laravel App using external js frameworks such as jquery, vue etc.
I'm starting a new large-scale application and after hearing a lot about VueJS + Laravel combination i thought of using it. I followed Laracasts' Learn Vue 2: Step By Step series and some tutorials to understand how it works.
But have few questions in mind:
Why do we even need to use Vue with Laravel. I understand that we can create component like <user-profile></user-profile> in Vue, and then use it in Laravel Blade. But it looks like over-complication things? Firstly we pass data from controller to blade, and then further pass it to vue. Why do we need to do that?
Laravel and Vue both have their own routing system. Which one to use?
How to structure an app using Laravel + Vue
PS. I'm making an application that will mostly be used on mobile devices.
moved from comment
Why do we even need to use Vue with Laravel.
Although you probably already knew, Vue is just one of many javascript frontend frameworks (libs?) You can consume the data send from the server any way you want. Vue is just the sister-framework of Laravel. The only thing you can probably say as to why they are mentioned together is that you can "talk" (interface) easily between them using json objects. Javascript is meant to make your page interactive, have behaviour. Use it when you need this.
Laravel and Vue both have their own routing system. Which one to use?
Whatever you want, do you want a "single page" (blade) that is rendered in 3 different pages by Vue, say like some kind of Wizard form. It really depends on where you want to put the load. I think you can think of use-cases where client side page rendering would be better, but most of the time server sided will be a great choice.
Single page applications are more snappy (faster) after initial load, but server side rendered applications are better for SEO in general. There are also ways to let a SPA render on the server to improve SEO however. And this we we can keep the discussion going for some while.
How to structure an app using Laravel + Vue
Laravel has already an example vue file under resources/assets/js/app.js. So it is safe to assume you can put everything there.
I'm currently building a web app using Laravel 5.1 and would like to start creating a native application so that my users can use their phones. I have decided that using the Ionic Framework is likely the best approach for the app and just have a few questions on marrying the two together.
I've got routes in Laravel that looks like this example:
app.dev/geckos - This is a GET request.
Which takes the currently authenticated user, uses their ID and fetches all geckos that match their user ID. It does return a blade view however.
I assume that when working with something like Ionic, the GET request would need to return JSON instead on order to loop through properly?
Is there a way that I can alter my controller to serve JSON based on if the route was something like this instead:
app.dev/api/v1/geckos
Both routes would use the GeckoController#index method, ideally I just don't want to repeat the code.
I'm fairly new to Laravel and very new to Ionic. So if I'm over complicating this theory please let me know.
Any information is appreciated on this,
Andy
Another solution which I used is to have 1. application in Laravel, which is a RESTful JSON API. Then you would have 2. Web app (in AngularJS) and 3. Mobile app in Ionic (which is based on AngularJS).
So you will create two separate applications, mobile and web, which both communicate with the same JSON API. The web would be a single-page AngularJS application, so that way you can reuse all the Angular services which communicate with the API, maybe even some controllers between your mobile Ionic and Web application.
You will save some time when creating two separate responses for mobile/web application, since you would create only one: JSON response. AngularJS will take care of rendering in both applications, that way you won't have to create separate templates for web applications in Blade, instead make all the rendering using Angular in both applications. There will be some nuances in rendering of the same content in Web and Mobile app, but it would only require creating separate js directives/css styles/html templates for both applications, using Blade you wouldn't be able to reuse any view related code between applications. Also you will be able to use the same Authentication method for both applications.
To sum up, this solution should be cleaner then your solution because you will be able to reuse backend entirely between the applications, reuse a lot of fronted stuff (like input validation code, services, filters,..), reuse Authentication and introduce looser coupling and have much clearer structure then the ugly response type switch in controllers.
EDIT:
So this can be a rough example of the structure of such project:
1. API - REST in Laravel, returning JSON
-Controllers
-Session // actions CREATE, DELETE
-User // actions CREATE, VIEW, UPDATE, DELETE..
-Gecko
2. JS application - Angular App, for both mobile and web app
-common //controllers, services, filters - most of the frontend logic which reusable between both applications
-controllers.js
-services.js
-filters.js
-mobile //this part can be hosted on some server or part of the mobile application
-app.js //separate configs for mobile app
-controllers.js //controllers only for mobile app
-directives.js
-web
-app.js //separate configs for web app (links to HTML template URLS,...)
-controllers.js //controllers only for web app
-directives.js
-services.js //or even services only for web app
3. WEB APP
-HTML Templates - bunch of static .HTML files
-Home
-Login
-Register
-Gecko
-Gecko Views...
-Some index file with layout template, which includes everything from js/common and js/web, entry point to your web application
4. MOBILE APP
-www
-index.html // must include everything from js/common and js/mobile
-templates
-Gecko
-Gecko Views...
But the structure may vary significantly, depending on what part of mobile application you want to have hosted on web server and which should be available offline, or how you want to host it, how detailed the structure might be..
Doing this would be messy because your single controller action will be returning two totally different responses.
However if you go down this route, you could add an additional header to the request from the mobile app, and then check for this to switch the response.
im trying to create a Single Page Website with DurandalJS in the frontend and Laravel as the Backend. Do you think this is a good Idea?
If yes how would I do the following:
What would your recommendation for the basic interaction between both frameworks be?
Would you rather have all the computation done in JS instead of Laravel sending calculated and styled returns?
How Do I setup Laravels controller in order to only get dynamic Data for, say a Div, instead of a whole page?
How can I adjust the browser URLs?
I hope I was specific enough, thank You in advance.
Laravel does not actually care about what framework you use to build the Frontend. Laravel is just a framework that helps you build your application with. It gives you great advantage with respect to the time spent and effort.
You can use any frontend framework that you want to build your app with. I have actually not used Durandal, but from the first look of it here is my opinion.
Durandal is built on top of jQuery, knockoutJS and requireJS. It also has a MV* architecture in place with support for eventing as well. So you could basically define routes on Laravel and initiate the communication between both the frameworks through events and ajax. Again this completely depends on the functionality that you are building.
In the overall flow of your app, consider Laravel as a Model that just gives data from a source to your app and Durandal as your views and controllers. This way, it will keep your data flow cleaner and easier to build. Computation of your functionality depends on how important and secretive the app is. If there are functionalities/implementations that you need to be secretive about, you can keep it on Laravel and just send computed data to Durandal. If its a web app that you are building, then keeping all implementation on the JS is just a right click away from knowing what and how you have built it. One can just see how the implementation is done just looking at the Javascript source of the web app. If you are building Mobile Device App, then the case is different.
Take a look at Restful Controllers. Will give you an idea on how to setup controllers to return only data. But if you need to return the div itself, then you can make use of the Basic Controllers of Laravel to perform them.
You can setup cleaner routes for the browser URL's. Take a look at Laravel Routing