This document discusses choosing technologies for software projects. It argues that ORMs do not scale well and promote spaghetti code because models take on too many responsibilities. Modular monoliths and microservices help address these issues by separating concerns. The author promotes Platformatic as a tool that can remove repetitive tasks while still allowing complex features by extending databases through code.

1. @matteocollina
Pareto will tell you to stop
using your ORM

2. A little bit about me
Matteo Collina, Ph.D.
Co-Founder & CTO, Platformatic
● Node.js Technical Steering Committee member
○ Triager for Node.js vulnerabilities
○ HTTP, Streams, diagnostics, …
● Board member OpenJS Foundation
● 8 years as a consultant focused on Node.js
● Software Architect
● Created Fastify and Pino
● 12 billions download/year on NPM.
Subscribe to https://nodeland.dev my week newsletter about all things Node.js.

3. Choosing a technology

4. The Pareto principle

5. The pareto principle
80% of outcomes result from 20% of all causes for any given event. 80 and 20 are empirical values.

6. Pareto in practice
80% of the effort in building a project comes from only 20% of the features

7. WE WANT TO REDUCE THE EFFORT (and
time) IT TAKES TO BUILD AND MAINTAIN A
SOFTWARE PROJECT
What technology would you choose?

8. What would you choose?
We need to pick a technology that reduces the effort for both repetitive and complex features.

9. If we can reduce the effort for
both repetitive and complex
task….

10. Object
Relational
Mapping

11. ORM promise us a
neat, well organized
codebase with the
concept of Models.
A Model represents a
row in the database
as well as all the
relations.

12. What happens to
your application
when it uses an
ORM?
It hibernates*
*pun intended

13. The problem is in the Model concept
Why ORMs are an anti-pattern
Every model has 3
responsibilities:
1. Manage persistency,
including relationships;
2. Hold the data in memory;
3. Implement business logic.

14. Model-View-Controller
The unscalable architecture: Monoliths
The MVC architecture has only
three “places” where you can
add new features:
1. Models
2. Views
3. Controllers
Soon, you will have 2000
models.

15. ORMs remove the easy part

16. ORMs deliver a nice
bowl of spaghetti
code since the 90s

17. ORMs only help with the repetitive tasks

18. Modules can help scale your code complexity
The Modular Monolith as a solution
Fastify can
help structure
your applications
in modules

19. Microservices solves the logistical complexity
Microservices as a solution
Each team
manages one
or more
microservices.

20. What would you choose?
The pragmatic choice is to choose the framework that enables us to build the most complex features.

21. The best line of code is the one I don’t have to type.

22. My backend requirements
Things are going to get tricky
1. Can run everything locally
2. Extensible via code & native database
language (e.g. SQL)
3. Have basic authorization support
4. GraphQL and REST Support
5. Apollo Federation Support
6. Deployable cloud-prem
7. Support multiple databases (MySQL,
MariaDB, SQLite, PostgreSQL)
I want a
backend that
takes no time
to build but it’s
as flexible as I
would build it
myself

23. Have the cake? Eat the cake?

24. Have the cake and eat it too!

25. Can a tool remove all repetitive tasks and go out of
the way for the most complex features?

26. Platformatic
https://platformatic.dev

27. Development process using Platformatic DB

28. Platformatic DB Architecture
1. Platformatic DB can be
extended, so you don’t need
to deploy “functions”
2. Based on Fastify plugins,
you can rely on the Node.js
and Fastify ecosystems
3. You can use the individual
components of Platformatic
DB, completely skipping our
server.

29. Claim an invite at https://platformatic.dev
Platformatic Cloud is now in private beta
@matteocollina
https://nodeland.dev