MEAN Stack: Good application development is all about making educated choices - part 1

There are many great frameworks allowing developers to start writing web applications almost effortlessly, without the need of long hours of studying its API. Angular as framework of MEAN stack choice is a good example of it.

Incredible ease of use, however creates some risks, such as lack of consistent standard across the market and that very often causes development drawbacks. Lack of code consistency almost always makes project level learning curve much steeper.

On the other hand coding by convention provides simplicity and coding freedom and perhaps that is why it is very often practice of choice.

As there is quite a lot of buzz around the Web about the MEAN stack, it might be difficult for beginner or even intermediate developer to decide on which convention to follow.

Aim of this talk is to highlight widely adopted community conventions as well as provide some useful insights to why those choices have been made. It will help you to decide which convention is best for building your application.

During the course of this talk you will learn more about:
PART 1
different types of Angular service recipes and why and when to use them
pros and cons of effective ways to organise your code

PART 2
introduction to AMD and why to love it
AMD with require.js
setting up build process with gulp.js

Transcript

1. GOOD APPLICATION
 DEVELOPMENT IS ALL ABOUT MAKING EDUCATED CHOICE Getting most of the Angular (part 1) by @rusticode
2. WHAT’S AHEAD? 1. Angular services service definition, 
 angular services and specialised objets, service recipes and when to use them different ways to organise application code with few tips on how to pick the right one for your web-app quick overview and pros and cons of using / not using it 2. Code organisation 3. Introduction to AMD
3. SERVICES
4. A service is a self-contained unit of functionality, such as 
 retrieving an online bank statement. Services can be combined by other software applications
 to provide the complete functionality of a large software application. http://en.wikipedia.org/wiki/Service-oriented_architecture WHAT IS SERVICE?
5. A services are self-contained units of functionality, such as 
 retrieving an online bank statement. Services can be combined by other software applications
 to provide the complete functionality of a large software application. http://en.wikipedia.org/wiki/Service-oriented_architecture SERVICES ARE…
6. INJECTING SERVICES WITH $INJECTOR & SERVICE PROVIDER When service is requested,
 $injector service finds correct service 
 provider, instantiate it and calls its 
 $get service factory function 
 to get the instance of the service. WHAAAT??! WHAAAT??!
7. INJECTING SERVICES WITH $INJECTOR & SERVICE PROVIDER When service is requested, $injector service finds correct service provider, instantiate it and calls its
 $get() service factory function to get the instance of the service. maa… maa… ?
8. TERMINOLOGY •Service providers are constructor functions. When instantiated they must contain a property called $get, which holds the service factory function. •Service factories are functions created by a service provider and used to create service objects •Service is a singleton object created by a service factory. •$injector service is used to retrieve object instances as defined by provider, instantiate types, invoke methods, and load modules. READY…. ?
9. SERVICE RECIPES https://docs.angularjs.org/guide/providers https://docs.angularjs.org/api/auto/service/$provide Services API defined by the developer writing the service Specialised objects Angular framework specific API •value •factory •service •provider •constant •controllers •directives •filters •animations Helper methods for registering components with $injector Note: Those methods are exposed on angular.Module, ex: angular.module(“testModule”).factory()
10. 1. Value recipe •Value service does what it says on the box •Returns primitive type value ( string, number, boolean) •Returns composite type value ( object, array ) •Makes value available for dependency injection Example 1.1 angular.module("meanApp", [])
 .value("user", {
 token: "SUPER-SECRET-TOKEN",
 name: "MEAN User"
 }); When to use
11. 2. Factory recipe Example 2.1 angular.module("meanApp", [])
 .factory("user", function() {
 var userName = "Mean User";
 return {
 token: "SUPER-SECRET-TOKEN",
 name: userName
 }
 
 }); •Most common, and used in majority of situations •If you like modular pattern •Explicit object construction allows “private” properties •Returns object with public API methods When to use
12. Example 2.2 function User(userId) {
 this.token = userId;
 this.name = "Mean User";
 }
 
 angular.module("meanApp", [])
 .value("userId", 123) 
 .factory("user", function(userId) {
 return new User(userId)
 }); 2. Factory recipe •Instantiates external object libraries
 
 …there is simpler way though! When to use
13. 3. Service recipe •Instantiating external libraries •When you like using keyword this over modular pattern •Access to entire object with its this.properties Example 3.1 function User(userId) {
 this.token = userId;
 this.name = "Mean User";
 }
 
 angular.module("meanApp", [])
 .value("userId", 123)
 .service("user", ["userId", User]) When to use
14. 4. Provider Recipe Example 4.1a : User constructor method function User(userId, uriPrefix) {
 
 this.token = userId;
 this.name = "Mean User";
 
 this.getURI = function() {
 return uriPrefix 
 + this.name.replace(/[^a-z0-9]+/ig,'-');
 };
 
 };
15. 4. Provider Recipe Example 4.1b : User Service with User Provider var meanApp = angular.module("meanApp", []);
 
 meanApp.provider('user', function UserProvider() {
 var uriPrefix = "";
 
 this.setUriPrefix = function(uri) {
 uriPrefix = uri;
 };
 
 this.$get = ["userId", function userFactory(userId) {
 return new User(userId, uriPrefix);
 }];
 }); meanApp.config(function(userProvider) {
 userProvider.setUriPrefix("user-");
 });
16. 4. Provider Recipe •Available in configuration phase • Configurable reusability •Instantiating external libraries When to use You should use the Provider recipe only when you want to expose an API for application-wide configuration that must be made before the application starts. This is usually interesting only for reusable services whose behaviour might need to vary slightly between applications. From Angular documentation
17. 5. Constant Recipe Example 5.1 (…)
 
 myApp.constant('uriPrefix', ‘user-');
 
 (…)
 
 meanApp.config(function(userProvider, uriPrefix) {
 userProvider.setUriPrefix(uriPrefix);
 }); •Available in run phase ( same as value recipe ) •Available in configuration phase ( same as provider recipe) When to use
18. SERVICE COMPARISON Factory Service Value Constant Provider can have dependencies yes yes no no yes uses type friendly injection no yes yes* yes* no object available in config phase no no no yes yes** can create functions/primitives yes no yes yes yes * at the cost of eager initialization by using new operator directly ** the service object is not available during the config phase, but the provider instance is https://docs.angularjs.org/guide/providers
19. ORGANISING CODE
20. COMMON PATTERNS all in one file 
 used to demo simple code snippet 
 (100-200 ? lines of code) simple functional grouping
 file per functional group functional grouping 
 folder per functional group feature based grouping
 HMVC, folder per group
21. single application file app/ app.css app.js tests/ unit/ app.js e2e/ scenarios.js karma.conf.js protractor-conf.js index.html All in one file
22. All code resides in one file Tiny footprint Easiest to write Easiest to maintain (assuming small size of the project) No external dependencies Pros Cons Not usable for projects bigger than 100 -200 lines of code All in one file
23. Simple functional grouping file per functional group app/ app.css app.js app-controllers.js app-directives.js app-services.js tests/ unit/ app-directives_test.js app-controllers_test.js e2e scenarios.js karma.conf.js protractor-conf.js
24. Good for very small projects( few services ) Small footprint ( only few files ) Easy to write and manage ( few script dependencies ) Pros Cons Not practical for bigger apps Easy to maintain assuming project doesn't grow No Drag&Drop support Simple functional grouping folder per functional group
25. Simple functional grouping folder per functional group app/ app.css app.js config-const.js controllers/ app-controller-01.js app-controller-02.js directives/ app-directive-01.js services/ app-service-01.js app-service-02.js app-service-03.js app-service-04.js controllers/ tests/ unit/ controllers/ app-controller-01.js app-controller-02.js directives/ app-directive-01.js services/ app-service-01.js app-service-02.js app-service-03.js app-service-04.js e2e karma.conf.js protractor-conf.js
26. Simple functional grouping Good for medium projects Easy to write and manage at the beginning Pros Cons Not practical for big apps Managing code base is easy only at the beginning No Drag&Drop support folder per functional group
27. Feature based HMV(W), folder per group app/ app.css app.js app-controller.js app-controller_test.js components/ adminlogin/ adminlogin.css adminlogin.js adminlogin-directive.js adminlogin-directive_test.js userlogin/ …( more files here ) https://docs.google.com/document/d/1XXMvReO8-Awi1EZXAXS4PzDzdNvV6pGcuaF4Q9821Es/pub
28. Feature based Recommended by google ( common standard ) Good for most types of projects Perfect for concern separation Drag&Drop ready Modules are self contained Adjacent tests Easy to refactoring Easily expandable Clean structure …and many more Pros HMV(W), folder per group
29. Cons Might seem too “enterprise” for some projects Might require little bit of additional time to set up Usually requires additional file per each module It should be supported by build scripts or AMD Feature based HMV(W), folder per group
30. HOW ABOUT MY CODE? all in one file simple functional grouping grouping by functionality grouping by feature ???
31. Organising code by feature really rocks when it comes to building and maintaing complex web-apps Grouping by feature rocks
32. CODE ORGANISATION 
 VS. 
 SIZE OF THE PROJECT all in one file project size number of developers simple functional grouping functional grouping feature based grouping
33. AMD updated: 24th of July 2014 AMD has been moved to the separate slide deck ! Keep an eye on @rusticode on twitter and http://www.meetup.com/MEAN-Stack/
34. Build great apps Make educated choices
35. THANK YOU @rusticode rusticode.com