The following dependencies are expected to be installed:
MacOS users are recommended to use Homebrew, a package manager that simplifies the installation of software on MacOS and Linux systems, to easily install the required dependencies for this project. If Homebrew is not yet installed, follow the instructions on its homepage.
Once Homebrew is installed, the project dependencies can be installed by running the following command in the terminal:
brew install python3 postgresql
Before the project setup, follow these steps for database setup:
-
Start the PostgreSQL service. The command may vary depending on the operating system:
brew services start postgresql
-
Connect to the default
postgres
database:psql postgres
-
If the
postgres
user does not exist, create a new user namedpostgres
with passwordpostgres
:CREATE USER postgres WITH PASSWORD 'postgres';
If the
postgres
user already exists, set the password for this user to 'postgres':ALTER USER postgres WITH PASSWORD 'postgres';
-
Create a database named
moxie
owned by thepostgres
user:CREATE DATABASE moxie OWNER postgres;
-
Exit the PostgreSQL shell:
\q
After the database setup, the following steps are followed to set up the project:
-
Clone the repository:
git clone https://github.com/lmiguelvargasf/moxie
-
Navigate into the project directory:
cd moxie
-
Install the project dependencies using PDM:
pdm install
-
Copy the
.env.example
file to.env
:cp .env.example .env
Open the
.env
file and replace the placeholders in theDATABASE_URL
with the appropriate values. The connection string should reflect the values used in the Database Setup section. For example:DATABASE_URL=postgresql+asyncpg://postgres:postgres@localhost:5432/moxie
In this example,
postgres
is the username and password,localhost
is the host,5432
is the port (default PostgreSQL port), andmoxie
is the database. -
Run the migrations:
pdm migrate
-
Run the project:
pdm dev
-
Access the application by clicking on the following link:
localhost:8000
. The following response should be seen:{"status": "up"}
-
Access the admin tool by clicking on the following link:
localhost:8000/admin
.
At least a med spa is assumed to exists in the database. There is no endpoint for this, so
you can create it by using the admin tool, psql
, or any UI tool as pgAdmin.
The list of available endpoints is in localhost:8000/docs. In order to test the endpoints, feel free to use any tool you feel comfortable with like Postman, cURL, HTTPie, HTTPx, etc.
A Postman collection has been included to test the endpoints that were implemented. In order to use this collection, it is assumed you will need to install Postman. Then, you will need to import it.
Assumption: API authentication is not initially required since there are no explicitly required user roles or data privacy concerns demanding such authentication.
Rationale: the focus of the assignment is primarily on demonstrating CRUD functionality and the relationships between entities rather than securing those operations. Omitting authentication simplifies the initial setup and accelerates development, which is crucial within the constrained timeline of 2-3 hours.
Assumption: it is not required to track the identity of the individual making the appointment since the assignment does not include user identities in the data model for appointments or services.
Rationale: considering the time constraints and the directions provided, it seems reasonable to focus on the relationship between med spas, services, and appointments without complicating the schema with user management.
Assumption: med spas operate during standard business hours (9:00 AM to 5:00 PM) and follow the local timezone of their physical locations.
Rationale: the assignment does not provide specifics on operating hours or timezone management, so assuming standard business hours simplifies scheduling, availability checks, and conflict management, avoiding the complexities of handling various timezones or extended hours.
Assumption: all services offered by the med spas are available without constraints of inventory or specific availability slots.
Rationale: no details are provided about limitations on service availability. This assumption will avoid implementing inventory or slot management systems.