Full stack development
1 like1,228 views
This document outlines the agenda for a presentation on full stack development. It begins with introductions and background on the presenter's experience. The presentation will cover the evolution of front-end development, typical front-end and back-end tasks, reasons for bugs on each side, and best practices for full stack development. It will also provide stories of issues that can arise when front-end and back-end teams do not communicate well. The goal is to demonstrate why understanding both sides is important for full stack developers.
Full stack development
- 1. Full stack What stands behind these words
- 2. @Me ● Front-end lead developer ● Front-end since 2008 ● Full stack since 2013 ● Now: Node.js ● Before: Angular.js, Backbone.js, Chaplin, Google Closure Toolkit, Flex, Actionscript
- 3. Agenda 1. Front-end world 2. Back-end world 3. Reasons of bugs 4. Best practices 5. Stories with morality 6. Summary 7. QA?
- 4. Front-end. So different applications. ● Gaming ● Media publishing ● Internet Messaging ● Data visualization ● Social networks ● GIS ● And many many more...
- 5. Front-end evolution 1. Pre AJAX: a. LAMP: Linux + Apache + MySQL + PHP(PERL, Python). index.php 2. AJAX: a. Multi paged: CakePHP, Django, Symfony, Zend Framework, JSP b. Single paged: Index.html + anchors, jQuery 3. Post AJAX: a. Realtime API: Meteor.js, WebSockets, WebRTC
- 6. Typical tasks ● Unit testing, end-to-end testing of modules and components ● Minifaction and merge of javascript modules ● Compilation of LESS/SASS/Stylus to CSS ● Revisioning of files ● Assets preparation ● Generation of manifesto file
- 7. Front-end ● Client-side ○ Interoperability ■ Cross-browser - same feature + different implementations, polyfills ■ Mobile devices - fast css + slow javascript + slow internet connection ● Presentation ○ HTML5 - a lot of buzz-words, but only few jedis know about them
- 8. Front-end ● Modularity ○ Pre-AMD ○ AMD: Require.js, DojoToolkit ○ ES6 modules ● Core ○ Prototype.js, DojoToolkit, Google Closure Toolkit ○ jQuery them all ○ MVP, MVVP: Backbone.js, Knockout.js, Angular.js, Ext.js, Ember.js
- 9. Reasons of front-end bugs ● Browser detection code ● Too wide CSS selectors ● Event cycle management ● Event listeners not removed properly ● Closures variables
- 10. Summary ● One language many environments ● Heterogenous clients (OS + Browser + Platform) ● Significant amount of events are invoked by user: mouse, keyboard, touch-screen ● Mostly visual representation
- 11. Back-end ● Platforms ○ *nix: Linux, BSD, Solaris, AIX, HP-UX ○ MS Windows ● Databases ○ Relational: Oracle, MySQL, PostgreSQL, MS SQL ○ Non-relational: MongoDB, OrientDB, CouchDB, Cassandra, BerkeleyDB ● Languages ○ Perl, PHP, Python, Erlang ○ Java, Scala, Groovy ○ Ruby, Ruby on Rails ○ Node.js, CoffeeScript
- 12. Tasks ● Builds (unit testing, integration testing) ● Deployment ● Environment configurations ● High Availability ● Load balancing ● Performance testing ● Continuous Integration
- 13. Reasons of back-end bugs ● Configuration ○ Not applied ○ Not loaded ○ Points to wrong place ● Action sequence flow ● Asynchronicity issues ● Parameters validation ● Integration with third-party API’s or other services ● Trying to apply coding pattern that does not work as expected ● Memory management issues
- 14. Back-end summary ● Mostly homogenous environment ● Price of API changes ● Most events are emitted by OS/Services/Network/Databases ● Predictability - you are driving environment ● User does not see the back-end explicitly. He even does not know that it exists.
- 15. Kill em’ all ● One paltform could not fit all tasks: ○ Many data sources, fast handling - Node.js ○ Universal scripting platform - Python ○ Hipster platform -Ruby on Rails ○ Long-term tasks performance - Java, Scala ○ Narrow fast tasks - C/C++ ● One interchange format is not applicable for all use cases ○ JSON - Data ○ HTML - Pages ○ Markdown - documentation ○ XML - RPC, SOAP, Structured text ○ YAML - Configuration files, descriptions
- 16. Full stack profile 1. Client side stack a. HTML5 - presentation and client side API b. Build automation Grunt/Ant/Maven c. Unit testing d. LESS/SASS/Stylus e. AJAX, WebSockets, WebRTC 2. Server side stack a. Java, Python, PHP, Ruby b. MVC framework c. Databases d. *nix e. CI
- 17. Stories: Four Weddings and One Funeral ● What could happen if developers do not understand each other ● What should be avoided ● Where to point ● What is going on when: oh crap it does not work!
- 18. Story #1 1. HTML5 game for mobile platforms 2. CSS3 + Spritesheets + Lime.js + Google Closure Toolkit 3. CakePHP + MySQL + Ubuntu Linux 4. XML as interchange format 5. Over 20 API calls to load friends game scores and over 5 minutes to load it all
- 19. Story #2 1. HTML5 Newspaper App for mobiles 2. Backbone.js + Require.js + jQuery 3. Drupal6 + Ubuntu linux + MySQL 4. XML as interchange format 5. XML built using strings concatenation (sic!) 6. Many drupal hooks that do not know about each other 7. 5 - 10 mins to load news feeds
- 20. Story #3 1. HTML5 Multi Page Web App 2. Java + Ubuntu Linux + Oracle DB 3. Require.js + Backbone.js + jQuery 4. All clients in GMT timezone 5. Server was located in non-GMT and used local time zone 6. Clients needed to adopt server time to local time 7. Day could have 22, 23 and 25 hours. Really.
- 21. Story #4 1. HTML5 Web portal for OpenStack platform 2. Python + OpenStack + Ubuntu + RabbitMQ 3. Angular.js + LESS + HTML5 4. One action invokes many (>5) ajax calls 5. All calls are enqueued as long as domain is the same 6. Gimme code #1, Gimme code #2 7. Huge latency, over 1 min to see single statistics entry
- 22. Moral 1. One single UI element could involve a lot of back-end interactions 2. Applying front-end approaches to back-end and vice versa is a bad idea 3. Quick and dirty in a long term period leads to just dirty 4. Laziness on one side leads to overtime on another side
- 23. Best practices ● RAML ● When you have over 3-5 calls per single action - think about middleware ● Tools should be chosen when you have analysed requirements and workaround ● No silver bullet and ‘Не все йогурты одинаково полезны’ ● Be ready for production from the very beginning ● Be ready for changes and do not rely on library/framework. Library could be replaced with another one if it implements the same pattern
- 24. Best practices ● Definition of done for back-end work ○ RAML or documentation about HTTP request/response format ○ Unit tests ○ Deployable package deb, rpm whatever ○ VM where it could be deployed Jenkins job is even better ○ Notification to all team
- 25. Best practices ● Definition of done for front-end work ○ Proper config for web server/requirements for back-end ○ Unit tests, cover these cases: negative, positive, invalid ○ Behavior ■ Right for correct user data. ■ Expected for incorrect user data. ■ Predictable for network failures. 200 OK is not the only response ○ Look and feel ■ Check your target browsers and devices. Safari !== iOS safari !== Chrome ○ Load time is reasonable and not only from localhost;) ○ Packaged into deb/rpm
- 26. Best practices ● Definition of bugfix is done ○ Jira issue with description about bug ○ Code fixed and reviewed ○ Unit and automation test added to cover the case that bug is fixed ○ Code merged into master branch ○ Deployable package is available
- 27. Resume, or why to choose full-stack? 1. Being full stack developer makes you polyglot. You can negotiate with front-end and back-end devs and dev-ops and QAs 2. Being full stack developer gives you better understanding of product lifecycle 3. You will know the junction points of your app
- 28. Contacts ● pavlo.iuriichuk@globallogic.com ● skype: pavlo.yuriychuck ● twitter: @pavlo-yuriychuck