112 lines
3.2 KiB
Markdown
112 lines
3.2 KiB
Markdown
- FastAPI
|
||
- because:
|
||
- more flexible deployment environments
|
||
- less magic to the code
|
||
- higher throughput
|
||
|
||
+ logging to Datadog
|
||
+ tracing with Sentry
|
||
- lint python code with pylint, autopep8
|
||
+ check python types with mypy
|
||
+ code should be well type-hinted
|
||
- specify a stub unittest using the pytest library
|
||
+ Oracle DB access with the "oracledb" python module
|
||
+ a health-check endpoint
|
||
- rate limiting
|
||
- an inital POST /api/v1/resource - stub this for now
|
||
- ORM (need to pick one)
|
||
- sqlalchemy
|
||
|
||
- audit log of all DB changes (POST/PUT/PATCH/DELETE), use middleware
|
||
- do we need to log access (GET requests)?
|
||
- Where to store audit records?
|
||
- oracle
|
||
- dynamo?
|
||
- Pro:
|
||
- fast, won't block or load oracle
|
||
- cheap
|
||
- Cons:
|
||
- limited indexing
|
||
- not blessed by SBA (yet)
|
||
- have to work with Allocore
|
||
- LIST endpoints
|
||
- support limited filtering
|
||
- based on:
|
||
- user
|
||
- indexed columns
|
||
- pagination
|
||
|
||
|
||
- Authentication
|
||
- actors are:
|
||
- API server (fastapi server)
|
||
- client (app server)
|
||
- user (browser)
|
||
- request process
|
||
- User connect to client to perform action (browser call)
|
||
- Client requests changes to API server (s2s call)
|
||
|
||
- "Browser call" authentication
|
||
- client authenticates user via ULP/Okta
|
||
- browser holds session cookie
|
||
- "s2s" call
|
||
- client holds PSK (api-key) for that specific service (prepay, LX, Origination, etc.)
|
||
- client passes JWT which contains:
|
||
- PSK
|
||
- OIDC token
|
||
- until Okta exists, just trust the client properly verifies with ULP
|
||
- or forward session id and check with ULP
|
||
- request_context (defined by the endpoint):
|
||
- user_id?
|
||
- location_id?
|
||
|
||
|
||
non-architecture matters:
|
||
- package management with uv
|
||
- dockerize
|
||
- ci/cd github actions + codebuild
|
||
- pre-commit
|
||
- lint
|
||
- unittest
|
||
- mypy?
|
||
- only skilled devs work on API server
|
||
- PR should cross-teams (2 reviewers)
|
||
|
||
|
||
Resources that we need in the near-term:
|
||
- POST Payoff
|
||
- GET Location
|
||
- list locations user can access
|
||
- GET Users
|
||
- lookup by id
|
||
- search by location: /api/v1/user/?location-id=
|
||
- GET countries
|
||
- GET holidays
|
||
- GET franchises
|
||
- GET naics-code
|
||
|
||
|
||
|
||
|
||
|
||
|
||
|
||
Open questions:
|
||
- query param OR convention (python-filterparams?) GraphQL?
|
||
-
|
||
- Unified models for reads and writes
|
||
- API endpoint must match the structure of the models
|
||
|
||
|
||
Current issues:
|
||
- Dev environment
|
||
- add static checking
|
||
- autopep8
|
||
- isort
|
||
- mypy
|
||
- Deploy environment
|
||
- add datadog logging
|
||
- add sentry error tracking
|
||
- authentication core
|
||
- add unittest infrastructure
|