Frontend 'vs' Backend Getting the Right Mix

7,371 views

Published on



Modern website architectures are typically composed of 2 parts: frontend and backend. Building out frontend and backend components requires diverse skill sets and often have competing interests when it comes to developer productivity and site performance. This talk will discuss some ways Java frameworks deal with these issues as well as benefits and tradeoffs. The talk will include combine demos with cutting edge frontend frameworks (Handlebarsjs, CoffeeScript, Less) and popular Java backends (Spring, Apache CXF).

Bio:
Bob Paulin is an independent consultant that has been developing on Java for the past 10 years. Bob is focuses on Business Enablement and Web Centric Applications. He’s presented in the past at CJUG on Apache Sling and is currently helping his clients perform modular development/design, automation for continuous delivery, and build forward leaning web applications. When not coding, Bob enjoys coaching football and spending time with his with his wife and 3 kids.

Published in: Technology
0 Comments
9 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
7,371
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
72
Comments
0
Likes
9
Embeds 0
No embeds

No notes for slide

Frontend 'vs' Backend Getting the Right Mix

  1. 1. FRONTEND 'VS' BACKEND GETTING THE RIGHT MIX Created by / /Bob Paulin @bobpaulin bob@bobpaulin.com
  2. 2. ABOUT ME Independent Consultant Business Enablement Web Centric
  3. 3. A LONG TIME AGO I CREATED "FACEBOOK" College students love seeing pictures of their friends doing stupid things at parties Photoshop can be used to make funny pictures even more funny Do not host anything on your school's web property
  4. 4. WHAT THIS TALK IS NOT Deep Dive into web frameworks THE answer on which architecture is better
  5. 5. WHAT THIS TALK IS Using Frontend and Backend frameworks together How developers work together Advantages and disadvantages of architectures Some empirical data on architecture performance
  6. 6. HOW DID WE GET HERE? Complexity Corporate Culture Developer Aptitudes
  7. 7. BACKEND DEVELOPER
  8. 8. TYPICAL BACKEND DEVELOPERS Focus on the server side Data Storage and Retrieval System Architecture Availability Does it work?
  9. 9. FRONTEND DEVELOPER
  10. 10. TYPICAL FRONTEND DEVELOPERS Client/Browser focused Information Architecture Closer to creative/design Does it look right?
  11. 11. DOES THIS MODEL ACTUALLY WORK?
  12. 12. CHALLENGES WITH FRONTEND/BACKEND TEAMS
  13. 13. COMPETING REQUIREMENTS
  14. 14. FREQUENT HANDOFFS
  15. 15. FRAMEWORKS OFTEN COUPLE FRONTEND AND BACKEND TECHNOLOGIES
  16. 16. ANOTHER WAY TO THINK ABOUT THE PROBLEM... AN AMERICAN FOOTBALL ANALOGY
  17. 17. FRONTEND DEVELOPERS = OFFENSIVE BACKS
  18. 18. FRONTEND DEVELOPERS = OFFENSIVE BACKS Score Points with Customers Work is highly visible Can be limited by poor play at other positions Often get the biggest share of blame when things go wrong and praise when things go right
  19. 19. BACKEND DEVELOPERS = OFFENSIVE LINE
  20. 20. BACKEND DEVELOPERS = OFFENSIVE LINE Enable other positions to do great work Work is not usually visible Mistakes often have a cascading effect Generally only get blamed when things go wrong. When things go right .... well things are just suppose to work all the time right?
  21. 21. OK ENOUGH ABOUT YOUR PEOPLE PROBLEMS LETS LOOK AT SOME CODE ALREADY!
  22. 22. 3 DIFFERENT APPROACHES TO THE SAME WEB SITE REQUIREMENTS - A BOOK REVIEW SITE Allow users to select keyword preferences Allow users to view and post review comments about a specific book Should use responsive design. Because, well, that's the hot new thing right?
  23. 23. A BACKEND RECIPE Spring MVC Spring Data MongoDB Apache Tomcat Apache Http Server JSP Twitter Bootstrap WRO4J Amazon Cloudfront (CDN)
  24. 24. DESIGN Cache Google Api Response for Books and Book Search Consolidate and minify CSS and JS using WRO4J Page turn between Homepage and Reviews Page can't be cached but static resources can
  25. 25. CODE Spring MVC Controller Spring Data Services WRO4J Config
  26. 26. ARCHITECTURE
  27. 27. A FRONTEND RECIPE Brunch ChaplinJS CoffeeScript Handlebars Node.js Apache CXF Spring Data MongoDB Apache Tomcat Apache Http Server Twitter Bootstrap Amazon Cloudfront (CDN)
  28. 28. DESIGN All Services are done through AJAX Apache CXF Provides Restful Services(Consumers/Producers) JAX-RS Single Page Application Behavior via Chaplin Node.js but only for Brunch Compilation All pages and frontend code cached Some Data Services Cached: Volatile vs Static
  29. 29. CODE index.html - Look Ma, only 16 lines of server side html! Chaplin Controller Chaplin Views Chaplin Models Handlebars Templates Apache CXF JAX-RS
  30. 30. INDEX.HTML <!doctype html> <!--[if IE 8]> <html class="no-js lt-ie9" lang="en"> <![endif]--> <!--[if gt IE 8]><!--> <!--<![endif]--> <head> <meta charset="utf-8"> <meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1"> <title>Frontend Home Page</title> <meta name="viewport" content="width=device-width"> <link rel="stylesheet" href="/frontend-web/stylesheets/app.css"> <script src="/frontend-web/javascripts/vendor.js"></script> <script src="/frontend-web/javascripts/app.js"></script> <script> </script> </head> <body> </body> </html> require('initialize');
  31. 31. ARCHITECTURE
  32. 32. A MIXED RECIPE FRONTEND TECH Backbone CoffeeScript Handlebars Twitter Bootstrap BACKEND TECH Spring MVC Handlebars.java WRO4J Apache CXF Spring Data MongoDB Apache Tomcat Apache Http Server Amazon Cloudfront (CDN)
  33. 33. DESIGN Some Services are done through AJAX others on Serverside Apache CXF Provides Restful Services(Consumers/Producers) JAX-RS Page turn between Homepage and Reviews Page can't be cached but static and service resources can Page actions do not require page turns Templates are shared between frontend and backend Book Searches are cached with data URIs
  34. 34. CODE Cached Controller WRO4J Backbone Views
  35. 35. ARCHITECTURE
  36. 36. TEST DESIGN Web Page Test Browser - Current Chrome Location - Virgina Click events tested locally using Chrome Developer Tools
  37. 37. TEST SCRIPT 1. Homepage View 2. Add a New Book Preference 3. Open a Review 4. Add A Comment
  38. 38. BACKEND HOMEPAGE WATERFALL
  39. 39. FRONTEND HOMEPAGE WATERFALL
  40. 40. MIXED HOMEPAGE WATERFALL
  41. 41. BACKEND REVIEW WATERFALL
  42. 42. FRONTEND REVIEW WATERFALL
  43. 43. MIXED REVIEW WATERFALL
  44. 44. DISCUSSION What does this data tell us? What does it not tell us? Which is most scalable? Variations between Browsers
  45. 45. CONCLUSIONS
  46. 46. BACKEND SUMMARY Most consistant load times Better performance with static data Less requests Full page loads for incremental changes can prevent optimal performance Data is embedded within the page so it can't be separated into different TTL Dynamic content within the JSP prevents pages from being cached. Increases traffic to the origin
  47. 47. FRONTEND SUMMARY Requests handled independently. Enables fine grain caching Eliminates page turns to refesh data model Significant caching opportunities at the edge Generates more requests Higher memory and CPU consumption on the client end
  48. 48. MIXED SUMMARY Allows the most flexibility in how information is loaded Code reuse at the template level Eliminates some page turns related to data updates Performance suffers when both page and services are volatile (non-cachable)
  49. 49. REFERENCES CODE AND PRESENTATION Frontend "vs" Backend FRONTEND BackboneJS Brunch ChaplinJS CoffeeScript Handlebars Twitter Bootstrap BACKEND Apache CXF Handlebars.java MongoDB Spring Data Spring MVC WRO4J
  50. 50. BOB PAULIN / /BOB PAULIN @BOBPAULIN BOB@BOBPAULIN.COM

×