SSJS, NoSQL, GAE and AppengineJS
Download as KEY, PDF5 likes738 views
Server-side JavaScript (SSJS) is gaining popularity due to factors like the rise of NoSQL databases, asynchronous programming, and JavaScript's ubiquity. SSJS environments like Node.js, CommonJS, and AppEngineJS allow developers to use JavaScript beyond the browser by running it on the server. Google App Engine also provides a platform for hosting SSJS applications and automatically scaling them.
![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](https://image.slidesharecdn.com/appenginejs-100808152155-phpapp02/85/SSJS-NoSQL-GAE-and-AppengineJS-37-320.jpg)
SSJS, NoSQL, GAE and AppengineJS
- 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