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,                                 ...
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
REST+JS - Codebits 2011
REST+JS - Codebits 2011
Upcoming SlideShare
Loading in...5
×

REST+JS - Codebits 2011

350

Published on

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.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
350
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \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

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

    ×