Our Battle Against Technical Debt
Behind Great Product #3: Build Your Code for the Future
Frandy & Herwidodo, February, 24th 2017
Who are we?
• Frandy Jaya • Binusian• Join blibli in 2012• Java & JavaScript
Developer
• Herwidodo• Budi Luhur, Computer
Science• Join blibli in 2015• Front End Developer– Focus on Performance
and technology
Agenda
• What is Technical Debt and why it is sometime sensible to take it
• Our journey to tackle technical debt and modernize our technology stack
• Peek into our future Front End technology
Blibli.com UI pre launch 2010
Blibli.com UI Circa 2012
Build Your Code for the Future
Technical Debt
Technical Debt
Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem.
In this metaphor, doing things the quick and dirty way sets us
up with a technical debt, which is similar to a financial debt.
Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and
dirty design choice.
https://martinfowler.com/bliki/TechnicalDebt.html
Taking Technical Debt is Sensible
• Time to market trump good design when you have unproven business
• Until it is hold you back, crippling your productivity
Taking Technical Debt is Sensible
• Paying technical debt is hard, it needs support from very top level
• Rewrite / Refactor based on proven technology
Architectural Debt
Blibli.com SOA architecture circa 2013
Store Front
Back officeMerchant
ESB
Blibli.com UI Circa 2013
• Technology– Dojo – JSP– JQuery– Websphere Commerce Server
• Technical Debt– Huge javascript file– Slow backend
• Temporary remedies– YSlow to evaluate performance– YUI Compressor – Implement SOLR to help
backend performance issue
Blibli.com UI rewrite 2014
Technology
• AngularJS 1.2• Responsive Design• Solr 4• Java 7, Spring and Tomcat• Redis• Google Pagespeed and Varnish
Combination of Server Side Rendering and SPA
• Checkout page is SPA
• Product Detail page is half SPA
• Catalog, search and others are server side rendering for SEO puprpose
Content Problem
• Problem – Content is scattered in Code– No database to hold content data– Multichannel UI is not possible
• Solution– In House CMS system– Save content in database– Layout in database
Improved Architecture
Store FrontEngine
Back officeMerchant
ESB
Store Front UI
SOLR
CMS
Internet
Responsive vs Adaptive
• Our responsive problem– Desktop and mobile web UI share almost nothing,
all element are different– Mobile web was really slow
• Responsive done right– Start with mobile web design– Make it responsive to desktop web– Success example• salestockindonesia.com
Mobile Web UI revamp to adaptive 2015
• One controller 2 completely sparate UI• CMS support 2 layout : Desktop and Mobile
Web• SASS and Grunt introduction on mobile web UI• SPA page still using responsive• Mobile Web performance increase
dramatically
Break Monolithic to Microservices 2015
Store Front UI
SOLR
CMS
Internet
20+ Microservicesto handle transactions
Travel UI
Digital Product UI
10+ Microservicesto handle travel
10+ Microservicesto handle Digital Product
Front End Performance 2016
• Server side load < 1s• Front end average load time ~ 12s• What was the problem
– Blocked javascript execution– DOM size ~ 700kb– Page size ~ 3MB– Single big CSS file block rendering
• Solution– Differ javascript– Decrease DOM size using ajax and lazy load– Lazy load all image, start download when image in viewpoint– Break CSS, inline CSS for layout and rendering– Put third party JS at the and of DOM
• Result : frond end average load time ~4s - 6s
Front End Performance Result
Code Quality : Block Element Modifire (BEM)
• Maintainable• Easy Tracking• Modular• Flexible• Support partial load• Fit with component based modern framework
ex : React, Vue, Polymer.
Brand new Travel UI is using BEM and SPA
Code Quality : Design System and Blistrap
Front-End Tooling and Development Cycle
• It is crazy time where front end developer need compiler and build tools !!– SASS– Grunt : Concate & minify CSS + JS
• Existing UI application is basically Java Project– Use Maven to build– Use tomcat to run application– Takes ~ 10 minutes from fresh build to application
ready
A Peek to Our Front End Technology in Future
• Separate backend and front end completely– Single Page Application– Backend as API
• Front End developer friendly tools– VueJS – SASS– Webpack– NodeJS to simulate route and response of Backend API
• Automated testing and quality gate– VueJS unit testing– CodeceptJS for acceptance test
• Reactive backend using Spring and RxJava to connect to many microservices using nonblocking IO
We Are Hiring!!THANK YOU