Getting a single page app to be sensibly indexed by Google is not easy.

I think this is the most important point when people are deciding whether they should move their entire frontend layer to the browser in their new projects, and frankly, a lot of guys pushing (or developing) for single-page webapps don't get that.

While it is possible to have a mix of client-side routes/pushState/server-side generated template, it's actually non-trivial. So I really don't see a lot of cut and dry separation of layers anytime soon until Google can start indexing sites that fetches data after the HTML structure has arrived.

Big full-stack webapp frameworks are here to stay, tho we might see more webapp frameworks that are great at doing API first to emerge.

I've been using AngularJS for a project over the last few days and I've found that it really helps with the structure of the JS.

Some other points:

- haven't tried Angular testing yet but it has end-to-end testing (and you can swap out your backend services for mocking)

- you can use Celery (uses RabbitMQ/Redis/Mongo/whatever underneath for the broker) for offloading the jobs in Python. Just add a decorator to your work function, makes it really easy (you can also use PiCloud if you need something with more crunching power)

- ElasticSearch docs are still a bit of a minefield. I was already familiar with Solr and Lucene and I struggled with them (ElasticSearch is really nice though)

- Lucene itself is very complicated when you need it to do more for you. ElasticSearch can't protect you from that complexity but there is a mighty engine down there to solve all your searching needs

- Mongo makes dev easy, but I worry about the long term cost when things get complex. I did a job recently and found that my brain struggled to keep the internal Mongo doc structure intact.

- I wouldn't make a single page app if I wanted it indexed by google. I guess there are usecases but I haven't run into them yet.

It's still early days for this stuff and it still has a way to go. We're all going to learn some lessons along the way I'm sure.

Thanks for sharing your code, I'll look at it later when I'm not supposed to be getting a job finished :)

> Mongo makes dev easy, but I worry about the long term cost when things get complex. I did a job recently and found that my brain struggled to keep the internal Mongo doc structure intact.

I don't worry too much about that. You can use the repository patten to manage the serialisation and storage of your objects. Given this is something you'd typically do in most backends, I don't think it's a big ask. I do worry about the Mongo scare stories.

> You can use Celery (uses RabbitMQ/Redis/Mongo/whatever underneath for the broker) for offloading the jobs in Python. Just add a decorator to your work function, makes it really easy (you can also use PiCloud if you need something with more crunching power)

I can't remember evaluating Celery, so possibly I overlooked it. Perhaps it didn't work with Python 3 at the time?

I'll have to look into Angular.

Do you have a link that elaborates on N. Zaka's architecture?

I've also successfully implemented Zakas' [1] approach after watching his presentation "Scalable Javascript Application Architecture" [2] and abandoning Backbone.Aura [3]. Aura theoretically implements this, but in practice we found that it made some assumptions that were incompatible with our needs. Consequently, we rolled our own implementation.

[1] http://www.nczonline.net/blog/about/

[2] http://www.youtube.com/watch?v=vXjVFPosQHw

[3] https://github.com/aurajs/aura

Very interesting mateiral. I used backbone.js a while ago but missed Aura.

Do you know if that architecture is compatible with Angularjs' philosophy?

This video:

http://www.youtube.com/watch?v=vXjVFPosQHw

(which was also posted by politician) was very useful in explaining the theory. I also made some changes to it, but offhand I can't remember what they were. I think it was to do with the separation of starting vs initialising modules (parts of a page).

I think you're misunderstanding what a single page app is. If a single page app is degrading gracefully when Javascript is turned off then it is probably not a single page app.

What is your definition of single page app?

A web app where this is just one HTML file but the JavaScript gives it the feeling of being a whole site (client side template rendering, etc). I think in essense a single page app is one where there is no server side temp laying.

What do you think of the single page app you've described with multiple html entry points?

Say / responds with the homepage as per usual and /feed responds with a different html start point, but the same application code.

Using this technique you could create a site that responds to multiple urls with html and at the same time creates a SPA experience using a single js application (say, with backbone for example).

It's really the Rolls-Royce solution by which I mean it's a better but a lot more work. I didn't have that amount of time to commit. :)