It's a perfectly viable approach and one that Github use.
Check out Livewire.
Be part of JetBrains PHPverse 2026 on June 9 – a free online event bringing PHP devs worldwide together.
Hi.
Imagine I have a web application where a list of recent users are shown. So in my routes/web.php I would have something like this (nothing new, basic approach):
routes file
Route::get('users/recent', [RecentUsersController::class, 'index']);
controller
class RecentUsersController
{
public function index()
{
$recentUsers = User::recent()->get(); // scopeRecent
return view('pages.recent-users', compact('recentUsers'));
}
}
views/pages/recent-users.blade.php
// navbar etc.
// content...
@include('partials.recent-users')
// footer
So my idea is to make something like this:
// routes file
Route::view('recent-users', 'pages.recent-users');
Route::get('api/users/recent', [RecentUsersController::class, 'index']);
// controller
class RecentUsersController
{
public function index()
{
$recentUsers = User::recent()->get();
if (request()->wantsJson()) {
return $recentUsers->toJson();
}
return view('partials.recent-users', compact('recentUsers'));
}
}
// pages.recent-users
// there is no $recentUsers variable available in the view so this is the approach Im talking about
// instead of using "include", make an "internal request" which returns either HTML or json (depending on the case)
// in this case it returns the html I want (the partial view rendered)
// navbar etc.
// content
<div class="container">
{!! Http::get('/api/users/recent') !!}
</div>
What do you think?
@luddinus But you’re essentially doubling your request time because now two HTTP requests need to be made to get data: one to your application, and then one your application makes to your API.
I can "reuse" the API when a mobile app is made (maybe never, lol)
YAGNI. Build it when you need it. There’s nothing stopping your building a “traditional” server-rendered application that fetches your data directly from the database, and then exposing an API if you do offer a mobile app. Don’t make bizarre, inefficient architectural decisions based on some “maybe” event.
Please or to participate in this conversation.