I want to force my lumen project to run without instantiating the whole app.
For example when a route has been executed, like:
/test
when it is called, then it goes to somewhere that we defined it.
for instance: ExampleController#test
That's it.
I don't need any extra package or in fact I don't want the whole app created just for a simple request.
Is there any tool? or Is it possible?
It is possible to reduce boilerplate code from every Framework, but consider Lumen as a reduced Laravel.
First read Laravel's Request Lifecycle from docs: https://laravel.com/docs/7.x/lifecycle
Secondly, you should keep Facades, Eloquent and Services Providers commented and with this Lumen is lean as posible.
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 trying to understand the concepts of the service containers and service providers in Laravel.
At this moment, my application consists of (custom generated) models, views and controllers. So, pretty straightforward.
But now, I am planning to build a cron job which will fetch some data from an external service. This data needs to be stored in my database. I also have a view where users can manually enter the same sort of data. My controller validates the input and saves the model.
However, I don't want to copy the logic of the store function in my controller and I also don't want to call that same function from another controller.
So, I read about service providers. I followed some tutorials and read the docs on laravel.com but I somehow don't get it.
For example, I have two models: "Order" and "OrderEntry". Currently, the only function within these models is a relationship function so I can call $order->entries() and $entry->order().
Like I said I have a OrderController which validates some things and the stores a "Order" with $order->save() in the store method of the OrderController.
What's the best approach for this? I can also write a store function on the model "Order" itself. That way I can also use the same logic on different places in my app.
An ALTERNATE option to service providers and maybe not the end-all-be-all:
I had a requirement for uploading and parsing files, where the user can do it through the UI, but a dev also needs to process files manually. I used a command to be able to call it from the controller or from the CLI. Perhaps not as extensible as service providers, but a slightly simpler option. They are particularly easy to call & run from a cron job too.
If you're decided on service providers, they're unfortunately a little fuzzy for me as well. I guess maybe consider the scale of what you want to do, and the reusability of the service provider you're creating. This post helped me "get it" a little more, but I have not yet had a scenario where this has been needed. Good luck!
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.
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
I'm a Laravel 3.x beginner with a CI background.
I'm very acquainted to use controllers rather than routes and I'm having issues trying to use controllers in Laravel.
For example: let's say I have the home_controller and the "about" action. My problem is that I'm only able to access the "about" action by setting a route that points to it - something I think is undesirable.
Is there a way to get the "about" action to work without setting a route?
In laravel, everything can be accomplished using either Routes and/or controllers.
However, using both routes AND controllers is suggested for great flexibility. See this article for more informations and some examples of how to combine routes with controllers.
Anyway, if you want to use controllers (which is perfectly acceptable), you need to register them in your routes.php with Route::controller('yourcontroller') before you can use them.
Everything has to be routed in Laravel. But, you don't have to manually route each method. You could do something along the lines of Route::controller('admin').
See here: http://laravel.com/docs/routing#controller-routing
I like Mike Anthony solution. When you're using only controllers this detect method is everything you have to do - this will register automatically all of your controllers. Best hand free solution so far.
The usual controller registration is, as the guys already mentioned, this:
Route::controller('controllername');
You have to register all controllers like in the example above. It is one line of code per a controller, and it is the rule.
But if you have a static page or a login action (page), a good practice is to create a Route controller (anonymus function), not a classic controller (in controllers folder).