We have a number of separate laravel projects using routes to implement online api's. I am creating a separate laravel 5 project to 'collect' these routes.
As theses routes can change over time, I thought it would be a sensible option to create a route in each separate laravel project which returned a json of available routes in that project. Something like;
App\Http\Controllers\RoutesController#routes
with method
public function routes(Request $request)
{
$routeCollection = Route::getRoutes();
$routePaths = [];
foreach ($routeCollection as $route) {
$routePaths[] = $route->getPath();
}
return response()->json(['routes'=> $routePaths], 200);
}
Then the collecting app can simply query this same route for each individual project url. I think this feels like a fairly good solution. However I want to check before I implement this that I am not reinventing the wheel.
Does laravel have a way to 'broadcast' all publicly available routes? - or some way to scan for all available routes from a given url? Or are there better ways of doing this?
You can get a list of all routes in the same way that the artisan route:list does, you can see the function you can call here:
https://github.com/laravel/framework/blob/6e31296d6531d0148aadf09c5536b89dda49dc27/src/Illuminate/Routing/RouteCollection.php#L243
Related
Background:
I'm building an SPA (Single Page Application) PWA (Progressive Web App) using Vue.js. I've a remote PostgreSQL database, serving the tables over HTTP with PostgREST. I've a working Workbox Service Worker and IndexedDB, which hold a local copy of the database tables. I've also registered some routes in my service-worker.js; everything is fine this far....
I'm letting Workbox cache GET calls that return tables from the REST service. For example:
https://www.example.com/api/customers will return a json object of the customers.
workbox.routing.registerRoute('https://www.example.com/api/customers', workbox.strategies.staleWhileRevalidate())
At this point, I need Workbox to do the stale-while-revalidate pattern, but to:
Not use a cache, but instead return the local version of this table, which I have stored in IndexedDB. (the cache part)
Make the REST call, and update the local version, if it has changed. (the network part)
I'm almost certain that there is no configurable option for this in this workbox strategy. So I would write the code for this, which should be fairly simple. The retrieval of the cache is simply to return the contents of the requested table from IndexedDB. For the update part, I'm thinking to add a data revision number to compare against. And thus decide if I need to update the local database.
Anyway, we're now zooming in on the actual question:
Question:
Is this actually a good way to use Workbox Routes/Caching, or am I now misusing the technology because I use IndexedDB as the cache?
and
How can I make my own version of the StaleWhileRevalidate strategy? I would be happy to understand how to simply make a copy of the existing Workbox version and be able to import it and use it in my Vue.js Service Worker. From there I can make my own necessary code changes.
To make this question a bit easier to answer, these are the underlying subquestions:
First of all, the StaleWhileRevalidate.ts (see link below) is a .ts (TypeScript?) file. Can (should) I simply import this as a module? I propably can. but then I get errors:
When I to import my custom CustomStaleWhileRevalidate.ts in my main.js, I get errors on all of the current import statements because (of course) the workbox-core/_private/ directory doesn't exist.
How to approach this?
This is the current implementation on Github:
https://github.com/GoogleChrome/workbox/blob/master/packages/workbox-strategies/src/StaleWhileRevalidate.ts
I don't think using the built-in StaleWhileRevalidate strategy is the right approach here. It might be possible to do what you're describing using StaleWhileRevalidate along with a number of custom plugin callbacks to override the default behavior... but honestly, you'd end up changing so much via plugins that starting from scratch would make more sense.
What I'd recommend that you do instead is to write a custom handlerCallback function that implements exactly the logic you want, and returns a Response.
// Your full logic goes here.
async function myCustomHandler({event, request}) {
event.waitUntil((() => {
const idbStuff = ...;
const networkResponse = await fetch(...);
// Some IDB operation go here.
return finalResponse;
})());
}
workbox.routing.registerRoute(
'https://www.example.com/api/customers',
myCustomHandler
);
You could do this without Workbox as well, but if you're using Workbox to handle some of your unrelated caching needs, it's probably easiest to also register this logic via a Workbox route.
Iʼm creating a simple SPA that will retrieve data from an API. The page itself is served by a separate backend process which is the only entity that knows the API address. As such, it also provides an endpoint that, among other things, returns the API URL:
{
"api_url_base": "http://api.example.org/v1"
}
This is needed because the whole thing is deployed at multiple sites where we donʼt have control over DNS records and it may or may not be easy to derive the API URL from the front end appʼs.
Now i need to write my Vue app so nothing can happen until i fetch and process this file. To achieve that, i added to the appʼs beforeMount method:
this.settings = axios.get('/settings.json');
and in my componentsʼ beforeMount:
var comp = this;
app.__vue__.settings.then((response) => {comp.url = response.data.api_url;});
However,it seems the componentʼs beforeMounted often runs before the appʼs, and app. __vue__.settings is undefined when i get to the componentʼs beforeMount.
Where do i go wrong? Am I putting things at wrong places, or is my approach completely wrong?
You can fetch data before mount the vue app.
axios.get('/settings.json').then(response => {
// do something with response
new Vue({
router,
store,
render: h => h(App)
}).$mount('#app')
}
One way (as suggested in the previous answer) is to make one more call, before anything else. However it brings numerous downsides.
Let me just say that it freezes the loading of your application until the response is received.
There is hope as you can cleverly use (f.e.) good ol' dependency injection to pass the required data to your app.
This article answers this question fully and completely: https://codeburst.io/passing-configuration-to-vue-js-1b96fa8f959
I have the following in my controller
class WrittersController extends Controller
{
public function index()
{
return view('backend.writters.dashboard');
}
public function store(Request $request){
//confused on when to use this
}
public function create(Request $request){
//add new user functionality
}
Now in my routes i would like to use the resource routes
Route::resource('writters','WrittersController');
Now the confusion comes in my vue axios http endpoints. I uderstand that i index is a get request but axios doesnt have a store or create point.
When should i use the store and create endpoints in the vuejs
UPDATE ON MY AXIOS. Am using axios via
axios.post("url") //how do i go about create and store here
The store function is called when you want to create i.e you will create and then store. So I usually call the create method from inside the store. I do this just to seperate the code and make it more readable. There is no store or create http requests. The store uses post request. So you will need to use post request with axios. Just use Route::resource in your web.php and then go to the terminal and check your routes with
php artisan routes (laravel 4)
php artisan route:list (laravel 5)
This will list all your registered routes and tell you which functions they use.
You use the other resources in the same way you used it for the get request.
Assuming your resource route looks like the following.
Route::resource('/mydata', 'MyDataController');
You would construct your requests in the following manner.
As you observed already, if you use axios.get('/mydata') you are routed to the index method. However if you use axios.post('/mydata'), Laravel will automatically route you to the store method.
If you want to use the create action you change the url to use axios.get('/mydata/create') and you are routed to the create method. Please note that the create action is not used for creating the record but rather for fetching the view where the user will create the record, e.g. a form. Then you will store the data entered in that form with a POST request.
If you want to use PUT (or PATCH) you use axios.put(/mydata/{some_id}) and you are routed to the update method.
So Laravel handles all the routing automatically for you depending on the type of request that is made (GET, POST, PUT/PATCH, DELETE). You only need to supply a parameter in the URL for those "Verbs" that require it.
Look at the documentation here link Look for the chart or table labeled "Actions Handled By Resource Controller" and you will see the various actions what verbs to access them with, and their respective URLs and Routes.
Also note that you can add custom methods to the resource controller if needed, but you will have to define the route. You do this by declaring the route in your routes file e.g. web.php before you declare the actual resource.
Say you want to add an new post method 'archived' to mark some record as being no longer active. You would do something like the following in your routes.
Route::post('/mydata/archived/{some_id}', 'MyDataController#archive');
Route::resource('/mydata', 'MyDataController');
As demonstrated above you can use axios.put() or axios.patch() and they will both be routed to the update method. There are times when you need to handle those requests differently. For example when using a autosave feature and I want to validate some form data when only one field has changed, I would use patch to validate just that single field as follows.
public function update(Request $request, $id)
{
if($request->isMethod('patch')){
$this->validateSingle($request);
}else{
$this->validateAll($request);
}
//....
}
I am building a website based on https://github.com/Vheissu/aurelia-starter-node. It will have some backend logic in the /api area and there will be also a SPA area handled by Aurelia. I would like to:
read config in express app (https://www.npmjs.com/package/config) using require('config')
use this config on the server (usual stuff)
use a subset of this config on the client (in the Aurelia app)
I know about https://github.com/Vheissu/Aurelia-Configuration but I don't want to maintain two config sets handled by different libraries, dealing with setting the environment in two places etc.
Question: is there a clean way to do what I am looking for?
My thoughts so far:
pass something to aurelia bootstrapping logic, but I can't find any info about this
ugly solution: rendering the config as global variable into index.html (the one which is the master page for the SPA) and read it from Aurelia code, more less like How to pass data from ASP.NET WebForms to Aurelia Global Scope
I ended up keeping the configuration in the server code and rendering only the client part of it to the body of the page like so:
When defining aurelia routes for my app:
let model = {
clientConfig: {
x: 123
}
};
res.render('index.html', model);
And then in view (using ejs templates):
<script>
var config = <%- JSON.stringify(clientConfig) %>;
</script>
For me this feels much cleaner than maintaining the config in two places.
We have an old Yii application along with new Symfony one.
The basic idea is simple - I need to check if there is a route matching in Symfony application then it is cool, if not then bootstrap Yii application and try to handle the request with it.
The main idea to not instantiate AppKernel (and do not load autoload.php - since there is two different autoload.php for each project) before I am sure there is route matching.
Can I do it somehow?
We've done this before with legacy applications.
There are two approaches you can take.
Wrap your old application inside a symfony project (recommended).
Unfortunately this will indeed load the symfony front-controller and kernel. No way around that. You need to make sure that symfony can't handle the request and to do that the kernel needs to be booted up.
Use sub-directories and apache virtual hosts to load one application vs the other as needed.
Given option 1,
You can either create your own front controller that loads either symfony or yii by reading routes (from static files if using yml or xml, or annotations which will be more complex) OR EventListener (RequestListener) that listens to the HttpKernelInterface::MASTER_REQUEST and ensures that a route can be returned.
Creating your own front controller is the only way that you can make it not load the symfony kernel, but it will require you to write something that understands the routes in both frameworks (or at least symfony's) and hands off the request appropriately.
Event listener example:
public function onkernelRequest(GetResponseEvent $event)
{
if (HttpKernelInterface::MASTER_REQUEST !== $event->getRequestType()) {
return;
}
... Code to continue normally, or bootstrap yii and return a custom response... (Can include and ob_start, or make an http request, etc)
}
public function getSubscribedEvents()
{
return [
KernelEvents::REQUEST => ['onKernelRequest']
];
}
As you see, the kernel needs to be booted to ensure symfony can't serve the route. Unless creating your own front controller (as stated above).
A third approach would be to create a fallback controller, which would load up a specified URL if no route was found within symfony. Although this approach is generally used for legacy projects that lack a framework and use page scripts instead of proper routes, and definitely requires the use/help of output buffering.
The EventListener approach gives you the opportunity to create a proper Request to hand off to yii, and using what is returned to create a Response as proper symfony object (can also use ob or other options).
Thank you.
This is an alternative to vpassapera's solution -http://stovepipe.systems/post/migrating-your-project-to-symfony