Comment by calpaterson | Hacker News Reader

Comment by calpaterson | Hacker News Reader

Parent Full thread

It's funny, this architecture he mentions of one-page-app clients on the frontend and microframework servers on the backend with Python is precisely the model I choose for a recent side project.

What I learned: - Javascript requires a lot of architecture to be sustainable over even medium size apps (I stole N. Zaka's architecture)

- Writing functional tests for Javascript is difficult. (Writing unit tests is easy)

- Most web browsers are nearly there with everything you need for one-page-apps. IE8 is the only real problem, and I think my problems are soluble.

- Python's single threaded nature requires that you make explicit effort to add offline jobs (I added a priority queue using redis)

- Elasticsearch is actually quite complicated once your needs move out of the completely trivial

- Most of the documentation for Elasticsearch assumes a working knowledge of Lucene (which I don't have).

- Mongodb is really really easy to develop against

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

Here's the backend source:

- https://github.com/calpaterson/recall

And the frontend source:

https://github.com/calpaterson/web-recall

And the current deployed version is here:

https://recall.calpaterson.com/about/

I'd love to answer any questions, I'm not as keen on one-page-apps now as I was when I started.

    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).

> Getting a single page app to be sensibly indexed by Google is not easy. if the backend is done correctly it is not a problem at all , an app should be able to degrade gracefully when javascript is deactivated. if not then it useless to bring the issue of SEO, SEO is not something to be thought about after the app development.

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. :)

Reply on news.ycombinator.com