[Umbrella Ticket] PATH User Database

[Olshansk]

Objective

Build the foundation for tracking users accessing the portal.

Origin Document

Postgres driver
Proposed Database Structure

Goals

• Associated a relay with a user ID
• Enable other gateways to build features associated with a specific user
• Enable downstream efforts related to billing
• Enable downstream efforts related to rate limiting
• Enable downstream efforts for user-specific features in the future (whitelisting, user agents, settings, etc...)

Deliverables

• Implementation that ties a relay to a UserId including
  • Connecting to, fetching and caching user data from a Postgres database.
  • Relating a service request to this user data via a UserApp ID (eg from .../v1/{USER_APP_ID} in the URL).
• User-specific rate limiting (dependent on [Umbrella Ticket] Rate Limiting - Capacity & Throughput Rate Limiting #10 as a parallel requirement)
• Updated tooling and documentation to startup a postgres DB alongside the gateway
• 1-2 pager w/ docs to be turned in 🦖 docs in the future

Non-goals / Non-deliverables

• Out-of-the box stripe integration or hooks
• Implementing downstream user settings (whitelisting, user agents, settings, etc...)
• Integrating with crypto payments

General deliverables

• Comments: Add/update TODOs and comments alongside the source code so it is easier to follow.
• Testing: Add new tests (unit and/or E2E) to the test suite.
• Makefile: Add new targets to the Makefile to make the new functionality easier to use.
• Documentation: Update architectural or development READMEs; use mermaid diagrams where appropriate.

---

Creator: @Olshansk
Co-Owners: @commoddity

[fredteumer]

this feels like it's being conflated from a user db vs billing db situation. The purpose of the database is to codify the business logic of the application for the purposes of user management, plan management, services, etc.

Billing, while important, inherits a small subset of this data and is combined with the metering of the application to integrate with Stripe.

[commoddity]

this feels like it's being conflated from a user db vs billing db situation. The purpose of the database is to codify the business logic of the application for the purposes of user management, plan management, services, etc.

Billing, while important, inherits a small subset of this data and is combined with the metering of the application to integrate with Stripe.

To be clear, I think the extent to which this issue needs to interact with billing is simply providing a UserApp ID we can relate to a service request to identify who sent the service request and, thus, who gets billed for it.

IMO getting to the point of having two key functionalities should be the focus of this issue:

1. Connecting to, fetching and caching user data from a Postgres database.
2. Relating a service request to this user data via a UserApp ID (eg from .../v1/{USER_APP_ID} in the URL).

This keeps the scope limited while still providing the prerequisite functionality to implement #10

@Olshansk I know we just discussed this a few mins ago but I tend to agree that adding Out-of-the box stripe integration or hooks may be getting a bit ahead of ourselves for this iteration.

[fredteumer]

The above makes more sense for the scope of this ticket. We can expand upon it to open a metering/payment rail integration with stripe as a future feature and mark other possible payments integrations as future issues.

[Olshansk]

@commoddity @fredteumer PTAL at the updated goals, deliverables and non-goals and 👍 if it looks good to you.

I'm also putting together #13 to capture the billing work in a follow-up ticket.

[commoddity]

@adshmh @Olshansk Proposal for DB driver ready for initial review: #15

[commoddity]

Draft PR for implementing Envoy Auth Plugin Proposal here:
#28