Design principles¶
UserHarbor should remain simple, predictable, and easy to integrate.
1. Core should only do what is necessary¶
The main library is responsible for basic user account operations:
- registration
- email verification
- login
- session management
- logout
- password reset
- password change
- user deletion
- simple role-based access control
Unusual business-specific cases should be implemented outside the library.
UserHarbor does not try to solve every identity-related problem.
The following are outside the scope of the core library:
- OAuth
- OpenID Connect
- social login
- 2FA/MFA
- ACL
- organizations and teams
- ownership and resource policies
- policy engines
- admin panels
- ready-made HTTP endpoints
- ready-made HTML views
- integrations with specific frameworks
Such features may be created as separate libraries or integrations, but they should not complicate the core project.
UserHarbor should not become an application framework.
2. Framework-agnostic before framework integrations¶
The main library should not depend on FastAPI, Django, Flask, Litestar, or any other framework.
Framework integrations should be created as separate libraries.
3. UserStore and EmailSender are dependencies¶
UserHarbor does not assume where users are stored.
UserHarbor does not assume how email messages are sent.
These responsibilities belong to adapters compatible with the UserStore and
EmailSender interfaces.
4. Adapters should live outside the core¶
Integrations with databases, ORMs, email services, queues, frameworks, and providers should be developed as separate packages.
5. Stability is more important than feature count¶
After the public API becomes stable, further core development should focus mainly on:
- improving security
- improving reliability
- improving performance
- maintaining compatibility
New features should be added carefully.
6. Simple things should remain simple¶
The library should be easy to use in small projects, while still being possible to extend in larger applications.