ROCA workshop @ Booster Conference 2013, Bergen, NO

Transcript

1. ROCA Embrace the Web FND & wvk, innoQ Deutschland GmbH Booster 2013, Bergen, NO 2013-03-14 We’ll take care of it. Personally.
2. Agenda source: Robbert van der Steeg 1 Hei. 2 What’s ROCA? 3 Technical Guidelines 4 UX Consequences 5 Quiz Time! . .
3. Hei. FND Frederik Dohr <fnd@innoq.com> recovering SPA enthusiast wvk Willem van Kerkhof <wvk@innoq.com> practitioner of others’ preachings . .
4. roca-style.org . .
5. Yet another Manifesto? . .
6. source: Hannes Fritz . .
7. What’s ROCA? Resource Oriented Client Architecture … server |<---- ROCA ---->| client emphasis ................................ emphasis …with server-side emphasis . .
8. Use the Web, Luke source: Barron Fujimoto HTTP client-server communication HTML content structure CSS presentational aspects JavaScript behavioral augmentation . .
9. Interlude: REST . .
10. REST: Meaningful Resources ▶ resources represent real or virtual ’things’ ▶ resources can be collections ▶ resources share a uniform interface . .
11. . .
12. REST: URIs ▶ http://example.com/session ▶ http://example.com/users/fred ▶ http://example.com/users/fred/orders ▶ http://example.com/products?colour=black ▶ https://example.com/processes/money-transfer/new ▶ https://example.com/8e184cc6cf92b8a4725417c56c34a852 . .
13. REST: Links ▶ state transitions via Links (Hypermedia) ▶ traversion of arbitrary associations ▶ links shold be generated by the server, not the client ▶ supports interface evolution ▶ abstracts from absolute locations . .
14. REST: HTTP Methods ▶ uniform interface for all resources ▶ limited number of HTTP operations (verbs) ▶ pre-defined semantics allows for optimisations (e.g. caching) HTTP verb semantics GET read information, possibly from cache PUT update or create with known URI POST create sub-resource DELETE delete, remove (logically) … plus a few more. . .
15. REST: Multiple Representations ▶ resource access via representations ▶ possibly multiple representations: HTML, XML, JSON, CSV, … ▶ HTTP supports content types and -negotiation . .
16. REST: Stateless Communication ▶ no need for communication relevant state per client ▶ massive scalability gain ▶ supports loose coupling (communication not bound to a specific server) . .
17. Back on topic… . .
18. RESTful HTTP The server application adheres to REST principles ▶ it exposes meaningful resources ▶ each resource has its own URI ▶ all necessary request handling information is contained within the request ▶ HTTP methods are used in line with their definition ▶ resource state is maintained by the server . .
19. Application Logic on Server All essential application logic resides on the server. ▶ authority & trust ▶ a service without business logic is a database . .
20. No Duplication The same functionality must not be implemented redundantly on both client and server. → no application logic on the client (JavaScript) risks: ▶ increased maintenance ▶ diverging implementations ▶ subtle differences in interpretation . .
21. POSH The server returns structured semantic HTML markup, independent of layout information or client behaviour. NB: alternative serializations are encouraged . .
22. HTML ▶ constitutes the foundation of the contract between server and client ▶ provides essential data structures with rich, standardized semantics as well as hypermedia support → Using HTML as the Media Type for your API → “lower-case semantic web” . .
23. Extensible Semantics ▶ Microformats ▶ microdata ▶ RDFa <div class="vcard"> <span class="fn">Willem van Kerkhof</span> <a class="email" href="mailto:wvk@innoq.com">wvk</a> <a class="url fn org" href="http://innoq.com">innoQ</a> </div> — hCard . .
24. Unobtrusive JavaScript JavaScript is used unobtrusively ▶ the application remains usable without JavaScript ▶ usability enhancements and convenience features are added progressively . .
25. Unobtrusive JavaScript relying on client-side JavaScript execution is risky ▶ fault tolerance ▶ transport corruption (e.g. mobile compression) ▶ security filters (e.g. firewalls or browser plugins) . .
26. Unobtrusive JavaScript <a href="javascript:doStuff();">action</a> . .
27. Unobtrusive JavaScript <a href="#" onclick="doStuff();">action</a> . .
28. Unobtrusive JavaScript <a href="/my-resource" onclick="doStuff(this.href);">action</a> . .
29. Unobtrusive JavaScript <a href="/my-resource" class="remote">action</a> . .
30. Unobtrusive JavaScript <a href="/my-resource" class="remote">action</a> var elements = document. getElementsByClassName("remote"); elements.onclick = function() { doStuff(this.href); }; . .
31. Static Assets All JavaScript and CSS code must be static. ▶ no dynamic per-request code generation <script> var message = "hello ${username}"; var element = jQuery("item_${item.id}"); </script> NB: This does not prohibit the use of preprocessors like LESS or CoffeeScript. . .
32. Progressive Enhancement source: Understanding Progressive Enhancement . .
33. Progressive Enhancement . . . . . . . “A webpage doesn’t have to look the same in every browser. In fact, a webpage shouldn’t look the same in every browser” — Nicolas Zakas offering users the best possible experience given the capabilities of their device . .
34. sources: midiman, Nicolas Zakas . .
35. Progressive Enhancement <div class="tabs"> <ul> <li> <a href="#about">About</a> </li> <li> <a href="#toc">Table of Contents</a> </li> <li> <a href="#comments">Discussion</a> </li> </ul> <p id="about">lorem ipsum dolor sit amet</p> <ol id="toc"> ... </ol> <div id="comments"> ... </div> </div> jQuery(".tabs").tabs(); → jQuery UI . .
36. Progressive Enhancement <input type="date"> jQuery("input[type=date]").datepicker(); <table class="sortable"> ... </table> jQuery("table.sortable").dataTable(); . .
37. Progressive Enhancement ▶ separation of concerns encapsulation, loose coupling ▶ maintainability & reusability through composable generic components → component lifecycle . .
38. UX Conse- quences . .
39. Links A user must be able to link to a specific piece of information ▶ e.g. by copying the address from the browser’s address bar ▶ pasting it into an e-mail or IM ▶ creating a bookmark ▶ or using any of the fancier ways to share URIs . .
40. Non-Browser Clients The server’s logic should be accessible to user clients other than a web browser. ▶ crawler, indexer (SEO for free, yay!) ▶ alternative user agent (curl, text browser, screen reader etc.) ▶ arbitrary unanticipated usage . .
41. Cookies Cookies may not be used for purposes other than authentication or user tracking. ▶ no “redirect back” information ▶ no “flash messages” ▶ no session state ▶ If it’s worth persisting, give it a proper server-side resource! . .
42. Formats Resources have additional representations in other formats. ▶ e.g. JSON, XML, CSV (read/write) ▶ …or PDF or XLSX reports (read-only) . .
43. Browser Controls The browser controls like the back, forward and refresh buttons must work as expected. back → user’s last meaningful resource refresh → no re-rendering of the login or home page ▶ mind the the POST verb! . .
44. Accessability Each page’s information and functionality must be accessible by tools like screen readers. keyboard shortcuts: fine, but not everyone uses a keyboard pointing devices: likewise . .
45. It’s your turn. . .
46. Quiz Time! ROCA or not □  □  source: Hay Kranen . .
47. When sharing a URL with another user, that user is presented with an empty page. □ ROCA? . .
48. When sharing a URL with another user, that user is presented with an empty page.  ROCA? ▶ session state? ▶ JavaScript problem? ▶ hashbang URIs? . .
49. When refreshing the page, the user is taken to the respective site’s front page. □ ROCA? . .
50. When refreshing the page, the user is taken to the respective site’s front page.  ROCA? ▶ client-side logic? ▶ HTML5 history API? ▶ where’s the REST? . .
51. After using the browser’s back button, the user is presented with an error messsage informing them to use the website’s own navigation controls instead. □ ROCA? . .
52. After using the browser’s back button, the user is presented with an error messsage informing them to use the website’s own navigation controls instead.  ROCA? ▶ where’s the REST? ▶ there should be no difference between linking, sharing and history navigation . .
53. Shortly after starting a booking process for a train journey, the user is interrupted and returns several minutes later to complete his booking. Filling out and submitting the form, he is presented with a session timeout message. □ ROCA? . .
54. Shortly after starting a booking process for a train journey, the user is interrupted and returns several minutes later to complete his booking. Filling out and submitting the form, he is presented with a session timeout message.  ROCA? ▶ Session state on server? . .
55. On a slow connection, ads, navigation elements, footers and other secondary information are slowly displayed first. Eventually, the main content is displayed. □ ROCA? . .
56. On a slow connection, ads, navigation elements, footers and other secondary information are slowly displayed first. Eventually, the main content is displayed. ? ROCA? ▶ not a ROCA validation (but still annoying) ▶ “content first” . .
57. While navigating a site, the browser’s address bar displays URLs of the form http://example.org/#!inbox http://example.org/#!compose □ ROCA? . .
58. While navigating a site, the browser’s address bar displays URLs of the form http://example.org/#!inbox http://example.org/#!compose  ROCA? ▶ client-side routing undermines most ROCA principles . .
59. Dashboard contents are loaded asynchronously via AJAX. □ ROCA? . .
60. Dashboard contents are loaded asynchronously via AJAX.  ROCA? ▶ Progressive Enhancement from simple links (→ hypermedia) . .
61. When refreshing a page displaying search results, the browser prompts the user to confirm whether they really want to submit the form again. □ ROCA? . .
62. When refreshing a page displaying search results, the browser prompts the user to confirm whether they really want to submit the form again.  ROCA? ▶ mind the POST verb! . .
63. Comments are loaded asynchronously after the page has loaded. □ ROCA? . .
64. Comments are loaded asynchronously after the page has loaded.  ROCA? ▶ depends on implementation ▶ link to comments? . .
65. The current page’s JavaScript source code is minified and obscured, thus hard to read. □ ROCA? . .
66. The current page’s JavaScript source code is minified and obscured, thus hard to read.  ROCA? . .
67. After clicking the “proceeed with secure payment” link, a browser popup window warns about an untrusted SSL certificate. After confirming its trust, a second popup asks for the user’s login credentials. □ ROCA? . .
68. After clicking the “proceeed with secure payment” link, a browser popup window warns about an untrusted SSL certificate. After confirming its trust, a second popup asks for the user’s login credentials.  ROCA? ▶ HTTP basic auth over SSL, perfect. ▶ wanna talk about trusted CAs? . .
69. Because of browser limitations in handling basic auth (e.g. no logout, no styling), form-based authentication in conjunction with cookies is being used. □ ROCA? . .
70. Because of browser limitations in handling basic auth (e.g. no logout, no styling), form-based authentication in conjunction with cookies is being used.  ROCA? ▶ OK, if all necessary state information is stored in the cookie. ▶ Basic auth for non-browser clients . .
71. Inpecting the current page’s source code reveals a minimal HTML frame with JSON data embedded in a <SCRIPT> tag. □ ROCA? . .
72. Inpecting the current page’s source code reveals a minimal HTML frame with JSON data embedded in a <SCRIPT> tag.  ROCA? ▶ think POSH! ▶ think Progressive Enhancement! . .
73. Selecting “open link in new tab” results in a blank page. □ ROCA? . .
74. Selecting “open link in new tab” results in a blank page.  ROCA? ▶ bad: <a href="javascript:...;"> ▶ different, yet still bad: <a href="#"> . .
75. Form inputs from a previous step are stored in cookies to be retrieved by JavaScript for validations in the next step. □ ROCA? . .
76. Form inputs from a previous step are stored in cookies to be retrieved by JavaScript for validations in the next step.  ROCA? ▶ Session state? ▶ Application logic on Client? . .
77. Form inputs from a previous step are stored in cookies to be retrieved by JavaScript for validations in the next step.  ROCA? ▶ Session state? ▶ Application logic on Client? ▶ think of a better solution? . .
78. Opening the current page in a second browser window renders the first page inoperable. □ ROCA? . .
79. Opening the current page in a second browser window renders the first page inoperable.  ROCA? ▶ session state . .
80. You did well. Thank you! . .
81. Key Takeaways ▶ POSH ▶ unobtrusive JavaScript ▶ RESTful HTTP ▶ server-side authority ▶ no duplication ▶ generic components . .
82. ROCAful Examples ▶ Hijax demo ▶ pjax ▶ Turbolinks ▶ TodoMVC (ROCA) . .
83. Contact innoQ Deutschland GmbH Krischerstraße 100 D-40789 Monheim Tel +49-2173-3366-0 http://www.innoq.com info@innoq.com Frederik Dohr <fnd@innoq.com> Willem van Kerkhof <wvk@innoq.com> . .