I think it might be. Extensibility, maintenance and reusability are top priorities.

In my current project, we're doing a lot of the front end in Knockout.js. It's pretty simple to integrate with Laravel (we pass the initial state of the models directly into the view and then sync updates via a JSON api), and the two-way data bindings are a big win for the front end. Knockout is a more lightweight framework than Angular; we're still using Laravel's routes, controllers, etc. Something like Knockout might be worth considering if you're worried about Angular adding too much complexity.

Our implementation is more tightly coupled than ranzor's, with the Knockout code integrated into the Laravel views, which means everything is one codebase - although it is less flexible in terms of being able to swap out the front end. That being said, the JSON endpoints we're setting up for our AJAX syncing can probably be pretty easily repurposed into a general API.

My favourite part about building an app with Laravel and Angular is it's forcing me to keep my backend thin and RESTful and really separate out all my concerns. There was certainly a bit of a learning curve, as I had to rethink a lot about how I write Laravel apps, but I've been really enjoying the process so far. You could always try creating a smaler project to test the waters, and see how you like it.

How do you guys handle session / authentification management with this architecture ? (UI impacts too)

The main thing is having two separate codebases for a bundle. Most features are going to be bundles so when we're building a site we can pick and choose and build more bundles to fit the needs of the site. I don't want to have to pull in a Laravel bundle for shopping cart functionality and then also bring in a package for the Angular side of it.

Knockout sounds interesting if everything can be bundled within Laravel.

jgoux said:

How do you guys handle session / authentification management with this architecture ? (UI impacts too)

Laravel handles this pretty well out of the box; just put the default auth filter in front of the routes for your API endpoints. Laravel manages the session cookies, which work for the AJAX calls as well. You can also set up your API calls to use HTTP basic authentication.

beaverusiv said:

The main thing is having two separate codebases for a bundle. Most features are going to be bundles so when we're building a site we can pick and choose and build more bundles to fit the needs of the site. I don't want to have to pull in a Laravel bundle for shopping cart functionality and then also bring in a package for the Angular side of it.

Knockout sounds interesting if everything can be bundled within Laravel.

I believe Laravel packages/bundles can have their own assets folders for JS etc. So if you have an Angular shopping cart module, you can just put it in the Public folder of the corresponding Laravel module. At least, I think that should work. It should also not be that difficult to set up Bower/RequireJS configurations (or some other JS dependency management tool) on a per-package basis within Laravel.

How do you guys handle google? For SEO purpoposes etc.

Decreased results on those area's is what keeping me back from using Angular in anything but the management area's.

DirkZz said:

How do you guys handle google? For SEO purpoposes etc.

Decreased results on those area's is what keeping me back from using Angular in anything but the management area's.

I haven't dealt with this personally, but it's my understanding that there are various approaches, but basically, they involve rendering hidden static HTML versions of the app's views that the crawler can see. See this project: https://github.com/steeve/angular-seo, which claims to be able to automate this.

I've also only used AngularJS for the admin section - there it's really awesome. For the frontend, I rely too much on organic search engine traffic, so it's a bit too risky for me at the moment. The above solutions seem to be nice workarounds, but for now I do it fully Laravel / HTML (with Bootstrap) for the user-facing pages.

Another thing to consider vis-a-vis SEO is that you can use parts of Angular or Knockout etc. without going all the way to a single page app. For example, we still have separate Blade views for each page and don't use front-end/hash routing, but get a lot of mileage out of Knockout's two-way bindings (which work similarly to Angular's) for updating tables, forms, controls, etc. I think Knockout is especially suited for this type of light-weight usage.