Article Planner

Problem Statement

Tech bloggers and content teams lose ideas in scattered notes and never see the pipeline: which posts are still raw ideas, which are outlined, which are drafted, which shipped. A REST API for this gets chatty fast (fetch article + its category + tags + status in separate calls), and a half-tested backend rots. The need is a single, flexible, well-tested API that models the workflow, not just the data.

Proposed Solution

Article Planner is a GraphQL backend for managing tech-blog article ideas through their full lifecycle. A writer registers/logs in (JWT), creates article ideas, categorizes and tags them, and moves each through an explicit status pipeline: IDEA → OUTLINED → DRAFT → PUBLISHED. One GraphQL endpoint serves flexible queries and mutations over the whole model.

Full Solution Details

Auth — JWT-based registration and login.
Article CRUD — create/read/update/delete article ideas.
Categorization — organize by categories and tags.
Status tracking — an explicit four-stage editorial pipeline.
GraphQL — a single endpoint with flexible queries/mutations and a Playground for exploration.
Testing — unit + integration tests on Jest using MongoDB Memory Server (real DB behavior, no external dependency).

Technical Documentation

Node.js + Express + TypeScript with Apollo Server v5 exposing the GraphQL schema, and MongoDB via Mongoose. The standout is the test setup: Jest runs against MongoDB Memory Server, so integration tests hit a real (in-memory) Mongo instance rather than mocks — meaning queries, validations, and schema behavior are tested as they'll actually run, with no external database needed in CI. Code quality is enforced with ESLint + Prettier + Husky git hooks. Strict TypeScript throughout, including the GraphQL types.

Tech Stack

Node.js, Express, TypeScript, GraphQL (Apollo Server v5), MongoDB/Mongoose, JWT; Jest + MongoDB Memory Server, ESLint, Prettier, Husky.

System Design

Client ──GraphQL (single endpoint)──► Apollo Server v5
                                          │ resolvers
                                          ▼
                              Auth (JWT)  ·  Article service
                                          │
                                          ▼
                                   Mongoose / MongoDB
   Article: { title, body, category, tags, status: IDEA→OUTLINED→DRAFT→PUBLISHED }

  Tests: Jest ──► MongoDB Memory Server (real in-memory Mongo, no mocks)
  Hooks: Husky → lint + format on commit

Smart Architectural Decisions

Integration tests against a real (in-memory) Mongo. Using MongoDB Memory Server instead of mocking the data layer means tests exercise actual query/validation behavior — a far higher-confidence approach that catches schema/query bugs mocks would hide.
GraphQL for a relational-ish content model. Articles ↔ categories ↔ tags ↔ status is exactly the shape where GraphQL's single flexible endpoint beats chatty REST.
Workflow modeled explicitly. Encoding the editorial pipeline as a status enum (not free-text) makes the domain self-documenting and queryable.
Commit-time quality gates (Husky + ESLint + Prettier) keep the codebase consistent without relying on discipline.

Impacts

A flexible, strongly-typed, genuinely-tested GraphQL API for running a content pipeline end-to-end — and a clean reference for how to test a Mongo-backed GraphQL service properly.

Demonstrated Skills

GraphQL/Apollo Server schema + resolver design; editorial-workflow domain modeling (status pipeline); JWT auth; MongoDB/Mongoose; high-confidence testing strategy (Jest + MongoDB Memory Server, integration over mocks); TypeScript; tooling/quality automation (ESLint, Prettier, Husky).