

Picplum Tech Stack - Backbone, Async Uploads, Prints API - lyime
https://speakerdeck.com/u/dodeja/p/picplum-tech-stack

======
lyime
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...](http://fluentconf.com/fluent2012/public/schedule/detail/25389)

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>

------
PStamatiou
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?

~~~
smattiso
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!

~~~
lyime
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 :)

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

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

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

------
czzarr
* 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?

~~~
lyime
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.

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

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

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

------
eugenem
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 ?

------
dzuc
Can you talk a bit about why you use Transloadit?

~~~
PStamatiou
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.

~~~
robryan
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.

