Full stackWhat stands behind these words

@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

Agenda

1. Front-end world2. Back-end world3. Reasons of bugs4. Best practices5. Stories with morality6. Summary7. QA?

Front-end. So different applications.

● Gaming● Media publishing● Internet Messaging● Data visualization● Social networks● GIS● And many many more...

Front-end evolution

1. Pre AJAX:a. LAMP: Linux + Apache + MySQL + PHP(PERL,

Python). index.php2. AJAX:

a. Multi paged: CakePHP, Django, Symfony, Zend Framework, JSP

b. Single paged: Index.html + anchors, jQuery3. Post AJAX:

a. Realtime API: Meteor.js, WebSockets, WebRTC

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

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

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

Reasons of front-end bugs

● Browser detection code● Too wide CSS selectors● Event cycle management● Event listeners not removed properly● Closures variables

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

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

Tasks

● Builds (unit testing, integration testing)● Deployment● Environment configurations● High Availability● Load balancing● Performance testing● Continuous Integration

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

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.

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

Full stack profile

1. Client side stacka. HTML5 - presentation and client side APIb. Build automation Grunt/Ant/Mavenc. Unit testingd. LESS/SASS/Styluse. AJAX, WebSockets, WebRTC

2. Server side stacka. Java, Python, PHP, Rubyb. MVC frameworkc. Databasesd. *nixe. CI

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!

Story #1

1. HTML5 game for mobile platforms2. CSS3 + Spritesheets + Lime.js + Google

Closure Toolkit3. CakePHP + MySQL + Ubuntu Linux4. XML as interchange format5. Over 20 API calls to load friends game

scores and over 5 minutes to load it all

Story #2

1. HTML5 Newspaper App for mobiles2. Backbone.js + Require.js + jQuery3. Drupal6 + Ubuntu linux + MySQL4. XML as interchange format5. XML built using strings concatenation (sic!)6. Many drupal hooks that do not know about

each other7. 5 - 10 mins to load news feeds

Story #3

1. HTML5 Multi Page Web App2. Java + Ubuntu Linux + Oracle DB3. Require.js + Backbone.js + jQuery4. All clients in GMT timezone5. Server was located in non-GMT and used local time

zone6. Clients needed to adopt server time to local time7. Day could have 22, 23 and 25 hours. Really.

Story #4

1. HTML5 Web portal for OpenStack platform2. Python + OpenStack + Ubuntu + RabbitMQ3. Angular.js + LESS + HTML54. One action invokes many (>5) ajax calls5. All calls are enqueued as long as domain is the same6. Gimme code #1, Gimme code #27. Huge latency, over 1 min to see single statistics

entry

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

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

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

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

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

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

Contacts

● pavlo.iuriichuk@globallogic.com● skype: pavlo.yuriychuck● twitter: @pavlo-yuriychuck