I have some settings in my app that can by changed by admin (like categories of products that every user can choose from when creating new product). I'm storing them in database 'settings' table that consists of 'name' and 'value' columns.
I also added a Service Provider that adds those settings to config and caches them. I can access them from Laravel easily, but not from frontend (using Vue).
Is there any way to access Laravel config values from Vue? I've tried this answer but with no success. Should I make request for settings with every API call?
If your setting is dynamic you must request them each time on a API call.
If not you can get those setting once when you deploy your fronted code.
I don't know if I'm understanding your question correctly but...
Laravel configurations are part of the backend. The only way to access them on the frontend is by passing them to it.
Unless there's some fancy trickery I'm not aware of, a Vue.js app, which loads and runs on the client-side, wouldn't have access to your server-side configurations -- unless there's something that say drags them in during compilation that I don't know about, which would strike me as risky at best.
But generally speaking, client-side headless app can't access server-side data unless the server says "here client, have this data."
E.g.
class MyApiController extends Controller
{
function getThisConfig()
{
return config('this');
}
}
With:
Route::get('/api/config/this', ['uses' => 'MyApiController#getThisConfig']);
And then your Vue.js app sends an AJAX request to /api/config/this.
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 am currently looking into Vue, as my front for my Laravel backend. Before doing anything I would like to ask a few things.
Let's assume I have a master template - a users Profile. When I first access a users profile, I get all his data (let's assume address - as another tab, personal data as another tab, and n Tabs specific ). Whenever I would access a user /user/1 I query all his sub-tabs and share this data between the tabs ( to reduce calls API ). Is such attempt possible?
When I took my first look at Vue, the first concern was that it uses Axios ( ajax ), and I do not really want to expose my endpoints, the profile data is publicly accessible so its not as simple as just gate it behind authentication. Is there a way to prerender data?
Thanks for any help.
Yes, definitely - Vue to Laravel communication is mainly done through API, especially if you cover entire front-end in Vue.js and not a mix of Vue and Bladee.
There are ways to 'kinda' prevent any abuses of your public API, but let's face it - anything can be walked around because limiting your public API will limit how your website works.
One approach would be to configure session to wipe-on-close and then generate token when someone enters the website - this way, only people who have a valid token (are currently on the website) can use public API.. but it's a two-edged sword.
I think the solution to both of your concerns would be to pass the data you need from the controller to your Blade template, and from there you echo it as json, and on you Vue side, you accept it as a component prop.
An example:
#extends('layouts.user-profile')
#section('user-data')
<user-component
:data="{{ $user }}"
>
</user-component>
#endsection
The important part here is :data={{ $user }}. Here you are echoing out the $user php variable, and Laravel will automatically convert it to json.
If you are not familiar with Vue component props, here is the documentation: https://v2.vuejs.org/v2/guide/components.html#Passing-Data-to-Child-Components-with-Props
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.
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.
Where do you guys put your static pages, like "home", in an MVC framework? Do you have a "home" controller? A "pages" controller? Do you create actions for each static page?
I'm using CFWheels now, and I'm trying to figure out the best place to put them.
Edit: Apparently CFWheels doesn't require you to create actions for all your views. So you can just create an empty controller and call the views like actions, but not have to write out the blank functions.
CakePHP (and I guess, Ruby On Rails) has a "pages" controller. There is a routing function which redirects requests to /pages/foo to /pages/display/foo. Similarly, / is redirected to /pages/display/home. The display action looks up the views/pages folder for any file with a matching name and renders that.
At the end of the day, a static page is a view without a model, that was returned based on an action the user requested from your server by hitting particular route. :-)
Yes, technically you could expose the direct location of the view resource to the user and rely on the http daemon to go fetch it and return it. However, that means that the resource URL is now tied not to the semantic of the resource you want to expose, but to actual bits. This means that if you want another representation of that same resource, you have to expose it on a different URL.
So, when you create the structure of your web app, think first about the URLs and the resources you want to expose and then think how to implement each resource.
I put my static pages in the database using a simple CMS with a private admin page.
This way, the clients can make simple changes themselves.
In Wheels, you don't even need to create the controller file.
If you create your view here:
views/about/index.cfm
You don't need to create the controller file at all. Then you should be able to just call this with no problems:
http://www.example.com/about