Laravel + Quasar 1.0 with Quasar CLI



  • @stefanvh Lifesaver 🙂



  • @stefanvh Thank you so much for this! I’ve found your starter kit very helpful while learning Quasar alongside the whole Vue/Laravel stack.

    I am stuck on a preFetch issue that maybe you can shed some light on. I have made minimal changes to your auth code but the preFetch doesn’t seem to being do its job. If I refresh the browser on a page requiring authorization or otherwise try to authenticate via a token, the router pushed the user to the login page before the token is validated. Tracking the issue, the router.beforeEach code from boot/auth.js seems to be firing before the preFetch block of code returns in the App.vue. I am having trouble understanding if this is a bug in your code or if I have something setup wrong - I thought the idea of preFetch was to avoid having to fuss with promises to avoid this exact issue, but there aren’t a lot of examples out there I can find or relate to how your code is structured. Was there a specific reason the router.beforeEach was parsed out into auth.js?

    Thanks again for the great starter kit!



  • I suppose that the original question by @lucasfernog is not answered yet. Many workarounds are provided, because other users stands that having separated projects seems to be a better approach. What if we want to perform tests using laravel-dusk ? Having separated projects will make it work ? Thanks in advance for your time.



  • @reynerhl it was asked many times here if you use search function, you’ll probably find some threads where peeps did manage to use laravel+quasar on same project folder. i myself have tried it, cloning from one of the thread posters here https://github.com/metalsadman/quasar-laravel. it’s on v1-beta, the components are still in old version tho, so check out quasar upgrade guide, and laravel docs respectively since it’s still on 5.7. about tests, no idea about it.



  • As I see it, and I’ll admit, I’m not an expert, but if you are using Quasar CLI, that means you are building a pure JS frontend app, or rather should be. So, this means nothing is being built using Blade, i.e. no server side rendering via PHP, which means the PHP side is only for an API.

    And with the CLI, you’ll need Node anyway, so to test the frontend code, you need Node based testing tools (see the testing App Extension). I’d suggest avoiding using Dusk for testing the front-end code. And I’d suggest to use other PHP testing methodologies specifically for testing the API code, which you would be writing in Laraval/ PHP.

    Or do like so many other devs have and drop PHP and learn Node outright. I did, and I’ve never looked back. 😁

    Scott



  • @s-molinari said in Laravel + Quasar 1.0 with Quasar CLI:

    Or do like so many other devs have and drop PHP and learn Node outright. I did, and I’ve never looked back. 😁

    Scott

    I’ve just decided to do just that too … I was planning to use Laravel as my backend API … but I’ve been looking at LoopBack.io and considering using that instead and the whole API creation/authorisation /integration seems so much simpler using LoopBack that I’m now planning on using that instead.



  • @digiproduct here are quite mind boggling benchmarks about backend API frameworks:

    https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=update

    in “data updates” test, laravel is placed at 186 position 🙂

    let the backend frameworks wars begin ha ha ha (evil laugh)



  • @qyloxe I’d never heard of most of those frameworks … and I’ve got no idea how to interpret that data.

    I’ll just try and see what happens



  • This post is deleted!


  • @metalsadman thanks so much for upgrading your example. Questions:
    1.- After launch quasar build, what folder should we use as entry point for our web server ? Here we are trying to keep both project togeter and maybe due to Laravel Views now support html as a file type in v5.8.18 ( https://github.com/laravel/framework/pull/28541 ) we can take advantages from this.

    2.- In your quasar.conf filee, after detecting we are in prod env, can you please explain why do you use this lines:

    cfg.plugins.push(new CopyWebpackPlugin([{
                from: path.resolve(__dirname, 'public_files'),
                to: ''
              }]))
    

    I know this is not the best example, and again, frontend app (and repo) should be separated from API, but I guess this is the main point for the thread.



  • @reynerhl

    1. not entirely sure bout this but probably related to number 2. just tested this using the api.
    2. it’s the target public folder using symlink iirc, where your quasar index.html resides.

    i’ll have to test it more soon, when i’m sort of free.



  • Finally, I able to create a workable dockerfile for development machine. Took quite a long time.

    My Humble Dockerfile



  • I am trying to do the same thing, if anyone can help, it will be welcome https://github.com/modemb/larasar



  • @stefanvh A lot of thanks


Log in to reply