5. Is Node.js ready for Enterprise?
Yes, sure
Node.js is ready
But JavaScript developers...
6. Is Node.js ready for Enterprise?
Yes, sure
Node.js is ready
But JavaScript developers are not
7. New features
● Multithreading for calculations and scale
(added in v10, stable in v12)
● WASI, Node-API 8, V8 v9 for Node.js v16, npm 7
● API: diagnostic API, perf_hooks, timer promises,
AbortController, vm, v8, scrypt, Web crypto api,
async_hooks, AsyncLocalStorage, etc.
● QUIC or HTTP/3 especially for mobile and 5G
8. Monkey job
Everything repeats every time we start a project
● Let’s discuss scaling, we expect highload
● We need microservices, REST and ORM
● People, vision and setup processes
● Application architecture and structure
● Select tools, libraries, frameworks
● Code conventions, repository maintenance
9. Node.js challenges
● Enterprise requirements: Reliability,
Maintainability, High Availability, Security,
Isolation, Compatibility
● Community culture: meetups, conferences,
fundamental SC knowledge, consensus
● Reputation and trust: education, certification,
success stories
15. How to think about you code
It’s glue and business-logic code
Semantically and syntactically flexible
Very expressive (you can create DSL)
Simple for maintenance and changes
Simple and readable for everyone
Works everywhere
Easy to integrate
16. Engineering culture
● Architecture: DDD and clean code, layered
architecture, domain in the middle
● Principles and patterns: GRASP, SOLID, GoF,
IoC, DI, coupling и cohesion, Law of Demeter
● Project structure: framework-agnostic
● Techniques: error handling, asynchronous and
parallel programming, metaprogramming...
17. Important aspects
● Application is the place for applied code
● Declarative code is better than imperative
● State: reliability, performance, interactivity
● Configuration and infrastructure in the code
● Getting rid of dependencies
● We use layered architecture
18. Related to Node.js
● Context isolation and v8 sandboxes
● Don’t block event-loop
● Avoiding race conditions and leaks
● Avoid reference pollution and mixins
● Don’t use middlewares
● Implement graceful shutdown
● Limit concurrency (async queue or semaphore)
19. Important for Enterprise
● Business needs quick prototyping (TTM)
● We need security audit and certifications,
so get rid of dependencies
● Enterprise prefers low-code
● Modeling visualisation
(BPMN, ERD, state diagram, process flow)
20. Layered (onion) Architecture
Domain
model
Domain services
Application services
Presentation
Infrastructure
Persistence
Postgres
Redis
External API
Logger
Configs
Scheduler
Health mon
Validation
Cryptography
Sessions
App firewall
AAA
Web UI
Mobile UI
API gateway
21. Middleware: big ball of mud
models
controllers
logger
configs
AAA
validation
cryptography
sessions
routing
middlewares
db
configs
rendering
24. High coupling
● References are passed to other parts of the
application (examples: req, res, socket, person,
payment, logger, session, scheduler...)
● Passed objects mutations due to mixins will
breaks our expectations
● Remaining references are visible from contexts
so memory leaks and we need restarts
26. What we get
● Framework-agnostic application
● Transport-agnostic communications
● No race conditions in asynchronous code
● No memory leaks and resource leaks
● Errors are handled properly
● Code reuse, no code duplication
● A few and reliable dependencies
27. What we get
● DI (dependency-injection)
● Automatic routing (directory based)
● Context isolation
● Parse cookie without middlewares
● Sessions without middlewares
● Authentication without middlewares
● Concurrency control with semaphores
41. Powered by schemas
● Contracts and data-structures validation
● Autogenerated .d.ts typings
● SQL DDL (database structure)
● Automated-migrations and structure versioning
● Scaffolding for DB access
● UI (web and mobile)
● Declarative data projections and aggregations
42. GRASP
General responsibility assignment software
patterns
“Applying UML and Patterns: An Introduction to
Object-Oriented Analysis and Design and Iterative
Development” // Craig Larman
43. GRASP
General responsibility assignment software
patterns
• Low Coupling • High Cohesion
• Information Expert • Creator
• Controller • Polymorphism
• Pure Fabrication • Indirection
• Protected Variations
44. GRASP: Information Expert
Problem: What is a basic principle by which to
assign responsibilities to objects?
Solution: Assign responsibility to the class that has
the information needed to fulfill it.
Benefits: Low Coupling, High Cohesion, Code
simplicity, Better encapsulation, Code reuse.
45. GRASP: Cohesion & Coupling
Cohesion (связность)
inside class, module,
component. etc.
Coupling (зацепление)
between classes
and other components
46. GRASP: Creator
Problem: Who creates object instance?
(who holds reference or destroy it)
Solution: composition containers (who aggregate
instances), who works with it and closely use it,
who have initializing information for instances.
Benefits: Low Coupling
Examples: constructor, factory, object pool.
47. GRASP: Controller
Problem: Who should be responsible for handling
an input system event?
Solution: Controller - communication entry point,
all system operations; delegates BL.
Benefits: protection, handle concurrency,
asynchronity, and parallel programming issues.
Examples: command, facade, layer isolation.
48. GRASP: Polymorphism
Polymorphism - alternative behaviour based on
type (see SOLID: LSP, OCP).
Problem: how to handle behavioral alternatives
based on type (or class)?
Solution: assign responsibility to the classes,
select one of type/class instead of if-statements,
access by interface or abstract class.
49. GRASP: Indirection
Indirection - intermediate object will decrease
coupling between two abstractions.
Benefits: Low Coupling, Code reuse.
Examples: GoF Mediator pattern (посредник),
MVC, С - controller.
50. GRASP: Pure fabrication
Pure fabrication - an abstraction that does not
exist in the subject area. It often reduces the
overlapping of domain classes.
Examples: Socket, DB Query, EventEmitter,
Promise, Asynchronous queue.
51. GRASP: Protected variations
Problem: How to design objects, subsystems, and
systems so that the variations or instability in
these elements does not have an undesirable
impact on other elements?
Solution: Identify points of predicted variation or
instability; assign responsibilities to create a stable
interface around them.
52. Summarize the approach
● Architecture: DDD and clean code, layered
architecture, domain in the middle
● Principles and patterns: GRASP, SOLID, GoF,
IoC, DI, coupling и cohesion, Law of Demeter
● Project structure: framework-agnostic
● Techniques: error handling, asynchronous and
parallel programming, metaprogramming...
53. LoD (Law of Demeter)
● Module should “knows” less about others
(low coupling), access through interfaces (ISP)
● All components communicates only with
neighbors and talks explicitly
● A class method works with its arguments,
other methods and properties of the instance
and its first-level structural parts
54. What we get
● Code reuse, no boilerplate
● A few and reliable dependencies
(pg 803 kb, ws 118 kb = 921 kb)
● System code 6 kb, applied code: 837 b
● Metarhia (5 June): 286 kb (JavaScript: 155 kb)
● Characteristics: Portability, Reliability, Security,
Isolation, Maintainability, High Availability