This document discusses software system architecture for Node.js applications. It begins by classifying common uses of Node.js, such as for local applications, servers, clients, and hardware control. It then discusses where architecture is important, noting that complexity, reliability, and variability require an architecture. The document outlines some Node.js architectural problems, such as old thinking from other languages and mixing of abstraction levels. It also discusses what architecture entails, such as dividing a system, naming components, and defining connections between them. Key aspects of Node.js like asynchrony, state, and scalability are examined. The document advocates for proper separation and binding of layers in an architecture. It concludes that monolithic and microservice architectures

1. Software
System
Architecture
for Node.js
Timur Shemsedinov
Research Institute of System Technologies

2. Local applications and console utilities
• Task runers and build systems
• Scripting, CLI, testing, documentation generation
Servers
• API and backends for SPA (AJAX/JSON, RPC, REST)
• Event delivery (for chats, games & interactive apps)
• Covering gaps in other applications
Clients
• Crawlers, data mining, testing scripts
• GUI applications (nw.js, node-webkit)
Hardware
• Control systems and production automation
#1 Classification of Node.js use

3. #2 Where Architecture begins?
Complexity
• The system doesn't fit in the head
• Long development
• Large teams
• Reuse abstract code
Reliability
• Confidence for owners
• Load scalability
• Team scalability
Variability
• Live systems are changes constantly

4. #3 Node.js and Architecture
JavaScript
node.js
io.js
Frontend developers hordes encroach invades server-side
S
B
Architectors
Conceptualists Corporate
Bullshit

5. JavaScript
node.js
io.js
Choosing the right allies
S
B
Architectors
Conceptualists Corporate
Bullshit
#3 Node.js and Architecture

6. #4 Node.js Architectural Problems
Old-style thinking inherited from:
• Languages and servers of short process life
• Frontend (web and window GUI)
• Heavy legacy of OOP
Abstraction Problems
• The applied and system code is mixed
• Abstract layers principle ис not satisfied
(from lower to higher layer)
• Inconsistency (different levels of abstraction are
mixed in a single layer)
• Attempts to separate logic and data
(impossible in Von Neumann architecture)

7. #5 Misconceptions about Node.js
Common architectural principles
A common architectural practices for Node.js
has not formed yet but (the worst) it is believed that
they have already formed
It seems that all out of the box...
...but pure node.js is very low-level tool
A set of incompatible:
technologies, ideas, principles and concepts
in one application
NIH (not invented here)
Good and bad aspects of NIH

8. #6 What is not Architecture?
• Middleware
• Routers
• Single entry point...
• Facade, singleton
• Mixin, closure
• Factory, decorator
• Class and object
• Prototype, DI etc.
• MVC, MVP, MVVM
• ORM, CRUD, Key-value
• Pull/Push, Pub/Sub
• REST, RPC и т. д.
• Clouds, SaaS, PaaS...
Code structure patterns}
OOP patterns
}GUI and DB patterns
}Communication patterns
}Deployment patterns}

9. #7 What is Architecture?
• Division
• naming
• and binding

10. #8 What is Architecture?
Architectural task
• Divide and give names, build connections
• Combine subsystems to system
Concepts and Tools Selection
• Paradigms, standards, models
• Technologies, frameworks, patterns
• Module interaction types
• Topology
• Protocols and data formats
System Integration
• Planning internal interfaces before development
• Define external interfaces and links

11. Asynchrony
• Lazy operations
• Maximizing memory usage
• No I/O is faster even then asyncronous I/O
State (statefull vs stateless)
• Long-living processes can afford this...
• Stateless gives nothing nowadays
• Application can't contain just pure functions
• Interactivity or large state requires stateful
Scalability
• IP and cookie sticky
• Interprocess communication
#9 Node.js Features

12. #10 Minimal client-server A.
Client
Server
DBMS
interface
process
request
response
Client
Server
DBMS
browser

13. #11 Separation and Binding
Client
Server
DBMS
browser
Client
Server
DBMS
browser
stubs and marshalling
binding
e.g. ORM
e.g. RPC

14. #12 Introspection and Binding
Dynamic binding

15. #13 Wrong Layer Separation
Client
Server
DBMS
Interface
Logic
Data
Logic
Data
Interface

16. #14 Right Layer Separation
Client
Server
DBMS
Interface
DataLogic
Interface
DataLogic
Interface
DataLogic

17. You can't opose them:
«The system distributed better
is the better centralized one»
Monolithic is not bad, bad is when we have strong coupling
between modules and loose coupling inside module.
General rules, restrictions, agreements and standards
make microservices one monolithic but the lack of
consistency leads to the fact that the system is not a
system at all, it falls into parts, it is not stable, not
operating acording to one goal as an organisms should do.
#15 Microservices vs Monolithic

18. Software System
Architecture
for Node.js
Timur Shemsedinov
Research Institute of System Technologies
Thank you
Your questions please