Upgrade to Pro — share decks privately, control downloads, hide ads and more …

RailsConf 2016: Client/Server Architecture: Past, Present, & Future

RailsConf 2016: Client/Server Architecture: Past, Present, & Future

The client/server architecture that powers much of the web is evolving. Full stack, monolithic, apps are becoming a thing of the past as new requirements have forced us to think differently about how we build apps. New client/server architectures create a clear separation of concerns between the server and the client.

As developers, we have the ability to create the new abstractions that will power the web. Understanding the past, present, and future of the client/server help us to become more active participants in the future ecosystem for building web applications.

3b308527ac4069c51d34b261d75ef976?s=128

Mike Groseclose

May 06, 2016
Tweet

Other Decks in Technology

Transcript

  1. / , , &

  2. Mike Groseclose @mikrofusion

  3. Prelude I

  4. None
  5. raise community pun awareness and support @girlswhocode Pundraiser

  6. “it's all just zeros and puns" Craig Dennis @craigsdennis $100

    “when it comes to puns, I love to be active, for the record.” “Hopefully @tenderlove gits to go to your talk” “I hope all these puns are up to spec for @tenderlove” “though a true pun comes from @tenderlove of the craft” “Though good luck keeping this on track. It might end up running out of steam” “Anyways, it's been a blast, but it's time for me to grab some Java and a good book.” Brandon Weaver @keystonelemur “there's a method missing from this madness” 
 “pundle install" Max Cantor @mcantor “you ng complete me?” Benjamin Fleischer @hazula “Be careful though stalk puns can be corny and hard on the ears.” “George RR Martin's favorite OS is Linux, because it has a killall command” “ I had a really good pizza pun, but it was too cheesy.” Chris Steinmeyer @chrisfishwood Pundraiser “I think I have to jquery your sanity.” Anshul Jain @anshizzle24 “I don't want to be MEAN, but puns are overrouted. Sorry, I just wanted to Express myself.” Nidhi Reddy @nerdyreddy “I was going to make a framework pun, but I wasn't sure how you'd React.” “Aren't you just full of SASS. Maybe you should grow a Backbone, js.” ỎNDRỠW @reesecode “Jiranny (noun) - Enslavement to Jira tickets.” Christopher Green @cg433n “CAPS LOCK: Preventing Login Since 1980s” rediibra @rediibra “guys. GUYS” Damon Bauer @damon_bauer “I hope they have sturdy keyboards for all those strongly typed languages ;)” “also if you run across a sad looking bug, you might try to console it. it's comforting and insightful” Elijah Manor @elijahmanor “Just commit yourself to it fully, it'll all add up in the end." Tim McDevOps @saintly_one “Coding Ruby now after years of writing in Java and C, I'm not sure when I'll ever return." Bryan J @WowSuchBryan “Well this is interesting and punny at the same time ..." MomMeetCoffee @mommeetcoffee “There are a lot of @GirlsWhoCode take over the world. For rails, bro." Charles Rector @chuckrector “Nice work on this, you should talk to your boss about arrays" “I was trying to find some UDP puns, but I don’t get half of them" Alex Weidmann @Effektz “I’ve heard if you hold a Unix shell up to your ear, you can hear the C" GitMonitor @GitMonitorApp “Don’t let your integers drown, because they can’t float" PocketConf @PocketConfApp “I looked through my top 10 favorite puns to see if any would work for your talk. Unfortunately, no pun in ten did.” Brandon Hays @tehviking “my friend was up all night trying to design this new API... I told her she probably just needs some REST” sudo @4_ab50b0f27bb3 “ I reading a book about gravity and I can't put it down” “I thought about cutting down on my sodium but then I was like na” Gina Woodard @thumblegena “I told my friend ruby to callback later. She didn't react well.” garvinling @GarvinLing “What do you call a cow that just gave birth? De-calf-inated I love puns!” Britany Meadows @letbritcode “I went to a weekend hackathon in the woods; it was in tents.”
 
 “make good .NET developers because they've spent years knowing how to see sharp” Ben Hyrman @benhyr
  7. Prelude II

  8. None
  9. None
  10. None
  11. Face Swap With Chris

  12. Airplane Traveling to RailsConf

  13. Losing Money In Vegas While Changing Planes

  14. None
  15. Part I: The Majestic Monolith

  16. Majestic monoliths! A whole system that addresses an entire problem.

    —The Rails Doctrine Presentation Layer Database Integration Business Logic
  17. Pros / Cons For Your Consideration

  18. Team Structure

  19. Team Structure organizations which design systems ... are constrained to

    produce designs which are copies of the communication structures of these organizations — M. Conway
  20. Development Complexity (Monolith Pros)

  21. single codebase to work in speed of jumping around the

    application easier to refactor functionality between services code gives you a view of the entire system easier to reason about (for smaller applications) simplier architecture (for smaller applications) consistency across the codebase great for small teams Development Complexity (Monolith Pros)
  22. more merge conflicts (as your team grows) codebase complexity (for

    larger applications) harder to reason about (for larger applications) Development Complexity (Monolith Cons)
  23. Face Swap w/ Statue

  24. Face Swap w/ Statue

  25. Face Swap w/ Mimi

  26. Systems Scalability

  27. Systems Scalability

  28. Systems Scalability

  29. Systems Scalability

  30. Systems Scalability

  31. Client / Server Flow

  32. Take me to website User Client Server Take me to

    website Process Request Return Response Sends Request Client Loads State Click Process Request Return Response Sends Request Client Loads State View View
  33. Mobile

  34. None
  35. None
  36. None
  37. None
  38. client code server

  39. Client Static Content Static Asset Server Web Server Router API

    Server Web Server Router Controller Serializable Model
  40. Client Static Asset Server API Server UX / UI Data

    & Business Logic
  41. None
  42. Face Swap With Rob & Nathan

  43. Part II: The Client

  44. JavaScript

  45. Transpiling

  46. Transpiling (Is Magical)

  47. Transpiling (Magic)

  48. Transpiling (Magic)

  49. JS Frameworks

  50. Angular / Angular 2 (beta)

  51. Ember

  52. React

  53. Redux React + Redux

  54. Redux Lore lodash

  55. Face Swap With Alex

  56. Face Swap With Yehuda

  57. Deployment

  58. Deployment Gulp + AWS Simple Storage Service (S3) + Note:

    Some “hacks” required to get urls to work without using hashbang URLs (for single page apps) https://example.com.com/#!/home
  59. $ git checkout -b gh-pages $ git push origin HEAD

    gh-pages Deployment Note: Some “hacks” required to get urls to work without using hashbang URLs (for single page apps) gh-pages does not currently support https for custom domains.
  60. $ npm install —global surge $ surge <project-path> surge.sh Deployment

  61. Convergence of Native & Web

  62. Tools: Cordova - “Target multiple platforms with one code base”

    Ionic 2 - “develop once, deploy everywhere.” React Native - “learn once, write anywhere.” Convergence of Native & Web
  63. Why isn’t everyone doing this? Performance (?) Convergence of Native

    & Web
  64. Convergence of Native & Web Why? Remove specialization required to

    build native apps Consistency in experience across platforms Shared components and code across platforms Performance becoming less and less an issue
  65. None
  66. JavaScript Fatigue

  67. interface churn modularity frustration JavaScript Fatigue

  68. You don’t need to live on the cutting edge. Use

    Semantic Versioning (SemVer) • MAJOR.MINOR.PATCH • MAJOR version when you make incompatible API changes, • MINOR version when you add functionality in a backwards-compatible manner, and • PATCH version when you make backwards-compatible bug fixes. Lock Dependancies (if using npm) Avoiding JavaScript Fatigue
  69. Client Summary

  70. Client Summary Client is about creating human experiences. Need tech

    to get out of the way. Some growing pains. Choices can be a good thing. Things still feel very modular, which has a cost (less opinions)
  71. Face Swap With Alex

  72. Face Swap With Justin

  73. Face Swap With Alex

  74. Face Swap With JCK

  75. Face Swap With Alex

  76. Face Swap With Justin @ Joe’s Kansas City Bar-B-Que

  77. Face Swap With Colin @ Joe’s Kansas City Bar-B-Que

  78. Part III: The Server

  79. Monolithic APIs

  80. Same pro’s of the monolith. + Clear separation of client/server

    concerns. Monolithic APIs
  81. Rails API • lighter weight rails app • logging •

    param parsing • resource routing • caching • convention over configuration • Gems (devise, JWT, jsonapi-resources, rack- cors, versionist) Monolithic APIs $ rails new <projectname> —api gh-pages
  82. Scaling A Monolithic API

  83. Microservices

  84. Microservice architecture are about scale. Microservices are an optimization technique.

    Start with the monolithic API (or as few micro services as possible) to ensure service boundaries are defined correctly. interface churn modularity frustration Microservices
  85. Potential Microservices Pitfalls

  86. Interfaces are harder to refactor Tools & Sharing code between

    services Dependancies on other microservices Latency between systems now a concern DevOps & System support becomes critical Monitoring & Debug Build and forget (more likely to build and then move on) Potential Microservices Pitfalls
  87. Scaling Your Application With Microservices

  88. Scaling With Microservices Models Defined by Bounded Contexts Bounded Contexts

    - The conditions under which a particular model is defined and applicable. - Domain Driven Design - Eric Evans
  89. Scaling With Microservices

  90. Scaling With Microservices Be of the web, not behind the

    web - Ian Robinson
  91. Scaling With Microservices

  92. Scaling With Microservices Atomic Services Consumer

  93. Scaling With Microservices Atomic Services Data Denormalization Tier Consumer

  94. Scaling With Microservices Atomic Services Composition Services Data Denormalization Tier

    Consumer
  95. Scaling Teams With Microservices

  96. None
  97. Face Swap With Twins

  98. Face Swap With Twins

  99. The Future

  100. The Future

  101. Face Swap With @searls

  102. The Future

  103. Put a dent in the universe. — David Heinemeier Hansson

  104. Thank You! Mike Groseclose @mikrofusion