Building collaborative HTML5 apps using a backend-as-a-service (HTML5DevConf 2013 SF)

Building collaborative HTML5 apps
using a backend-as-a-service

João Parreira

CTO for Realtime Framework

Realtime.co Cloud Services

Enterprise-grade services with global presence

Realtime.co Cloud Services
Used in TOP500 global websites

Realtime.co

Backed by $100M funding

Backend?

Usually consists of three
parts: a server, an
application and a database.

Backend-as-a-Service?

How?

What to look for?

(an example would be nice ...)

Why? (10 reasons)
caching
sharding data sync
server provisioning
scale-in/scale-out

read replicas

cluster management
CAP theorem

load balancing
monitoring

Why? (tl;dr)
You love building great web apps.

You don’t want to waste time
operating highly available
distributed backend clusters.

A little story from the trenches
Babblr: a chat platform for Tumblr users

They are ...
frontend developers
JavaScript ninjas
not SysAdmins
friends of a guy with 600K+ Tumblr
followers 

They wanted to ...
develop a chrome extension in 4 weeks
keep their hands off servers
launch it with a bang
reach every Tumblr user

Their solution?
“do what you do best and outsource the rest”
find someone to do the heavy-lifting
use a backend-as-a-service

And so they did,
they went with Firebase.

They had great press
before launch

th 6PM PST. They launched!
May 7

One hour later ...

“… we got 34,000 downloads in a
matter of 30 minutes. And what
that did is that the servers couldn’t
handle that traffic …”

What went wrong?
But you promised me love
Promised me love, love, love

Cee Lo Green

Scalable
Mobile ready
Available at all times
Real-time enabled
Truly secure

Lack of scalability
will doom your success
 Remember Babblr:
 the prototype was easy to develop ...
 everything worked during private beta ...
 but production launch was a disaster!
 The backend service was not up to the task.
 It didn’t scale when Babblr most needed it.

Your success depends
on your backend scalability
 Understand how your BaaS provider scales . Ask.
 Never talks about ops/sec? Hummm ...
 Favour reserved capacity scaling models
 Look for scaling APIs and autoscaling processes
 Be suspicious of scale limited developer plans.
What is the provider affraid of?

Mobile is
the new black!
 ~40% of internet time now on mobile devices
 Native iOS and Android SDKs are mandatory

 Push notifications are a nice plus
(APNS, GCM)
 If you’re not flirting with native apps ...you should.

Your user is king
and he demands you’re available
 Data must be stored in multiple datacenters
 Periodic backups? Disaster Recovery != Business Continuity
 Rolling deploys must be the standard procedure
 Look for service status pages
 A 99,999% SLA is quite normal ...
don’t let anyone tell you otherwise.

Life supports real-time,
your app should too
 Collaboration is easier with real-time data sync
 No persistent connection to each user?
Sorry, no real-time for you.
 We’re talking about time, latency matters. Measure.
 Look for WebSockets. They’re new but they’re awesome

Thou shalt have
a truly secured app
 If there’s a security option... turn it on!
http://robinverton.de/blog/2013/08/27/becareful-when-going-client-only-firebase/

 Don’t trust the client …

 You should be able to say “who can do what”

Thou shalt have
a truly secured app
 Favour ACLs with CRUD permissions
 Look for SSL enabled providers
 Look for providers using certified infrastructure
 Look for cryptographic methods to authenticate users
and prevent unauthorized data access

It’s Scalable
 Reserved capacity scaling model
 Different capacity for reads and writes
 Powered by Amazon DynamoDB
 Highly-scalable NoSQL database
 Shazam at SuperBowl 2012:
500.000 writes per second

It’s Scalable
(remember Babblr?)

Relaunched
with 120K+ users

It’s Mobile ready
 Objective-C SDK for iOS
 Java SDK for Android
 Push notifications with APNS+GCM
(in private beta, public in 3 weeks)

It’s highly-available
 100% uptime
(source: Site24x7)

 Multi-region
(US, EU, BR and ASIA)
 Data is saved in 3
different datacenters

It’s real-time enabled
 Data sync through WebSockets (with fallbacks)
 Powered by high-performance pub/sub message broker
 Simple event-based API:
var tableRef = storageRef.table("SomeTable");
tableRef.on("update", function(item) {
console.log(“Got an update:", item.val());
});

It’s secure
 Token-based authentication
 Permissions by ACLs with Create-Read-Update-Delete
 Roles for easier user management
 SSL encryption

It’s cost-effective
 Pay-as-you-go
 Starts from $1.5 USD/month (2 operations/sec)
 $500 USD developer offer including:
 10.000 concurrent users
 200GB storage
 10 million real-time notifications/month

One cloud backend, one API, multiple platforms

API

DynamoDB

Highly scalable

Real-time
notifications

API

Realtime Cloud Storage BaaS
API

API

Building a collaboration
HTML5 app in 5 minutes
 Group chat
 Realtime Cloud Storage (backend)
 AngularJS (MVC framework)
 Nicolas Gallagher PURE CSS SPEECH BUBBLES (pizzazz)
http://nicolasgallagher.com/pure-css-speech-bubbles/

Developer resources
 https://github.com/jparreira/Html5DevConf
 https://github.com/realtime-framework/Storage
 http://framework.realtime.co/storage

Realtime Cloud Storage : use cases
A unified backend for modern applications across platforms











Collaboration applications
Multiplayer Online Games
Social networks streams
Digital Advertising
E-commerce
Publishing
Project Management
Chats and comments
Systems monitoring dashboards
The next big thing ...

Building collaborative HTML5 apps using a backend-as-a-service (HTML5DevConf 2013 SF)

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Building collaborative HTML5 apps using a backend-as-a-service (HTML5DevConf 2013 SF)

Similar to Building collaborative HTML5 apps using a backend-as-a-service (HTML5DevConf 2013 SF) (20)

Recently uploaded

Recently uploaded (20)

Building collaborative HTML5 apps using a backend-as-a-service (HTML5DevConf 2013 SF)