Skip to content

TalaikisInc/users-cubed-api-next

Repository files navigation

Talaikis Ltd.

Users Cubed

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.

Features

  • 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)

API Clients

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.

Technologies

Install

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

Deploy

# Create S3 bucket:
node init/
# Edit .env.production
# Then:
npm run build:proto
npm run deploy

Test

# 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

Previous versions

Frontend

Security considerations

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.

Possible improvements / TODO

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

Licence

GPL v3