Picplum Tech Stack - Backbone, Async Uploads, Prints API | Hacker News Reader

Picplum Tech Stack - Backbone, Async Uploads, Prints API

speakerdeck.com

75 pointslyime16 comments

I am presenting the Picplum Tech stack at the O'Reilly Fluent Conference (Javascript) in SF today. http://fluentconf.com/fluent2012/public/schedule/detail/2538...

It will be streamed live http://fluentconf.com/fluent2012/public/content/video

Oh and hey, send some free prints on us :)

https://www.picplum.com/signup/ycprints

Other Picplum cofounder here -- hope to write an in-depth post about the particulars of our Backbone usage. We've been working on something that was quite a big app refactor. Complete with require.js modules (require 2.0 just came out, had to fork requirejs-rails to get it working https://github.com/stammy/requirejs-rails)

Anything in particular you guys would like to know about our Backbone usage?

How did you guys where to place the cutoff between having a single application "page" vs having normal server-side rendered pages? It seems like you guys have somewhat of a mix here I'm just curious what percentage of the rendering is done server side vs client side. What are the relative tradeoffs between the two?

Perhaps not related to backbone but how are you encoding the different "views" in your single page application? Does the client download all of the templates upfront or how does that work? Also does the client know which template to render for a given api call or is that passed down from the server as well?

I'd be very interested in reading a blog post demonstrating how you strung all of this together! Pretty cool!

Thanks!

Client side vs server side rendering is pretty straight forward for us. Anything that is static, like the homepage, pricing, about is rendered server side. These pages don't change that often. Almost anything that is dynamic is client side. I would say 80% of the rendering is client side. Although the server does all the JSON handling and template rendering (handlebar pre-compiled templates).

Initially we had inline handlebar.js views wrapped around script tags. Now we precompile all templates into JS objects (http://handlebarsjs.com/precompilation.html). These templates are compressed and Gziped into one file and downloaded on page load. We will have two sets of templates now (common views used across the site and application specific views like account profile).

Blog post coming soon :)

Were there any issues with swapping out Backbone's built in templating for handlebarjs?

Backbone does not have built in templates. Underscore templates are very basic for our needs.

He mean't to say "No problems!" :)

* why did you choose Heroku and MongoHQ rather than EC2? Isn't Heroku super expensive once you get past the weekend project scale?

* why do you choose to extend views rather than using mixins?

* what was your experience with requireJS aside from your rails problems? Did you find it helped development or not?

Good questions.

Heroku vs EC2.

Honestly, going through YC you get a bunch of Heroku credits. You also get AWS credits but getting a production app on Heroku is very simple, especially with rails. I also have to build and manage fewer parts of the infrastructure/deployment when you are trying to scale up and down. I don't think it's that expensive if you have optimized parts of your stack. Use web for only serving API, single page app, optimized assets via CDN etc.

Extend vs Mixins.

For Picplum we are building multiple front end's that use the same models and view logic with slight modifications. For example on our new homepage (coming soon), you can upload photos, add recipients and send out photos without having to goto the app. This is our new on-boarding process. Extending makes a lot more sense her. Homepage Batch view vs App batch view, Homepage Recipients vs App Recipients.

Require.js

We are still in the middle of figuring out a stable production setup with require. It helps you structure your Backbone app more efficiently. The tough part is to figure out how to bundle your js files effectively. You probably don't want every single JS file loading asynchronously since there can be 20+ files just for the homepage.

thanks for the answers!

Re: Require.js - it is possible to build one JS file using the r.js build tool:

http://requirejs.org/docs/optimization.html#onejs

That's what we do (albeit through requirejs-rails that is a layer on top r.js)

Mind elaborating about your image upload solution? What uploader did you use in the front end? transloadit vs cloudinary vs blitline vs hosting your own ?

Can you talk a bit about why you use Transloadit?

When we first launched we ran into the 30 second heroku timeout issue that was affecting us with some users and larger uploads. The easiest option was just dropping in the Transloadit endpoint. We have a dedicated EC2 instance that we have been planning on converting to our upload box with nginx and its upload module.

Interesting reading that and after reading: http://icelab.com.au/articles/money-stress-and-the-cloud/ (tl;dr: Credit card processing was breaking because of the 30 second limit).

Sounds like it would make sense for heroku to have a configurable timeout.

Reply on news.ycombinator.com