Challenge Overview
Welcome to “Poseidon LPC Register Microservice Challenge”. In this challenge, we would like to continue building the LPC Payment Backend API.
PROJECT BACKGROUND
The project objective is to build an SDK for the Loyalty Payment Card (LPC) for our client. This SDK will be used by LPC’s clients to build the LPC mobile app.
So the SDK will provide all required functionalities from authentication to payment processing, reward management, etc.
FRAMEWORK
- Node.js 12+
- NestJS
- DynamoDB
REQUIREMENTS
- Add the Registration (4 endpoints) microservice with the endpoints defined in the API Design documents:
- Database must be DynamoDB
- Tests are in scope
- Don't make changes to any the existing microservices
- We are building a multi-tenant application so we need to have data separation using TenantId as hash key. See this for reference https://aws.amazon.com/pt/blogs/apn/multi-tenant-storage-with-amazon-dynamodb/
- Data for one tenant should never be visible to another tenant
- Some clarifications on the JSON model:
- LoyaltyPointId will be entered by another microservice
- IsAdmin will be set manually. Default is false
- EvCustomerId will be set by another microservice (customer microservice)
- DeviceId is the mobile device id that will be used for push notifications
- The TenantId will come from Header. So keep the existing check found in the code
- LPCAccountNo, TenantId and all other IDs will be UUIDs, with the exception of EvCustomerId and ClientCustomerNo
- In LPCCustomer, Email must be unique. Please use any mechanism necessary to enforce it
- The application is a NestJS monorepo. New microservices should be created as new apps. Any common code should be placed in the common library.
- Do not delete configuration files in existing code base without authorization in the forum
- You will have to update the Dockerfile-dev and docker-compose files to allow running the application
- Postman files should be updated to allow review of the application
- Update the CI file to run the tests for all microservices
- Unit tests and E2E tests are in scope
- Unit tests requirements:
- Should not depend on environment, external data, or other unit tests (All external services like Cognito, DB and SOAP API should continue to be mocked during)
- Should cover all the paths of the code, assert edge cases, and not have side effects
- 90% of coverage in each category. We expect that all controllers, services will have 100%
- Test a single small unit of work, and assert the results of the code
- Well-factored and run fast and efficiently
- E2E test (integration) requirements:
- Should not depend on environment, external data (All external services like Cognito, DB and SOAP API should continue to be mocked during)
- Should cover success and failure cases (400, 401, 403, 404, etc)
- E2E tests should use the mock database calls, mock Cognito and SOAP api
- If unit testing is doing good coverage of service, E2E can stub the service call altogether
Final Submission Guidelines
- Updated source code and tests
- Updated postman file
- Updated README file