Here is a developing http server.
This server will serve data to a client & act as a "middle-man" between the requesting client and some data.
This API, and this project at large, will intend to follow the 12-Factor App methodology.
This API will be connected to a db.
The db connection will be event-driven.
- The api will start without a connected db
- The db connection instantiation will be async
A few events will be setup to interact with the db
- an event that triggers an attempt to connect to the db
- this will be run on api start as well as during re-try attempts when detected db disconnection
- an event that triggers the "knowledge" of the db connection success
- this will inform the api to "talk to" the database in the normally expected workflow
- an event that triggers the "knowledge" ofa db error (and/or disconnection)
- this will update the api to return errors to the client during unforeseen db down time
As a user I can
- Create my account with attributes
- first name
- last name
- email address
- password
- pw stored as one-way non-readable hashed vals
- Go through an account registration workflow
- Sign-up (register email address)
- validate email
- save password
- Forgot password workflow
- enter email
- click submit
- check email
- click a button in the email or get code from email
- enter code in ui for email validation
- enter new pw
- Reset pw
- enter current pw
- enter new pw
- submit
As an client with "admin" type user credentials, I can
- Get List of user accounts
- email address
- last login date
- user name
- date created
As a user I will be able to store text-blobs so that I can later view text for analysis:
- Text blobs
- "raw"?
- formatted?
As a user, I will be able to add "metadata", important attributes, to the text so that I can categorize the text with
- Orator
- Date
- tags (perhaps later on due to complexity of tag integration?!)
- more...
Incorporates a flexible logging solution.
The API is setup to be "bundled" for a tiny code footprint.
This server can be run a few different ways as a "containerized" service: one way in a more dev-friendly setup and one way in a more prod-like setup.
A dev image can be built & run as a container using the dev.Dockerfile. To build this image (with docker installed & running on your machine)
- cd into the server dir
- run
docker build -t dev-server -f dev.Dockerfile .: this will build a dev-friendly image tagged "dev-server" - run
docker run --rm -p 3000:3000 -v ${PWD}:/server qwer: this will run the image as a container This image is dev friendly with these 2 details, specifically: - uses
nodemon, which includes "hot-reloading" for faster server development
A dev image and a mongo image can both be started with a docker-compose setup.
One way to run this is to run from the command line docker-compose -f dev.docker-compose.yml up --build.
See Code Readme for more details
Some automated process goals here will be to:
- enforce unit code-coverage test threshold to be met
- enforce linting
- semantically version the api based on
- github issues
- commit messages
- semver practices
- deploy based on criteria
- merge to "staging"? deploy to a "staging" instance of the api
- merge to "main" or "master"? (figure that out) deploy to prod
- consider docker...
- bundling into a docker box &
- deploying to a registry (github registry?)
- leverage those images in "staging" and "prod" environments
- leverage webpack to minimize the code footprint for the api in staging/prod
- send messages to a slack channel
- on prod deploy
- on merge-to-dev...?
- on failed pipeline tests