Recommended
More Related Content
Recently uploaded
Recently uploaded (20)
Featured
Featured (20)
Confoo
- 1. To a Single Page Web App… and Back Again Nick Simmons Confoo Montreal 2015
- 2. ABOUT ME
- 3. STAR WARS IN ASIA
- 6. SHOPIFY ADMIN EVOLUTION Admin Classic: + ERB + Admin 2: Admin Next: ...
- 7. SHOPIFY - MAY 2013 + =
- 8. BUT... “Batman is hard!” - said everyone.
- 9. LEARNING BATMAN Superhero Newb Time Read Admin code Read Batman docs Back to Admin code Ask for help Read Batman code
- 10. HACK DAYS - JUNE 2013 “Let’s use Batman for our project!” “Where do I start?” “HELP!” “F**k this, I’m using Rails”
- 11. HARSH REALITY Complexity does not scale well.
- 12. NEW FEATURES - JUL TO NOV 2013 “Where should I put this code?” “I’m a frontend dev, client has all the state that I need.” “Let’s do it client side!”
- 13. THE RISE OF MOBILE APPS JSON API BUSINESS LOGIC BUSINESS LOGIC
- 14. CHOOSING THE RIGHT PATH Doing something because it’s possible doesn’t make it the right choice.
- 15. BATMAN DEEP DIVE - DEC 2013 “The Admin is looking a little janky.”
- 18. THE COST OF BATMAN
- 19. ADMIN REBOOT
- 20. WHAT IS ADMIN-NEXT? Turbograft Twine+ + https://github.com/Shopify/twinehttps://github.com/Shopify/turbograft
- 25. LESSONS LEARNED If you only remember these 4 points from my talk, that’s cool with me.
- 26. WHEN CHOOSING YOUR TECH Focus on what your needs are right now.
- 27. WHEN CHOOSING YOUR TECH Consider your team’s strengths.
- 28. WHEN CHOOSING YOUR TECH A simple approach scales better than a complex one.
- 29. WHEN VALIDATING YOUR TECH Vet your choice by building the most complicated part first.
- 30. How are we doing? ADMIN-NEXT + 6 MONTHS
- 31. Thanks!
Editor's Notes
- Nick Simmons from Shopify. Dev lead for Admin team. This talk is about my experience building the Shopify Admin.
- Montreal is my city. I was not born here, but my father was. Studied at Concordia and worked here for many years. Habs are my team.
- - Worked for LucasArts in Singapore. - Backend developer for online games. - Interest in JS MVC and single page web app began. - Disney bought Lucas, not interested in games. - That was the end of Lucas, and my time in Singapore.
- - Moved back to Canada. - Been at Shopify for almost 2 years. - Joined the Admin team.
- - I joined the Admin team. - Interface for shop owners. - Large web app: lots of pages, lots of forms, lots of data.
- - Classic: RoR app, view templates, jQuery sprinkled around. - Project began to convert Admin into single page app. - Decision to build their own framework. - Batman + Admin2 was the end result of this. Released July 2013. - 6 months later we decided to to move away from Batman. - Spent the next 8 months building AdminNext.
- - Batman was in polish stage. - Admin 2 was wrapping up, shipping soon. - Everyone was pretty excited about our JS MVC app. - No more full page reloads on page transitions. - All of our HTML endpoints were replaced by JSON API. - Server doesn’t care about UI any more. - Now Admin is just another API client!
- - Loved JS MVC and single page web app concept. - Batman really hard to learn. - At first I thought it was just me.
- - Read Admin code: So much going on, hard to figure out how everything ties together. - Read Batman docs: Gives a decent overview, but not enough simple examples to explain patterns. - Back to Admin code: Discovery of undocumented Batman features. - Ask for help: Not enough Batman experts to help the rapidly growing team. - Read Batman code: Time consuming effort to wrap your head around how everything works.
- - A lot of people wanted to try out Batman for their own projects - Went through same struggles as I did
- - Batman was a big framework with a lot of moving parts under the hood. - Intuition alone was not enough to grasp Batman. - A lack of documentation with solid examples made it really hard for people to jump in. - Many concepts and patterns spread through tribal knowledge. - Experts and tribal knowledge does not scale well.
- - Most of Admin team new to Rails. - Spend most of our time in client: Coffeescript. - Batman opens door for more client side business logic. - Admin team’s comfort zone, so we put more code into client.
- - POS also in development. - They are iOS developers, and most comfortable in their environment. - Same problems solved again. - Duplicated, complex business rules that should have been part of API. - Many bugs result from subtle differences between our client logic.
- We were relying on what the framework offered us too much instead of questioning whether it was really the best choice. We did not reflect on our decisions at key points in time. When additional clients became a reality we should have considered moving more logic back to the server. Another great historical example: SOAP
- - Page loads were visibly slow to finish rendering. - Expectation was page loads would be fast, but were seeing opposite.
- - This example shows how order show page should load vs. how it loads it batman. - Notice section towards the bottom fills in gradually after page load has completed? - Due to how our binding system works.
- - A lot of bindings on this page! - But when do any of these bindings get updated? - All require roundtrip to server, updated based on server response. - This works, but is not giving us that much. - Turns out, most of our Admin pages are like this.
- - Every time you visit Admin, Batman and Admin2 (with all html templates for all files) must be downloaded. - Caching does help, but deploy so often that cache is busted several times a day. - On slower connections it makes experience less than ideal. - Is upfront cost worth benefits? - Add increased memory footprint due to additional client side state.
- - Decision was made to prototype some alternative solutions to Batman. - Keep what worked, throw away what didn’t.
- - For most part, it’s just Rails. Most of our product devs are very familiar with it. - Allows us to specify which nodes in DOM we want to replace. Avoids full page reloads! - We still use API endpoints, but now they return HTML for Admin. Server does most of the rendering logic. - Let server do the work (we’re good at scaling server!) - Our binding system is currently 500 lines of javascript.
- - Admin has been running 100% on AdminNext tech for almost 6 months. - Everyone is doing Admin work now - Admin team scope has completely changed. - People are able to jump in and figure things out quickly. - Client side logic has been reduced to UI details. - Vast majority of bindings have been converted to ERB. - Even after building some of our most complicated views, amount of code added is very small. - Ongoing challenge of keeping our approach simple while supporting new problems that are not currently supported. - Overall very satisfied with our decision.