Talk at KharkivJs 2017, Viktor Turskyi. Why talk about the architecture? 1) 99% of NodeJs examples on Internet are “hello world” examples 2) A lot of misunderstandings around architectural patterns

1. The working architecture of
NodeJs applications
Viktor Turskyi
CTO at WebbyLab Kyiv, Ukraine

2. About me
● CTO at WebbyLab
● Open Source developer
(Perl, JavaScript)
● 13 years in Software
development
● Successfully delivered more
than 60 projects

3. Why to talk about the architecture?
99% of examples in Internet - “hello world” with express/sails etc.
A lot of misunderstandings around architectural patterns

4. MVC (from wikipedia)

5. Where to place this code? Model or Controller?

6. Fat Stupid Ugly Controllers
“The M in MVC: Why Models are Misunderstood and Unappreciated” Pádraic
Brady
http://blog.astrumfutura.com/2008/12/the-m-in-mvc-why-models-are-misunderstoo
d-and-unappreciated/

7. Is Model (MVC) and Domain Model the same?

8. Model (from MVC)/Domain Logic
● Domain model
● Transaction script
● Table module
● Service layer

9. Controllers
Services
Domain model
Data access
layer
Dispatcher
Layers

10. The way of thinking about Controllers
● Extremely thin layer
● Protects underneath layers from everything related to HTTP
● If you change JSON to XML (or even CLI), only controllers should be rewritten

11. The way of thinking about Domain Model
● Belongs to Model layer of MVC
● The core part of your application
● You have almost all of your business logic here (not only database access)!!!
● Knows nothing about service layer and upper layers
● Responsible for data storing and data integrity
● Fine grained API (not suited for remote invocation)

12. The way of thinking about Services
● Belongs to Model layer of MVC
● Contains application logic
● Does not trust any incoming params
● You should keep thin if possible
● Knows nothing about controllers/transport/UI.
● Use cases based API
● Knows about context (what user asks for data)
● Knows when and how to notify user (emails etc)
● Does coordination and security
● Coarse grained API (well suited for remote invocation)

13. ● Web framework independent layer of domain logic
● Learn once, write everywhere
● Well structured
● Works with large and small projects
● Hard to find existing framework which does the the same work.
Why own architecture?

14. Where do we use this architecture?
● Perl projects (Mojolicious web framework)
● PHP projects (Slim web framework)
● NodeJs (Express web framework)

15. Core patterns in the architecture
Application level (Martin Fowler):
● MVC
● Service layer
● Domain model
Class level (GoF):
● Template method
● Command

16. How do we cook the service layer?

17. Rule 1: Separate service class for each endpoint

18. Real code (with meta programming)

19. NodeJs example of a Service class

21. Base class (the simplest version)

22. “run” method
Template method in base class
Guarantees that all procedures are kept:
● Data was validated
● “execute” will be called only after validation
● “execute” will receive only clean data
● Checks permissions before calling “execute”
● Throws exception in case of validation errors.
Can do extra work like caching validator objects, etc.

23. Perl example of a Service class

26. Rule 2: There is no excuse for not using Promises or
await/async today
● Error handling - one of the most powerful promise features. You can structure
your error processing in a much better way with promises.
● You will never see “uncaughtException”
● You will have manageable code

27. Rule 3: Unified approach to validation
● DO NOT TRUST ANY USER INPUT! NEVER!!!
● Declarative validation
● Exclude all fields that do not have validation rules described
● Returns understandable error codes (neither error messages nor numeric
codes)
● It should be clear for the service user what is wrong with his data

28. We use LIVR for the validation
It supports:
● JavaScript
● Perl
● PHP
● Erlang
● Python
● Ruby
Details are here - http://livr-spec.org/

29. Rule 4: Never return objects directly
Whitelist every object
property:
1. You know what you
return (that no
internal/secret data there)
2. Your API is stable

30. It should be clear where any code should be! Otherwise you do not architecture.
One of the risks, than you can end up with an “Anemic domain model”
(https://www.martinfowler.com/bliki/AnemicDomainModel.html)
If you have a large project, this can be a reason of project failure as you will
implicitly switch to “transaction script” approach which is not well suited for large
applications.
Rule 5: Be aware of “Anemic domain model”
antipattern

31. Full example: User registration

32. Controllers
Services
Domain model
Data access
layer
Dispatcher
Layers

33. User registration: router/dispatcher

34. Routes (Controllers)

35. Service

37. User model

38. Action model

39. Where can I play with a real code?
We will open source our NodeJs boilerplate and release
several modules to npm soon.
Follow me on Twitter to be notified about it:
http://twitter.com/koorchik
https://twitter.com/webbylab

40. Viktor Turskyi (koorchik)
viktor@webbylab.com
https://twitter.com/koorchik https://twitter.com/webbylab
https://github.com/koorchik https://github.com/webbylab
http://webbylab.com