MedsWarning

A web system to help users manage and track their medication expiration dates and send reminders to renew those that have expired.

Table of contents

• Purpose
• Status
• Project Stack
• What do I need?
• Setup
• How to run it
• Folder structure
• Branches and Environments
• Roadmap
• License

Purpose

After developing several React-based applications with a similar tooling stack, I wanted to expand my skills in several concepts (such as server-side rendering) and libraries (such as zod, prisma, and shadcn).

Also, I wanted to unify this new stack into a tool, though for a common issue, the expiration date.

The tool's objective is to create notifications across several channels that warn the user which meds are about to expire and avoid unpleasant situations (sometimes we need a pill for a headache, and if it is consumed after that date, its effect can be reduced to zero or provoke side effects).

Status

Project Stack

What do I need?

Before cloning this repo, I recommend installing the following software:

• Node >= 24.4.0 to install packages.
• A PostgreSQL database on your local machine or in a cloud service.
• A Mailgun account to access its API key and sender email address.

Setup

After cloning the repo, install the node packages in the project's root file.

git clone https://github.com/NicolasOmar/meds-warning.git
cd meds-warning
npm run setup

At last, create an .env file at your project's root with the following content.

DATABASE_URL=HERE_GOES_YOUR_DATABASE_CONNECTION_STRING
MAILGUN_API_KEY=HERE_GOES_YOUR_MAILGUN_API_KEY
MAILGUN_DOMAIN=HERE_GOES_YOUR_MAILGUN_DOMAIN
JWT_SECRET=HERE_GOES_YOUR_JWT_SECRET
TEST_PASSWORD=HERE_GOES_YOUR_TEST_PASSWORD
RESET_PASSWORD_BASE_URL=HERE_GOES_YOUR_RESET_PASSWORD_BASE_URL

TEST_PASSWORD is only for a placeholder text in certain scenarios; its data will not impact any database.

MAILGUN_DOMAIN is the domain you configured in Mailgun in order to make the mailing sevice work.

How to run it

To run it, simply execute

npm start

In case you want to execute it as a single instance (using a production-like build)

npm start:prod

Folder structure

In case you have cloned the repo, it will show you the following folders:

• .github: Github Actions files used to run post-merge commits like unit test coverage collection.
• .husky: Dedicated to Husky configuration files.
• actions: Dedicated to React's Server Functions. Organized by entity.
• app: Location of system's routes structure based on NextJs App Router.
• components: Location of all used components:
  • base: Those installed from shadcn.
  • custom: Implementations of base components with logic included to handle specific tasks.
  • forms: Form components with their own input structure and action call. Those are client components due to the useActionState hook.
• prisma: Location of prisma implementation with its models/entities and migrations to mirror the entities relationship in the database.
• shared: Location of shared pieces of reusable code to be used across the system.
  • constants:: Dedicated to labels, strings, regular expressions, and configuration objects.
  • functions:: Dedicated to generalistic functions that can be used across the application.
  • ts: Dedicated to typescript interfaces, types, enums, and other features.

Branches and Environments

After my previous experience with semantic-release in other projects, I decided to give the following meaning to the project's versions after v4.0.0:

• Major versions (5.0.0, 6.0.0, and beyond) will refer to milestone achievements and significant changes that will need extra attention before the update.
• Minor versions (4.1.0, 4.2.0, and so on) will refer to bug fixes that required several important code changes or specific new features.
• Patch versions (4.0.1, 4.0.2, and so on) will refer to bug fixes that required small code changes or weekly dependency updates.

To check the current project's status, go to the Roadmap section.

Branching

Given the mentioned release logic, main is the only static branch, and each developed feature or fix will have a unique branch with its PR and a merge commit following semantic versioning and semantic commits specifications.

Roadmap

The first version/release (v1.0) was created to investigate, pick, and integrate several libraries as project technical foundations, which took the shape of a proof of concept that you can review here.

Since 23/03/2026, I have archived the project for an indeterminate time because I need to refocus my time on other priorities related to my current assignments and career path, which will take a big part of my time.

I will keep you posted on any updates, which will be forthcoming shortly.

License

GPL 3.0