SSJS, NoSQL, GAE and AppengineJS
Upcoming SlideShare
Loading in...5
×
 

SSJS, NoSQL, GAE and AppengineJS

on

  • 3,252 views

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

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

Statistics

Views

Total Views
3,252
Views on SlideShare
3,212
Embed Views
40

Actions

Likes
5
Downloads
28
Comments
0

1 Embed 40

http://clubajax.org 40

Accessibility

Categories

Upload Details

Uploaded via as Apple Keynote

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />
  • <br />

SSJS, NoSQL, GAE and AppengineJS SSJS, NoSQL, GAE and AppengineJS Presentation Transcript

  • SSJS, NoSQL, GAE, and AppEngineJS The new wave of web server technologies 1
  • 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
  • Web development: timeline • Shift to compiled languages and managed infrastructure: • 1995: Java • 1997: Java Servlet • 2001: C# • 2002: .NET 3 View slide
  • 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 View slide
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • Factor: NoSQL • Grossly incomplete, alphabetized sample list: • BigTable (Google’s formerly secret sauce). • Cassandra, CouchDB • memcached, memcachedb, MongoDB • Persevere, Redis, Riak 11
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • SSJS: CommonJS • Provides interoperability standards and guidelines. • Defines a common module format. • Targets synchronous loader => not exactly browser-friendly. 20
  • 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
  • SSJS: CommonJS • Example: var sqr = require(’arithm’).sqr; exports.len = function(a, b) { return Math.sqrt(sqr(a) + sqr(b)); }; 22
  • 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
  • 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
  • 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
  • GAE: short primer • BigTable is NoSQL: • Pros: • Good performance. • Cons: • A lot of restrictions. • In general GAE has a lot of restrictions. 26
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • GAE: short primer DEMO 33
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • AppengineJS: primer DEMO 41
  • 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
  • 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
  • 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
  • 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