goldbergyoni / goldbergyoni/nodebestpractices
🎉 We (almost) have an example app - Meet practica.js
- Dominant language
- Dockerfile
- Stars
- 106k
- Forks
- 10.7k
- PR merge metrics
- No merged PRs in 30d
Description
🥳Happy announcement here🎈
### TL&DR
We are working hard on an example app that is based on this guide. It's in Alpha mode, not production-ready yet, but your constructive feedback is more than welcome. [It's called practica.js, visit here](https://github.com/practicajs/practica)
Why is this unique and maybe the preferred option for new Node.js apps? Read below 👇
________
### What
For years, we have received repeating feedback here - "Can you show an example app?"
It took a while, mostly because we wanted to nail it properly, but now we're almost ready now 🎉👇
[Meet practica.js](https://github.com/practicajs/practica) - Our Node.js best practices code generator that is built around the principles of this guide
It's currently 0.0.1@alpha.1, not ready for production, some parts are still not coded (e.g. logger is doing console.log:)), but already has 400 commits and 17 contributors. We'll be grateful to have your constructive feedback
Basically, it generates a skeleton code that shows API requests traveling through the layers including DB and testing. it's *not* a new framework but rather using the popular and great (!) Node.js frameworks like Fastify, express and probably Nest in the future
Given these great frameworks and the existence of many starters, why do we need another one 😳? Here is its unique value:
## Why
### Unique value 1 - Production ready
It's Production ready (soon). Great frameworks by definition don't handle everything. express lacks basic features like auth, logger... Even richer frameworks lack Monorepo setup, hardened .dockerfile, real-world testing template with DB, and 100+ more things that EVERYONE NEED

### Unique value 2- Simpler architecture
Simplicity as a key architectural principle. We believe that tons of unnecessary complexity finds its way to most software which becomes a strategic maintenance obstacle. Consequently, Practica minimizes abstractions, relies on JS/Node standards, is built mostly around plain function, uses TypeScript for types only, favors the simple 3-tier architecture over fancy hexagonal/clean structure to name a few examples. When you read it, everything should look highly familiar and... simple

**Why trust our design -** One of the key reason you want to consider Practica is because you appreciate our design. But why? Because of the process, not the people. Every decision is neatly documented, all the options are compared transparently, the community is involved which leads to better collaborative decisions. Here is an example of a [typical decision making](https://github.com/practicajs/practica/blob/main/docs/docs/decisions/monorepo.md) for a monorepo tooling

Contributor guide
No contributing guide indexed for this repository
Research direction
Start with the linked practica.js example app and the guide referenced by the issue. Read docs/docs/decisions/monorepo.md for the documented monorepo rationale, then review the example app's stated API, database, and testing layers. The issue requests general constructive feedback rather than defining a specific change, so completion criteria are not established.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- dockerfile, express, javascript, nodejs, typescript
- Domain
- backend, developer-experience
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100