Lab 05: FP Architecture

Time: 60 minutes | Level: Architect | Docker: node:20-alpine

Overview

Functional programming architecture with fp-ts: Reader monad for DI, Writer monad for logging, State monad, ReaderTaskEither for full async+DI+error, do-notation with bind/bindW, and parallel execution with sequenceS.


Step 1: Why fp-ts?

fp-ts principles:
  ✓ Errors as values (not exceptions)
  ✓ Pure functions (no side effects)
  ✓ Composability via pipe()
  ✓ Type-safe at every level
  ✓ Lazy evaluation (Task vs Promise)

Core types:
  Option<A>          — value that may not exist (replaces null)
  Either<E, A>       — right is success, left is error
  Task<A>            — lazy async (never rejects)
  TaskEither<E, A>   — async + typed errors
  Reader<R, A>       — computation that needs environment R
  ReaderTaskEither<R, E, A>  — all three combined

Step 2: Option — Safe Null Handling


Step 3: Either — Typed Errors


Step 4: TaskEither — Async + Typed Errors


Step 5: Reader — Dependency Injection


Step 6: ReaderTaskEither — Full Composition


Step 7: Do-Notation with bind/bindW


Step 8: Capstone — TaskEither Pipeline

📸 Verified Output:


Summary

Type
Purpose
Compose With

Option<A>

Nullable values

map, chain, getOrElse

Either<E,A>

Synchronous errors

map, flatMap, mapLeft

Task<A>

Async (never rejects)

map, flatMap

TaskEither<E,A>

Async + typed errors

pipe, Do, bind

Reader<R,A>

DI at compile time

map, flatMap, ask

ReaderTaskEither<R,E,A>

All three combined

Full pipeline

pipe

Left-to-right composition

All types

Last updated