When you have a very large system there is a concept known as "separation of responsibilities" , and that is precisely what you can do a head-less system (ie, no views with design in your backend framework) and then consume it with some other front-end framework.
As a learning exercise it is good that you do it. I would start here:
1) Create a new Laravel group that will return your data but in JSON.
Route::group(['prefix' => 'api/v1', 'middleware' => ['auth']], function () {
Route::resource('/datos', 'DatosController');
});
2) Create a pure front-end application using some modern framework such as Angular or Vue.js.
With this change your authentication mechanism will change since you would be using something known as RESTful API and one of its principles is that you should not keep state between each call you make (stateless) . That is, in a call you can not save session data; instead, what is done is to use a token to validate whether access to the API is authorized or not.
Here is a simple post on how to implement a RESTful API: link
I found this article very good in Spanish, I put the definition that you can also read in: link
What is REST?
REST, REpresentational State Transfer, is a type of architecture of
web development that is fully supported by the HTTP standard.
REST allows us to create services and applications that can be used
by any device or client that understands HTTP, so it's
incredibly simpler and more conventional than other alternatives that
have used in the last ten years as SOAP and XML-RPC.
REST was defined in 2000 by Roy Fielding, co-author also
of the HTTP specification. We could consider REST as a framework
to build web applications respecting HTTP.
Therefore REST is the most natural and standard architecture type
to create APIs for Internet-oriented services.
There are three levels of quality when applying REST in the
development of a web application and more specifically an API that
collected in a model called Richardson Maturity Model in honor of
type that established it, Leonard Richardson father of architecture
oriented to resources. These levels are:
Correct use of URIs Correct use of HTTP. Implement Hypermedia.
In addition to these three rules, you should never save status in the
server, all the information that is required to show the
information that is requested must be in the consultation by the
client.
By not saving state, REST gives us a lot of game, since we can scale
better without having to worry about issues like storage
session variables and even, we can play with different technologies
to serve certain parts or resources of the same API.
If you have doubts later, send me a message and I can help you more calmly.
Best regards.