Look at the next 5 year cycle (2010) trends in web development.

1. SSJS, NoSQL, GAE, and
AppEngineJS
The new wave of web server technologies
1

2. JavaScript: beyond browser
• The program:
• Web development is changing. Again.
• Rise of NoSQL.
• Server-side JavaScript (SSJS). CommonJS.
• Short primer: Google App Engine.
• Short primer: AppengineJS.
2

3. Web development: timeline
• Shift to compiled languages and managed
infrastructure:
• 1995: Java
• 1997: Java Servlet
• 2001: C#
• 2002: .NET
3

4. Web development: timeline
• Shift to dynamic languages and “scripts”:
• 2004-2005: Ruby on Rails
• 2003-2005: Django (Python)
• 2005: TurboGears, Pylons (Python)
• 2005: Catalyst (Perl)
• Other languages followed too.
4

5. Web development: timeline
• Why the shift in mid-2000s?
• RAD
• Better understanding of performance
bottlenecks.
• CPU is not a bottleneck usually.
• Smarter building blocks.
5

6. Next shift: now
• What changed in last 5 years?
• Ajax gone mainstream: JavaScript is popular.
• Social networks require a massive scale:
high-performance, clouds.
• Existing SQL limitations started to hit
regular web developers: NoSQL.
• Rising interest in asynchronous evented
servers.
6

7. Factor: Ajax
• A lot of people familiar with JavaScript now.
• JS in browsers are asynchronous by necessity:
many people understand async techniques now.
• Distributed computing: CPU cycles can be
moved from a server to a client.
• Boosters: ECMA 262 v5, CommonJS, HTML5,
new browser arms race.
7

8. Factor: Ajax
• Better JS engines:
• Google’s V8 (used in Google Chrome).
• Opera, Mozilla, Apple improved their JS
engines greatly.
• JS is the second most popular language (after
Ruby) on Github:
• github.com/languages
8

9. Factor: NoSQL
• Theoretical and practical SQL problems:
• Optimized for indexed queries: can exhibit
poor performance in other scenarios like
frequent writes.
• Hard to scale horizontally: requires powerful
expensive servers.
• Problems of one-size-fits-all solutions:
different uses require different trade-offs.
9

10. Factor: NoSQL
• NoSQL does not mean an anti-SQL.
• The original meaning: Not Only SQL.
• Umbrella term for different data-related
technologies.
• Different classes of tasks may require
different trade-offs to improve the
performance.
10

11. Factor: NoSQL
• Grossly incomplete, alphabetized sample list:
• BigTable (Google’s formerly secret sauce).
• Cassandra, CouchDB
• memcached, memcachedb, MongoDB
• Persevere, Redis, Riak
11

12. Factor: NoSQL
• Sample of addressed problems:
• Speed at expense of data integrity.
• Transient memory-based databases.
• Simple horizontal scalability, replication, and
fault tolerance.
• Automating frequent administration tasks.
12

13. Cross-pollination: JS &
NoSQL
• Some NoSQL databases use JS as a scripting
language.
• CouchDB uses it to define views, validate
and transform objects, in MapReduce.
• Riak can use it for MapReduce queries.
• Persevere supports SSJS.
13

14. Factor: asynchronicity
• Evented/async IO vs. multi-threaded IO:
• All modern OSes use async IO under the
hood.
• Potentially it means less abstraction
penalties for async servers.
• Evented web servers (lighttpd, nginx) proved
to be great in high-performant scenarios.
• Some tasks are easier with events (Comet).
14

15. Factor: asynchronicity
• In general it is a controversial topic.
• Multi-threaded servers can be performant.
• Need good runtime and OS.
• Many tasks are easier to write as a sequential
code.
• Synchronization-free structures and clever
algorithms can avoid common problems.
15

16. Factor: asynchronicity
• But EDP (event-driven programming) rocks:
• Everything is essentially single-threaded.
• In most cases:
• No need to synchronize.
• No need to switch context.
• No need to allocate thread-related
resources.
16

17. Cross-pollination: JS & EDP
• JS programmers know EDP.
• This is exactly how we process browser
events.
• This is exactly how we do IO in most cases.
• Culturally JS looks like a good fit.
17

18. SSJS: timeline
• 1996: Netscape’s LiveWire
• 1996: Microsoft’s ASP
• 2005-2009: Helma/RingoJS, Narwhal,
Persevere, Pintura.
• 2009: ServerJS/CommonJS
• 2009: node.js
• 2009: AppengineJS
18

19. SSJS: CommonJS
• Started by Kevin Dangoor in 2009.
• Yes, the same guy who started TurboGears in
2005.
• Led by Kris Kowal.
• Targets non-browser environments.
• www.commonjs.org
19

20. SSJS: CommonJS
• Provides interoperability standards and
guidelines.
• Defines a common module format.
• Targets synchronous loader => not exactly
browser-friendly.
20

21. SSJS: CommonJS
• Modules are simple to write:
• The code is sandboxed.
• If you want to import something, assign it to
a global object named export.
• Modules are simple to use:
• Use require(module) to get its export
object.
21

22. SSJS: CommonJS
• Example:
var sqr = require(’arithm’).sqr;
exports.len = function(a, b) {
return Math.sqrt(sqr(a) + sqr(b));
};
22

23. SSJS: node.js
• The most popular SSJS environment at the
moment.
• Built on Google’s V8.
• Founded on evented IO.
• Supports some CommonJS specs.
• Has a lot of active contributors.
• Low-level libraries are written in C.
23

24. GAE: short primer
• Google App Engine: the foundation of Google.
• Provides access to a host of services used at
Google.
• Datastore (BigTable), users, mail, XMPP
(Jabber, Google Talk), URL fetch, BLOBs,
simple image processing, task queues.
• More services are coming, like Channels API
(Comet!).
24

25. GAE: short primer
• Free and paid plans are available.
• Google App Engine for Business is available.
• Python and Java SDKs are supported:
• You can use JVM-based languages too!
• JRuby
• JavaScript on Rhino.
25

26. GAE: short primer
• BigTable is NoSQL:
• Pros:
• Good performance.
• Cons:
• A lot of restrictions.
• In general GAE has a lot of restrictions.
26

27. GAE: short primer
• Examples of restrictions:
• Request processing should be less than 30
seconds.
• Response size should be less than 10M.
• App size should be less than 150M.
• These restrictions are universal:
• Paid accounts affected too.
27

28. GAE: short primer
• Free account restrictions (daily quotas):
• 1G bandwidth (in and out separately).
• 6.5h of CPU time.
• 1.3M HTTP requests.
• 10M datastore calls.
• 1G data stored.
28

29. GAE: short primer
• Examples of datastore (BigTable) restrictions:
• No joins.
• Inequality filter (<, >, <=, >=, !=) can be used
only on one property at the same time.
• Complicated sorting rules.
• Transactions can be executed only within the
same entity group.
29

30. GAE: short primer
• Wow! What is good about GAE?
• Scalability is built in and automatic.
• No need to deploy on different servers.
• No need to back up.
• Number of running instances are scaled
automatically.
• Google IO is fast.
30

31. GAE: short primer
• Wow! What is good about GAE?
• Convenient administration tools.
• Supports running several versions of your
application side-to-side.
• Easy to select the default version.
• Easy to check stats.
• Easy to administer users.
31

32. GAE: short primer
• Wow! What is good about GAE?
• Super-simple Development SDK:
• Provides the environment and two
commands: run locally, and deploy.
• Easy to run and debug locally using your
favorite development tools.
32

33. GAE: short primer
DEMO
33

34. AppengineJS: primer
• Created by George Moschovits
• Build on top of RingoJS (www.ringojs.org).
• Built on top of Rhino (JVM-based).
• Can be run on GAE!
• The foundation is Java.
34

35. AppengineJS: primer
• Faithfully implements Python API to GAE.
• Python is much closer to JS than Java.
• Google’s Python API docs can be used when
programming with AppengineJS.
• No need to know Java at all.
• It never hurts to know some Java. ;-)
35

36. AppengineJS: primer
• Internally uses Jack (like Ruby’s Rack) and
Nitro (a set of middleware and utilities).
• Shipped with an optional normal-template
package for simple templating.
• Unbelievably simple APIs.
36

37. AppengineJS: primer
• Example of a Jack web application:
• A function, which takes a request object and
returns a response object.
function(env) {
return {
status: 200,
headers: {”Content-Type”:”text/plain”},
body: [”Hello, world!”]
};
}
37

38. AppengineJS: primer
• On top of this simple specification Nitro
provides middleware functions.
• Middleware is used to pre-process a request
and to post-process a response.
• Usually middleware is nested like
matryoshka.
• The inner-most function is a request handler.
38

39. AppengineJS: primer
• Following middleware is provided by Nitro out
of box:
• dispatch() maps a requested path to a
handler function.
• setup() implements most common
operations like content size calculations and
so on.
• memcache() allows to cache responses.
39

40. AppengineJS: primer
• Following middleware is provided by Nitro out
of box:
• errors() handles exceptions.
• render() takes the result data and applies it
to a template.
• It is super easy to add your own middleware.
40

41. AppengineJS: primer
DEMO
41

42. SSJS vs. Browser for devs
• Controlled environment:
• No need to support legacy JS (like IE).
• You can freely use getters/setters.
• Array enhancements are available.
• Easier to debug.
42

43. SSJS vs. Browser for devs
• No need to worry about the download size of
programs.
• More sophisticated libraries can be used.
• JSON translates natively on both sides.
• JS techniques translate well to SSJS.
43

44. SSJS vs. Browser for devs
• Non-DOM libraries can be reused on both
sides.
• Big potential to reuse the same code client-
side and server-side. Example:
• Initial rendering of a page can be done on
the server.
• Subsequent updates/changes can be done
on the client.
44

45. Summary
• End-to-end JS solutions have a big potential.
This is a viable option for new web projects.
• New trends in web development can change
the landscape. Keep your eye on it!
• There is life beyond virtual machines and
hosted solution. Do you homework!
• Always evaluate NoSQL for your projects!
• JavaScript is fun!
45