This is the 4th generation user management/ CMS system for rapid project starts.
System is easily expandable with actions
and uses only one route /
, making development for both frontend and backend parts fast and easy.
- User signin/ signout/ signup/ reset password/ confirm, delete account
- Minimal role system
- Minimal referral system
- E-commerce (in progress)
- Blog (in progress)
- Contact us service
- Upload service
Tech features:
- API key protected
- One route (with O(1) routing)
- Protocol buffers for requests and responses
- Schema validation
- Ability to easily change database type
- Fully internationalized (just add translations to
app/lib/translations/locales
)
All requests should have following headers inside encoded body*:
- X-API-Key
- Action
User's requests (edit, sign out, profile edit, etc.) should have additional token*:
- Authorization
Bearer ...
The request body schemas are in app/lib/schemas/requests
- Headers should be object in the body, e.g.
{ body: { bodyField: 'a' }, headers: { .... }}
, so not only body can be encoded, but also client side custom headers (e.g.Action
).
** Version 2.0 accepts only flat bodies and only string values, making all, but body.proto
files in schemas/requests
obsolete, they are for body fields reference only.
- AWS Lambda via serverless framework
- AWS S3 (as a database) via AWS SDK
- Protocol Buffers (backend - frontend communication)
- Node.js
- Social signup/ signin via Auth0
- Yup for schema validation
npm install -g serverless
npm i
Note, some libraries should be built for Linux environment. On Windows 10 Linux bash they can be rebuilt using: npm i --force
# Create S3 bucket:
node init/
# Edit .env.production
# Then:
npm run build:proto
npm run deploy
# Local tests:
npm run test
# npm run offline
# Live logs:
serverless invoke -f users-cubed-api-next -l
serverless logs -f users-cubed-api-next -t -s production -e production
- Users Cubed Next Frontend - SSR frontend for the API
You should secure store for your secret environment variables. This is not implemented here, but should be in critical applications. Keys should be encrypted at rest, in transit with least of privilege.
Primary:
- Finish modules API (1) when creating user -> query for schema (2) finish admin actions
- Test email / password / phone change
- Update existing profile when sign in with social
- Refer. contact, upload, if user[0] is admin tests
- Blog API
- Shop API
Other:
- HTML email templates
- move to SQS for notifications
- Phone confirm
- Cleanup for old data (not confirmed users, tokens) in S3
- Shop categories
Nice to have:
- Complex schemas
- Get users by role
- Lambda per handler, monitoring, alarms
GPL v3