Closing the Gap - For all who are tired of choosing between Apps and Websites

InspiringCon 2016 talk by Wilhelm Behncke and Dmitri Pisarev

Transcript

1. Closing the gap For all who are tired of choosing between Apps and Websites
2. Wilhelm Behncke @WilhelmBehncke • Web Developer at sitegeist • Usually not dressed in white
3. Dmitri Pisarev @dimaip • Christian believer • Web Developer at SFI.ru
5. RPC, anyone?
6. REST To the rescue!
7. REST (Representational State Transfer) A set of architectural principles • Stateless communication • Resources - uniquely identified via URLs • Embrace HTTP to create a unified interface
8. REST - Unified Interface GET POST PUT DELETE PATCH ... http://my-project.com/api/endpoint/{id}
9. REST - HATEOAS Hypermedia as the Engine of Application State • Provide related URLs with every resource representation • Client navigates via those URLs
10. Flow knows how to do this.
11. REST - Challenges • Requires precise specification of resources • Beware of breaking changes • Many requests
12. REST - Possible Solution in Neos Describe ad-hoc endpoints in TypoScript • Build endpoints that can be easily consumed by your client within one request • Use TypoScript, just like you would render an HTML document Example at: http://dimaip.github.io/2015/11/15/react-neos/
15. Alternatives to REST GraphQL & Falcor
16. GraphQL • Query Language rather than API • Queries are shaped just like the expected response • Let the client decide about API
17. GraphQL
18. GraphQL
19. GraphQL - Strengths • More manageable API versioning ◦ Client decides about API • Less requests ◦ Queries can express exactly the dataset needed ◦ Great to map data directly to view hierarchies • Strongly typed ◦ Application specific data schema ◦ Static code analysis on queries
20. GraphQL - Weaknesses • No HTTP Caching ◦ Everything is a POST request ◦ Chaching needs to be implemented individually • Not a standard ◦ So, it might change in the future…
21. What about Content? An approach to build a query language based API for the Content Repository
22. Content Repository • Certainly a very powerful way to store content data • Makes it easy to describe and classify content • Makes it easy to organize content in an intuitive tree structure => The perfect match for any content driven application
23. Content Repository • Traversal over contents is a common problem • It is solved for TypoScript rendering via FlowQuery • FlowQuery is very expressive and intuitive to use for this task • A FlowQuery API can easily be implemented in JavaScript
24. So, why not just use a FlowQuery subset?
25. FlowQuery in a JavaScript Client
26. Shape your results
27. Shape your results
28. FlowQuery API - Challenges • Shares problems with GraphQL ◦ No HTTP caching - everything is POST ◦ Not a standard • Number of requests need to be managed
31. Levitating Neos Content Rendering to the Client
33. The Big Picture browser Neos/ TYPO3CR nodejs Caching, Server-side rendering of React API HTML API
34. Declarative Templating Comparison of TypoScript2 and React for basic stuff
35. We love TypoScript2...
36. TypoScript2 is actually brilliant...
37. React Components vs. TS2 Objects
38. Iteration
39. Advantages of TypoScript2 Unplanned extensibility: Context-dependant customization:
40. Advantages of React Functions: PropTypes:
41. Transport Ways to deliver data to the client
42. Data Fetching: TypoScript2 + FlowQuery
43. Data Fetching: Relay + GraphQL
44. Data Fetching: React Transmit + JS FlowQuery
45. Demo github.com/dimaip/neos-react-render
46. Challenges You are basically on your own now...
49. Inline Editing Problem: editors love inline editing. Solution: render editable field annotations in JS, from node data that we have already.
50. Image Resources Problem: we should not allow the client to request images of any side, or else they would spam the cache. Solution: allow to request an image resource only of predefined sizes. But that couples server and client. Better ideas?
51. Caching Problem: we left caching behind with TypoScript. FlowQuery has no caching on its own. Solutions: • Cache on the client. Cache invalidation anyone? ◦ Cache everything, flush by hand ◦ Implement real cache invalidation mechanism on the nodejs middleware, the way we do it in TS2 ◦ Something even more advanced, perhaps Event Sourcing based
52. Wait, but isn’t it a Two-Stack CMS?
53. Feeling lost? You are not alone...
54. Benefits Use cases for this fancy approach
55. Use Case: Dynamic Websites & Content-driven Apps
56. Mess of chatty endpoints...
57. Amazing ecosystem and tooling
59. Summary • Rendering on the client brings crazy benefits • But it brings crazy challenges as well • You need to pick the right content API for the job. There is no silver bullet. • FlowQuery JS API is already around the corner. GraphQL adapter soon to follow.
60. Go for it! What are you waiting for? github.com/dimaip/neos-react-render