Epic Feature: Campaign Control Panel

[DietBepis1]

Campaign Control Panel Overview 🎛️

Amplify has some growing pains. One of the biggest obstacles to user adoption is the time it takes to onboard new campaigns. This feature should greatly alleviate that pain and allow anyone with administration access to manage campaigns for each deployment of the app.

Oh CRUD

Yep, the solution is our most beloved programming pattern: CRUD. We need a user interface and some endpoints to talk to. In terms of work, that means:

• A new data model 💾
• New endpoints for managing campaigns 🔚
• Front-end work 🖌️
• S E C U R I T Y 🔒
• Some really revamped testing 🧪

Some Nuts and Bolts

This discussion will be the main way point for people to learn about this feature overview until it is finished and documented. We'll use this project to divvy up work and track our progress. People are encouraged to work on issues that they're interested in. If more than one person wants to work on a single issue, they may each create their own branch.

Architecture

The control panel will have a pretty straightforward flow, as described in this diagram:

A user will receive an authorization token upon login that lets him or her interact with new v1 campaign endpoints. We will begin versioning our endpoints with this feature to allow for some more flexible implementations.

New Data Model - Admin

Amplify currently has no concept of a privileged user (or any user for that matter). We will have to create a new Admin model, which I have noted in this issue.

New Endpoints

All the endpoints will be basic CRUD endpoints. The working list is something like:
Admin issue

• GET /v1/admins (gets admin entries)

• POST /v1/admins (creates one or more admin entries)

• PUT /v1/admins/:id (updates an admin, useful for password change, etc.)

• DELETE /v1/admins/:id (deletes an admin entry)

• GET /v1/campaigns (get all campaigns)

• GET /v1/campaigns/:id (get a single campaign)

• POST /v1/campaigns (create one or more campaigns)

• PUT /v1/campaigns/:id (updates a campaign)

• DELETE /v1/campaigns/:id (deletes a campaign)

We should have further discussion around bulk creation and deletion.

Authentication

Auth issues: #617, #618
We don't want any random person (or bot) to be able to hit some of these new endpoints and change our campaigns or authorized users -- that would inject chaos into our app! We will build this feature using a classic session-based authentication method, meaning that a user inputs their credentials and the server creates a session and stores it somewhere (postgres for our purposes), returning a token for the user to send along with API calls. We will use a middleware called Passport.js to help implement this because Passport will give us some flexibility implementing more robust API authorization in the future.

More details to be added soon.