InteractiveFrameworks

Microservices

Split the cats API into a service and a gateway that talk over TCP: request-response messages and events, replies that stream or time out, errors that cross the wire, the pipeline on a message, apps that both serve HTTP and listen for messages, a transport of your own, CQRS, and the health checks an orchestrator reads.

lessons
9
level
advanced
time
4.5 hours
Start with Your first microservice

Messages

A service that answers messages instead of HTTP requests, a gateway that asks, and events nobody waits for.

  1. 1
    Your first microservice

    Split the cats API in two: a cats service that answers messages over TCP, and an HTTP gateway that asks it. Start the service with createMicroservice, answer patterns with @MessagePattern, register a client with ClientsModule and send it messages.

    Read the theory
  2. 2
    Events

    Publish what happened instead of asking for an answer: the gateway emits a 'cat.adopted' event and answers 202 at once, and two handlers in the cats service react to it, each for its own purpose.

    Read the theory
  3. 3
    Streams and timeouts

    Replies that arrive over time and replies that never arrive: the cats service streams search results one cat at a time, the gateway collects them, and a census that takes too long is cut off with a timeout and answered 504.

    Read the theory

Around the handler

Errors that cross the wire, the pipeline on a message, and an app that serves HTTP and listens for messages at once.

  1. 4
    Errors across the wire

    What a thrown error becomes on the other side of a transport: RpcException for errors the caller can act on, an exception filter that turns a domain error into one, and a gateway that turns every reply's error into the right HTTP status.

    Read the theory
  2. 5
    Pipes, guards and interceptors

    The request pipeline you know from HTTP, on a message: a ValidationPipe that refuses a bad payload with an RpcException, a guard that reads its key from the payload, and an interceptor that audits every handler, in the order Nest runs them.

    Read the theory
  3. 6
    Hybrid applications

    One application, two doors: the gateway keeps serving HTTP and also listens on TCP for the events the cats service publishes, sharing its global pipe with the messages through inheritAppConfig.

    Read the theory

Building services

A transport the framework does not ship, commands and queries kept apart, and the health checks an orchestrator reads.

  1. 7
    A transport of your own

    Carry the cats service's messages over something Nest has no transporter for: the shelter's message bus. Write the server strategy that finds and runs the handlers, and the client proxy that publishes requests, matches their replies and dispatches events, then plug both in without touching a handler.

    Read the theory
  2. 8
    CQRS

    Keep the cats service's writes and reads apart: messages become commands and queries on their buses, an adoption is an aggregate that applies an event, an event handler keeps the notice board, and a saga turns every adoption into the next command.

    Read the theory
  3. 9
    Health checks

    Tell an orchestrator whether the gateway is alive and whether it is ready: a liveness check that asks nothing, and a readiness check with Terminus that pings the cats service over TCP, the vet clinic over HTTP, and the shelter's kennels through an indicator of your own that can be up, degraded or down.

    Read the theory