How to develop NodeJS apps effectively? I will tell you all details and share his personal experience on the whole process: from the very start and up to the production stage. You will also learn more about Docker, SDLC and 12 Factor App. Save the date!

1. OdessaJS - 2020
Effective NodeJS
Development
Viktor Turskyi

2. Viktor Turskyi
● CEO and principal software
architect at WebbyLab
● Open source developer
● More than 15 years of experience
● Delivered more than 60 projects
of different scale
● Did projects for 5 companies
from Fortune 500 list
2/86

3. Simple mental model for:
● Solution architecture
● Application architecture
(https://www.youtube.com/watch?v=TjvIEgBCxZo)
● Development process
● Deployment process
How to make development more
effective?
3/86

4. Solved most of the standard edge cases in starter-kit:
● Folders structure
● Configs
● Sessions
● Error handling
● Transactions
● Dependencies management
(including 3rd party services)
● Tests etc
How to make development more
effective?
4/86

5. 5/86

6. Complex is easy. Simple is hard.

7. ● Define standard technology stack
● Define standard architecture
● Define the most effective software development
approaches
● Define the most effective deployment strategies
● Define the most effective way of production support
● Internal trainings
Engineering productivity group
7/86

8. ● NodeJS
● ReactJS
● React Native
● MySQL/Postgres
● S3 like object storage
● Docker
Standard technology stack
8/86

9. Example Project

10. Solution architecture overview

11. Monolith or Microservices by default?

12. "If you cannot build a monolith what makes you
think that you can build Distributed Microservices"
Simon Brown

13. ● High operational complexity (increases costs)
● Versions compatibility issues (harder to track all dependencies in
consistent state, reduces iterations speed)
● Extremely hard to support transactions (risks of inconsistencies)
● Distribution issues (harder to program)
● Traceability issues (harder to debug)
● Technology diversity (mixing languages increases support costs,
standardization issues, hiring issues etc)
● You need more experienced team (hiring issues)
Microservices drawbacks
13/86

14. Key microservices issue

15. What is the best architectural
decision?

16. “The job of architect is not to make decision, the job of
the architect is to defer decisions as long as possible”
“Good architecture maximizes number
of decisions not made”
Robert Martin
https://www.youtube.com/watch?v=o_TH-Y78tt4

17. ● But when your components are services with remote
communications, then refactoring is much harder than with
in-process libraries.
● Another issue is If the components do not compose cleanly,
then all you are doing is shifting complexity from inside a
component to the connections between components. Not
just does this just move complexity around, it moves it to a
place that's less explicit and harder to control.
https://martinfowler.com/bliki/MonolithFirst.html
Martin Fowler:
17/86

18. So, we start with monolith
in 90% of cases

19. What is Monolith?

20. Usually it looks like
20/86

21. 9/19
21/86

22. 9/19
21/86

23. Application architecture

24. Which web-framework to choose?

25. ● Express
● Koa
● Sails
● Nest
● Feathers
● Derby
● Kraken
● Hapi etc
NodeJs frameworks:
25/86

26. It doesn’t matter!

27. Your application architecture
should not depend on a web
framework

28. ● NodeJs: Express
● PHP: Slim3
● Perl : Mojolicious
Web frameworks we use
28/86

29. “We use MVC why do we need
another architecture?”

30. MVC (from wikipedia)
30/86

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

32. “The M in MVC: Why Models are Misunderstood
and Unappreciated” Pádraic Brady
http://blog.astrumfutura.com/2008/12/the-m-in-mvc-w
hy-models-are-misunderstood-and-unappreciated/
Fat Stupid Ugly Controllers
32/86

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

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

35. An object model of the domain that incorporates
both behavior and data. (M. Fowler)
Works well for medium and large applications.
Domain model
35/86

36. Organizes business logic by procedures where
each procedure handles a single request from the
presentation (M. Fowler).
Works well for small projects.
Transaction script
36/86

38. Controllers
Services
Domain model
Data access
layer
Dispatcher

41. How do we cook the service layer?

42. Separate service class (implemented
as command) for each endpoint
42/86

43. Real code (with meta
programming)
43/86

44. ● 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
The way of thinking about
Controllers
44/86

45. NodeJs example of a Service class

46. Base class (the simplest version)
46/86

47. 47/86

48. 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.
“run” method
48/86

49. ● 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)
The way of thinking about
Services
49/86

50. 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
50/86

51. ● 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
Unified approach to validation
51/86

52. 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.
Be aware of “Anemic domain
model” antipattern
52/86

53. ORM Sequelize

54. ● 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)
The way of thinking about
Domain Model
54/86

55. ● ES6 syntax
● Transactions
● Configuration
Sequelize
55/86

56. Sequelize ES6
(do not follow docs strictly)

57. 57/86

58. 58/86

59. Initialize once
59/86

60. Sequelize transactions

61. Continuation-local storage works like
thread-local storage in threaded programming,
but is based on chains of Node-style callbacks
instead of threads.
https://www.npmjs.com/package/cls-hooked
Transactions with CLS
(continuation local storage)
61/86

62. Transactions with CLS
(continuation local storage)
62/86

63. Sequelize config

64. Do not do this: violates
12 factors apps principles
64/86

65. Chatbot example in Perl6
https://github.com/koorchik/codegolf-telegram-bot/

66. Configs

67. How to work with configs
according to 12 factors?

68. “confme”
https://www.npmjs.com/package/confme

69. 69/86

70. How to use config?
70/86

71. How to use config data for
Sequelize?
71/86

72. How to read config in migrations?
sequelize --config lib/config.js db:migrate --env db
72/86

73. How do we use “12 factors”
configs with next.js?
73/86

74. How do we use “12 factors”
configs with SPA?
Hack for Parcel (with webpack you just have “script” tag)
74/86

75. public/config.js and lib/config.js
74/86

76. “confme” demo

77. Docker

78. ● How do new developers setup working environment?
● How to work with S3 (we do not use localstack)?
● How to work with emails?
● How to run the whole platform?
● How to do migrations?
● How to work with cron?
● Do I need pm2?
● How to build frontend in docker?
Questions
78/86

79. Demo

80. ● Minio (vs localstack)
● Mailhog
● Adminer
Services that we use
80/86

81. User sessions

82. ● Classical sessions or JWT?
● Which type of transport to use (Cookie, Query
params, Custom headers)?
● How to refresh JWT?
● CSRF protection?
● CORS issues?
● How to implement “Force logout”?
● Sensitive information
Questions to solve
82/86

83. ● MonolithFirst by Martin Fowler
● Microservice Trade-Offs by Martin Fowler
● PresentationDomainDataLayering by Martin Fowler
● The Principles of Clean Architecture by Uncle Bob Martin
● The Clean Architecture by Robert Martin
● Microservice Architecture at Medium
● https://12factor.net/
Useful links
83/86

84. ● Based on ideas of Clean Architecture
● Works with small and large projects
● Follows 12 factor app approach
● Modern JS (including ES6 for Sequelize)
● Supports both REST API and GraphQL
● Follows security best practices.
● Docker support
● Covered with tests
● Battle tested
● Built on top of express.js
● Users managment
NodeJs Starter App
84/86

85. https://github.com/WebbyLab/webbylab-
starter-app-for-nodejs

86. Telegram: @JABASCRIPT
85/86

87. Email
viktor@webbylab.com
Website
https://webbylab.com
@koorchik
@koorchik
My contacts
86/86