📦 deps(thirdparty): update snapshots
This commit is contained in:
+98
@@ -0,0 +1,98 @@
|
||||
# Technology Selection
|
||||
|
||||
## Database Selection
|
||||
|
||||
Decision factors:
|
||||
|
||||
1. **Data model fit**
|
||||
- Relational (structured, ACID, complex queries) → PostgreSQL, MySQL
|
||||
- Document (flexible schema, nested data) → MongoDB, DynamoDB
|
||||
- Graph (relationship-heavy) → Neo4j, DGraph
|
||||
- Time-series (metrics, events) → TimescaleDB, InfluxDB
|
||||
- Key-value (simple lookups, cache) → Redis, DynamoDB
|
||||
|
||||
2. **Consistency requirements**
|
||||
- Strong consistency → PostgreSQL, CockroachDB
|
||||
- Eventual consistency acceptable → DynamoDB, Cassandra
|
||||
- Hybrid needs → MongoDB, Cosmos DB
|
||||
|
||||
3. **Scale characteristics**
|
||||
- Read-heavy → read replicas, caching
|
||||
- Write-heavy → sharding, write-optimized DB
|
||||
- Both → consider CQRS pattern
|
||||
|
||||
4. **Operational complexity**
|
||||
- Managed service available? Use it unless special needs
|
||||
- Self-hosted required? Factor operational overhead
|
||||
- Multi-region? Consider distributed databases
|
||||
|
||||
Decision matrix:
|
||||
|
||||
```
|
||||
ACID + complex queries + proven? → PostgreSQL
|
||||
Flexibility + horizontal scaling + managed? → DynamoDB
|
||||
Document model + rich queries + open source? → MongoDB
|
||||
High write throughput + wide column? → Cassandra
|
||||
Caching + pub/sub + simple data? → Redis
|
||||
```
|
||||
|
||||
## Framework Selection
|
||||
|
||||
### Backend (TypeScript/JavaScript)
|
||||
|
||||
| Framework | Best for |
|
||||
|-----------|----------|
|
||||
| Hono | New projects, serverless, edge |
|
||||
| Express | Teams with Express experience |
|
||||
| Fastify | Raw speed matters |
|
||||
| NestJS | Large teams, complex domains |
|
||||
|
||||
### Backend (Rust)
|
||||
|
||||
| Framework | Best for |
|
||||
|-----------|----------|
|
||||
| Axum | New projects, type-safe routing |
|
||||
| Actix-web | Raw performance critical |
|
||||
| Rocket | Rapid development |
|
||||
|
||||
Decision criteria:
|
||||
- Team expertise and learning curve
|
||||
- Performance requirements (most apps don't need Rust speed)
|
||||
- Ecosystem and library availability
|
||||
- Type safety and developer experience
|
||||
- Deployment target (serverless, containers, bare metal)
|
||||
|
||||
### Frontend
|
||||
|
||||
| Stack | Best for |
|
||||
|-------|----------|
|
||||
| React + TanStack Router | Complex state, large ecosystem |
|
||||
| Solid | Performance-critical UIs |
|
||||
| Svelte | Small teams, simple apps |
|
||||
| Next.js | SSR/SSG needs, full-stack React |
|
||||
|
||||
## Infrastructure
|
||||
|
||||
### Serverless (Vercel, Cloudflare Workers, AWS Lambda)
|
||||
|
||||
- **Pros**: Zero ops, auto-scaling, pay-per-use
|
||||
- **Cons**: Cold starts, vendor lock-in, harder debugging
|
||||
- **Best for**: Low-traffic apps, edge functions, prototypes
|
||||
|
||||
### Container orchestration (Kubernetes, ECS)
|
||||
|
||||
- **Pros**: Portability, fine control, proven at scale
|
||||
- **Cons**: Operational complexity, learning curve
|
||||
- **Best for**: Medium-large apps, multi-service systems
|
||||
|
||||
### Platform-as-a-Service (Heroku, Render, Railway)
|
||||
|
||||
- **Pros**: Simple deploys, managed infrastructure
|
||||
- **Cons**: Higher cost, less control, scaling limits
|
||||
- **Best for**: Startups, MVPs, small teams
|
||||
|
||||
### Bare metal / VMs
|
||||
|
||||
- **Pros**: Full control, cost-effective at scale
|
||||
- **Cons**: High operational burden
|
||||
- **Best for**: Special requirements, very large scale
|
||||
Reference in New Issue
Block a user