General strategy of this Repo about vuetober HOT 1 CLOSED

Hi, you make some good points here. This project came about because of the way that I personally was using October. The frontend tools for October, while good, do not operate at the level I needed them to. For example, how do you unit test an October component? How would you make an SPA with them? How would you integrate build tools to write modern javascript? etc...

It was these sorts of road blocks that led me to develop Vuetober, and I developed it with this mindset... "October's backend is amazing, but I want to handle the frontend". This is why I generally don't work with plain Laravel/Lumen projects. Yes, creating the APIs and the frontend would be the same as with Vuetober, but I wouldn't have the ability to quickly make beautiful lists and forms to manage everything. October's backend still gives me that, as well other things like administrator roles, dashboards, plugins I can integrate, and so on.

With that said, some of the concerns you have are totally valid. I don't think Vuetober would be a good fit for something you're looking to hand off to a client. This project is a better fit for sites that are going to have a developer working on it.

As for your concern about exposing endpoints to the public, there are no security concerns here. If you're using Vuetober with the RainLab.User plugin, just wrap your routes in this middleware I added a while back. This will give you basic authenticated routes, but if you need something fancier there should be nothing preventing you from implementing that.

And lastly, it might be possible to get Vuetober working with October's frontend tooling, I just have not dug into this much. @daftspunk even had the idea a while back to use October's component system to make plug-and-play APIs, which could be a really cool technique. I'd be interested to see the results of any experiments you (or anyone else) does with regard to this.

from vuetober.