use the same DB and have multiple servers for multiple platforms....like for mobile single sever, for web single server so that if one system gets down or crashed others can be still active ...
Transform non-api project into an api project for both flutter and web
Hey,
I have a project (only for development, learning) that hasn't a very good architecture, I knew that since I begin the project but It was just easy for me to keep doing the way I was doing since it's not meant for production...
Now, I want that same project to also work as a back-end for a flutter app, so having a web and mobile app. I would like to know what are the different ways I can go about it based on my current code. Should I just rewrite the back-end and make it an api? Adapt what I have to it can work for both web and mobile? I would like receive some advice, thanks!
Here is some of the code so you have an ideia, as you can see I don't have an api or send the result as JSON:
public function index(): View
{
$categories = Category::with('subcatCounts')
->get();
return view('forum.home', compact('categories'));
}
public function showAllTopics($cat_slug, $subcat_slug)
{
if( !empty(request()->get('q')) )
{
$accepted_parameters = [
'my-questions',
'popular-this-week',
'popular-all-time',
'no-replies'
];
abort_if( !in_array(request()->get('q'), $accepted_parameters), 404);
}
$filter = str_replace('-', '', lcfirst(ucwords(request()->get('q'), '-')));
$subcategory = SubCategory::with(['category' => function($query) use($cat_slug){
$query->where('slug', '=', $cat_slug);
}])
->where('slug', '=', $subcat_slug)
->first();
$allSubcategories = SubCategory::with(['category' => function($query) use($cat_slug){
$query->where('slug', '=', $cat_slug);
}])
->withCount('topics')
->get();
if(is_null($subcategory))
{
return redirect()->route('home');
}
if(!empty($filter))
{
$topics = $subcategory->getSubcategoryTopics()
->{$filter}()
->searchQuery(request()->get('search'))
->paginate(20);
}
else
{
$topics = $subcategory->getSubcategoryTopics()
->orderBy('created_at', 'desc')
->searchQuery(request()->get('search'))
->paginate(20);
}
return view('forum.show-subcategory', compact('topics', 'allSubcategories'));
}
public function create($cat_slug, $sub_slug)
{
$subcategory = SubCategory::select('id')
->where('slug', '=', $sub_slug)->first();
return view('forum.create-new-discussion', compact('subcategory'));
}
Should I just rewrite the back-end and make it an API?
For learning purposes, re-writing is a good exercise but you can make use of a lot of the code you already have for the web version.
When you have an API, you're generally going to write routes/endpoints that return data in JSON format (usually in your routes/api.php file). For example for a blog, you're going to want to write endpoints for all the CRUD (create, read, update, delete) functionality. A lot of the logic is the same, but instead of returning a blade view or redirecting, you're going to return JSON.
Traditional Server Rendered Web App:
public function index()
{
$posts = Post::all();
return view('index', ['posts' => $posts]);
}
API Controller that returns JSON:
public function index()
{
$posts = Post::all();
// return view('index', ['posts' => $posts]);
return response()->json($posts, 200);
}
Notice how the logic for getting the posts is the same, but in the API controller, you are returning the data in JSON format instead of passing that data to a blade view.
Now in your frontend (either your mobile flutter app, or your new single-page app) you're going to want to consume that data by making requests to it and then displaying the data you receive in the browser. In your SPA you would make use of tools like fetch or axios to do this. I'm not familiar with Flutter but I'm sure there's a similar tool that will help you make external requests.
All your frontend logic in your current web app (i.e. your Blade views) has to be re-written in your new frontends, your mobile app and your SPA (Vue, React, whatever you use).
Of course, there's a ton of other things like Authentication (check out Laravel Sanctum), routing, state management etc, but that's specific to the frontend you choose.
Now in reality, if this app was in production with active users, another option would be to keep that codebase and just expose a few endpoints via APIs so you can make a slimmed-down version for the mobile app. This is much less work than re-writing the entire app (and writing a new web frontend). Obviously, this will vary depending on what the needs of the users are.
Good luck!
Please or to participate in this conversation.