REST+JS - Codebits 2011

413
-1

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
413
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

    ×