Hello everyone!
I am planning to build a rather large web application with Laravel. This web application will have its own mobile native versions (iOS and Android). So my question is about the best way to architecture this thing.
Should I have something like:
Route::get('/foo', 'FooController@index');
Route::get'/bar', 'BarController@index');
and:
Route::group(array('prefix' => 'api/v1'), function() {
Route::get('/foo', 'FooController@index');
Route::get'/bar', 'BarController@index');
});
Where the mobile apps would consume only the api prefixed routes and the web app the others, or should I create two separated Laravel apps one for the web application itself and the other one just to act as api end-points for the mobile apps?
Any suggestions/advices or other ideias how to architecture this problem?
Thank you in advance :)
Both your options are valid, though I'd seperate the web app from the REST API if you can. It will let you easily upgrade your API separately from your web app and help separate those two concerns.
Along those lines, you could use a Javascript framework like Angular for the web app and have all the apps use the REST API you build in Laravel.
Basically, have all your apps (mobile and web) use the same REST API, however you choose to program them.
Good luck!
I'm building a large application that will be mobile first, using AngularJS for both iPhone and Android (using the Cordova framework). We planned that the web version will also be built with Angular, so all of my routes are meant to be API routes. It's been working very well so far. We've been in closed beta testing with our iPhone app for 3 weeks now, and we're very happy with the choices we made.
@pauljforyt I thought about that too, but building the the webapp with only AngularJS would bring more work to make it seo friendly. If you happen to know some nice resource where explains how to make SPA seo friendly, I would definitely follow that approach (I am still researching about it).
@hfalucas Unfortunately I don't have any ideas. It's something we never thought about for our web app, but isn't an issue in our case. Our public-facing site is a simple static site, and that's the part we want to be SEO friendly (and our blog). Once a user logs in, though, we'd want to prevent any search engines to index that content. I guess making the web app an Angular SPA takes care of that for us.
I'd be interested in hearing how others deal with this for SPAs that do need to be indexed by search engines, though, in case I need that for a future project.
You have two main options. You can do as discussed above or until search bots (other than Google's) all support SPAs, you can utilise PhantomJS to render static pages whenever content on your costomer-facing site changes. Granted it's a more involved setup, but probably the best option if you just have to use Angular on your customer-facing site. Also, don't forget that an Angular app doesn't always have to be bound to the body. You can use multiple tiny Angular apps on a single page if needed.
Please or to participate in this conversation.