• Save
REST+JS - Codebits 2011
Upcoming SlideShare
Loading in...5
×
 

REST+JS - Codebits 2011

on

  • 426 views

A talk I gave at Codebits 2011....

A talk I gave at Codebits 2011.

You can find the video here: https://codebits.eu/intra/s/session/204

Abstract:
There's an abundance of talks about developing for the web. Most of it targeted to developing mass-market websites, worrying about CDNs, SEO, bookmarks, progressive enhancement, etc.

But what if you want to build fullblown applications that just happen to be implemented in web technologies? Web apps, especially single-page, highly interactive ones, have some special characteristics.

For a long time we've been implementing web apps as if the browser was a mostly dumb terminal, and instead kept most of the logic on the server. Even current favorits like RoR or GWT keep to that old paradigm.

We'll see how we can take a REST architecture, combining it with a good dose of javascript MVP to create applications that are much closer, both in structure and in functionality, to desktop apps than to normal webpages.

By fully embracing web technology, instead of "hiding" behind some leaky abstractions, we'll be set free to take our apps to the next level. And we'll see how much nicer they are to develop.

Statistics

Views

Total Views
426
Views on SlideShare
422
Embed Views
4

Actions

Likes
1
Downloads
0
Comments
0

1 Embed 4

http://www.linkedin.com 4

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
  • \n
  • \n
  • \n
  • \n
  • CGIs -> PHP, ASPs, Java Servlets, JSPs, etc...\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • The difficulties with the browsers (slowness, incompatibility, tables)\nLack of good practices, libs and tools for JS\n
  • \n
  • \n
  • and its fast\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • XML-RPC, SOAP\n
  • /post/1/delete\n/basket/add/\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • it's the brains of the GUI\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • it's the brains of the GUI\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n

REST+JS - Codebits 2011 REST+JS - Codebits 2011 Presentation Transcript

  • REST+JSthe future forhighly interactiveweb apps?
  • The case fora new (ish)Web Appstyle
  • The Evolution of WebApps
  • statichtml
  • dynamicallygenerated static html pages
  • generatedbits of html with somejavascript for "moving things around"
  • What do thosehave in common?
  • Most of the work is done on the server
  • Does thismakesense?
  • State of the art MVC frameworks where the M the Cand even the V are server side concepts?
  • Maybe it did before
  • But now...
  • HTML+CSS gives us a verycapable presentationtechnologyand it gets more powerfuleveryday
  • Javascript, well...everybody loves it now
  • The browserseven those from Redmond are fast enough for most things
  • ...I think now theres a better way
  • Lets**really**embrace the medium
  • Lets implement the GUI of ourwebapps on the browser
  • Lets implement the GUI of our webapps on the browserall of it
  • And well use the serverfor the business logic.
  • And well use the serverfor the business logic. For a services layer
  • And well use the serverfor the business logic. For a services layer (and services are also cool now)
  • But why should we?
  • Because apps geteasier to developwhen we dont have to fight against the platform
  • Because we can make better, faster, more responsive appsthat take advantage of all of the mediumss possibilities
  • Because at the end youll get an API thrown in for free
  • Are you convinced?
  • So,Why REST?
  • Because it’s not SOAP :)
  • First,a short primer onREST
  • REST: REpresentational State TransferCool acronym, but terrible name
  • Central to REST is the concept of Resources
  • Resources are referenced by a global identifiere.g., an URI
  • Resources can havedifferent representationstext/html, application/json, application/vnd.ms- excel
  • Communication is donevia a standard interface HTTP, with all its methods (GET, PUT, POST, DELETE, etc.)
  • You do things in REST by transferring representations of the state of a resource
  • theRichardsonMaturityModel
  • Level 0One URI, one HTTP method
  • Level 1Many URIs, one HTTPmethod
  • Level 2Many URIs,each supporting many HTTPmethods
  • Level 3HATEOAS (Hypertext As The Engine Of Application State)using links for statetransitions
  • And we come tothe advantages ofREST
  • Its Simple
  • Its Proven
  • It scales **really** well
  • There’s greatlanguage support for itin all the languages that you’ll want to use
  • But, most importantly,thats what thebrowsers speak
  • And,on theBrowserside?
  • We’re building a GUILet’s turn to GUI patterns
  • MVCAn old favorite,lots of documentation,lots of experience
  • MVPVery similar to MVC,with some differences whichI think make it better.
  • M for Model
  • M for Modelcommunicates with the server
  • M for Model encapsulates the logic of the resources being manipulated.
  • M for Modelgives access to the data
  • M for Modelraises events when something interesting happensmost often when the data changes in some way
  • V for View
  • V for View notifies the Presenter of the users actions
  • V for Viewabstracts the DOM manipulation details
  • P for Presenter
  • P for Presenter tells the model toread data from the server
  • P for Presenter receives events from the model
  • P for Presenter reads data from the model
  • P for Presenter instructs the viewto present the data
  • P for Presenter receives notifications from the view of the users actions
  • P for Presenterupdates the model
  • P for Presenterinstructs the modelto send the data to the server
  • Theres **absolutely no communication**between the Model and the View
  • A Presenter maysubscribe to events from multiple Models
  • A Presenter maycommand multiple Views
  • Presenters cancommunicate with each other, but one-waycommunication is preferred
  • Advantages?
  • Strict separation of the DOMmanipulation code
  • Easier Testing
  • one place to lookto understand the GUI logic
  • one place to look for data manipulation
  • DEMOTIME
  • Letswrap up
  • Thank you! @jnelas