How busy do you expect the API to be? If you're feeling a need for speed then Lumen all the way, if not then Laravel would likely be a little easier and far more flexible. Regarding the API being used for both websites and mobile apps you're likely to find JWT/JSON Web Tokens far easier to use across all platforms than a session based auth.
hi @miso,
have a look at satellizer token-based authentication module for AngularJS . It has fully functional php backend server written in Laravel 5 https://github.com/sahat/satellizer/tree/master/examples/server/php
In my opinion, Laravel suits better your project, as you plan to have a site and API. Later on, you can extract busiest API calls to Lumen server, as @SP1966 suggested above.
@SP1966, in the beginning, I do not expect the API be very busy. But lets say, in the future it would be busy as API of airbnb.com. Is it naive to assume that such heavily visited site as airbnb.com can be run on single Laravel app?
@virt, you are right, unauthenticated search queries could target separate API. It it possible to integrate Lumen into Laravel such that they share model layer (repository classes)? Or did you mean different framework instances, perhaps on different machines?
@miso I highly doubt anything as large as airbnb is running a framework like Laravel, certainly not on the API end. Besides, it makes no sense whatsoever to run a full framework like Laravel to simply respond to an API, especially a busy API. The author of Laravel himself uses a micro-framework for the busier aspects of his projects which was the motivation for developing a Laravel like micro-framework in the first place.
@SP1966 right, Taylor suggests using full Laravel and Lumen all together http://www.laravelpodcast.com/episodes/11108-episode-26-illuminated-tesla-micro-services @miso Of course, there is no sense to integrate them, as they should be totally separated instances. If you design your app well, there is no problem with extraction some parts as services)) In your case you can share auth tokens across the server instances with some kind of common storage, e.g. database.
@vitr If you use JWT tokens you shouldn't be storing any state data server side. The token is self validating, so long as each of your servers that accept the token for validation knows the secret/salt used in signing the token they can each validate it independently.