Design patterns or Frameworks ? When you are at the decision making crossroad for choosing a framework to meet your use case, you should be thinking about design patterns and which patterns a particular framework adheres to.

1. Date: 02/03/2015
Frameworks or a Design Pattern ?
Shubhra Kar, Head of Products and Education
@shubhrakar

2. Bert
Belder
Ben
Noordhuis
Node Core
Raymond
Feng
Ritchie
Martori
LoopBack / Express Core
Sam
Roberts
Miroslav
Bajtos
Ryan
Graham Plus 15 other full-time open source
developers working on Node.js core,
modules and tools.
Contributing to over 100 open source
modules.
Supporting banks, retail, IoT companies,
startups and internet companies on
Node.js

3. Patterns are not created, they evolve
Right Now
— Someone on Stage

4. Pattern 1: DIY / Construction Blocks
✤ Un-opinionated
✤ Middleware

5. Router using express 4.0

6. Router using restify

7. Strengths andWeaknesses
Pros
Great starting point
Low learning curve
Nearly a standard for Node.js web
middleware
Fully customizable
Targeted at browser, hence templating
and rendering OOB
Cons
All endpoints need to be created
manually
Developers may end up creating their
own non-optimized libraries
Every end point needs to be tested
Refactoring is painful, update
everything everywhere
No standards or prescription, DIY
Pros
Very stable and actively developed.
Automatic DTrace support for all
handlers on enabled platforms
Built in throttling
SPDY support
Borrows from express but without
unnecessary templating/rendering
Strict API with full control over HTTP
interactions
Visibility into latency and app
characteristics
Cons
All endpoints need to be created
manually
Developers may end up creating their
own non-optimized libraries
Every end point needs to be tested
Refactoring is painful, update
everything everywhere
No standards or prescription, DIY
Less documentation
Express Restify

8. Pattern 2: Configuration
✤ HAPI
✤ Express and Restify (maybe…)

9. Router using hapi

10. Router using hapi

11. Strengths andWeaknesses
Pros
Supported by Walmart labs. Less known
but getting momentum
Very granular control over request
handling
Detailed API reference with support for
document generation
Significantly more functionality for
building web servers
Pseudo prescriptive with configuration
centric approach
Caching, Authentication and input
validation available
Plugin based architecture for scaling
Cons
Good construction blocks but left to your
own devices to figure out design patterns
Binds you to specific modules and tool chains
(catbox, joi, tv, boom, good, travelogue, yar)
All endpoints need to be created
manually
Developers may end up creating their
own non-optimized libraries
Every end point needs to be tested
Refactoring is painful, update everything
everywhere

12. Pattern 3: Convention - ORM
✤ Model driven development
✤ Any Datasource
✤ Automatic Rest API Generation

13. Router using LoopBack
DELETE /items/{id}
GET /items
GET /items/count
GET /items/findOne
GET /items/{id}
GET /items/{id}/exists
POST /items
PUT /items
PUT /items/{id}

14. Swagger using LoopBack

15. Router using Sails

16. Strengths andWeaknesses
Pros
Very quick RESTful API development
Convention over configuration (extends express)
Built in models ready to use (ORM)
RPC support, Web and Mobile SDKs
Data Connectors
Fully configurable when needed
Extensive documentation
Commercial support and full time team working on project
(Loopback)
Mobile Services (Push, Geo, Storage, Sync, Offline, File,
Device, User) - Loopback
Authentication, validation and Authorization
Cons
Higher learning curve
Opinionated

17. Pattern 4: Isomorphic JS & Full Stack
✤ Share Server Model with Client / Remoting
✤ Omni-Channel (Mobile, Web, IoT)

20. Pattern 5: MicroServices
✤ Decomposition
✤ Containment
✤ Flexibility
✤ Hyperscale

21. Relational Database Clustered Database Security Gateway Cloud
Laptop ( not requested but useful)
Connections
Tablet Phone IoT SDK API SERVER
Quick Example of Use
App Server
Relational Database Clustered Database Security Gateway C
Laptop ( not requested but useful)
Connections
Tablet Phone IoT SDK A
Quick Exam
App Server
Auth
Routing
Rate-Limit
Proxy
Mediation
Orchestration
Analytics
✤ RECOMPOSITION isn’t cutting it

22. ✤ The new need is DE-COMPOSITION
SaaS Mobile IoTWeb
App Server API Server
HTML JSON
{JSON}
{JSON}
{JSON}<SOAP/XML>
<TABLE>

23. DesignTime

24. RunTime