Backend development at scale is no longer about frameworks, endpoints, or writing code that works. At an advanced level, backend development is not about frameworks, syntax, or clever abstractions. It’s about designing resilient, scalable, maintainable systems that survive reality: traffic spikes, network failures, partial outages, human mistakes, and evolving teams.

Having led and designed systems that have scaled from hundreds to millions of users, I want to share the patterns, trade-offs, and concrete examples that make the differences.

This guide documents the principles to build scalable, resilient, production-grade systems.

1. Systems Design Over Endpoints — Real Signup Flow Example

Junior devs think API endpoints. Leads think flows and failure modes.

Scenario: Signup Flow with External Dependencies

Requirements:

• Register user credentials
• Send welcome email
• Log analytics
• Create billing profile
• Enable feature flags

Naive Synchronous Design

POST /signup
  → create user record
  → send welcome email (blocking)
  → create billing profile (blocking)
  → log analytics
  → enable feature flags
  → respond 200 OK

Why this is bad:

• If the email service is down, signup fails.
• Latency depends on the slowest external call.
• System is tightly coupled and hard to scale.
• No clear failure isolation.

Lead-Level Design: Asynchronous, Event-Driven, Resilient

Architecture diagram description:

• Client calls POST /signup → User Service creates user record with status PENDING.
• User Service emits a UserCreated event on an Event Bus (Kafka, RabbitMQ, or similar).
• Email Service asynchronously consumes UserCreated and sends a welcome email.
• Billing Service consumes the event and creates a billing profile.
• Analytics Service consumes the event to log metrics.
• Feature Flags Service listens and enables features.

Explanation:

• POST /signup writes user record synchronously.
• Emits a UserCreated event on Event Bus (Kafka/RabbitMQ).
• Other services consume events asynchronously and retry on failure.

Code snippet — event emission in Node.js:

// userService.js
async function signupUser(userData) {
  const user = await UserModel.create(userData);
  await eventBus.publish('UserCreated', { userId: user.id, email: user.email });
  return user;
}

Tooling suggestion:

• Use Kafka or RabbitMQ for reliable event streaming.
• Implement dead-letter queues (DLQs) for failed events.

2. Data Modeling for Reality — Orders System Example

Naive schema (normalized):

Tables:

• orders (id, user_id, total, status)
• order_items (id, order_id, product_id, quantity)
• products (id, name, price)

Problem query:

Get total revenue per day → expensive joins and aggregations.

Explanation:

• Write model normalized for ACID.
• Event processor updates denormalized aggregates asynchronously.
• Dashboard queries aggregates, avoiding expensive joins.

Code snippet — event processor updating aggregates:

eventBus.subscribe('OrderCreated', async (event) => {
  const { date, total } = event.payload;
  await AggregatesDB.query(`
    INSERT INTO daily_order_stats(date, total_revenue, order_count)
    VALUES ($1, $2, 1)
    ON CONFLICT (date)
    DO UPDATE SET
      total_revenue = daily_order_stats.total_revenue + $2,
      order_count = daily_order_stats.order_count + 1
  `, [date, total]);
});

3. Transaction Boundaries & Consistency — Payment Flow

POST /checkout
  → create order
  → charge card (external API)
  → mark order paid

Problem:

• Failures cause duplicate charges or lost updates.
• If payment gateway succeeds but response is lost, system inconsistencies arise.

Robust Event-Driven Flow

Steps:

1. Client calls /checkout → Order Service creates order with PENDING status.

2. Order Service emits PaymentRequested event.

3. Payment Service listens:

• Charges card.
• Emits PaymentSucceeded or PaymentFailed.

4. Order Service updates order status accordingly.

Idempotency:

• Payment Service tracks transaction IDs.
• Duplicate events are ignored.
• Webhook duplicates handled safely.

4. API Design for Longevity and Compatibility

APIs are contracts that live far longer than their creators.

Common anti-patterns:

Breaking clients with minor changes

Ignoring backward compatibility

Versioning by URL path (/v1, /v2), leading to maintenance hell

Better Practices

• Use media type versioning in headers (Accept: application/vnd.myapi.v2+json)
• Add new fields; don’t remove or rename existing ones.
• Mark deprecated fields clearly.
• Use feature flags to toggle behaviors.

This lets you evolve APIs without breaking existing clients.

5. Asynchronous Architecture & Event Thinking

Synchronous monoliths break under load and complexity.

Events are facts about what happened.

Example: Deleting a user:

• Emit UserDeleted { user_id, timestamp }
• Consumers revoke access, delete data, cancel subscriptions asynchronously.

This ensures:

• The deletion API is fast and reliable.
• Downstream systems can process independently.Retry and ordering issues can be handled per consumer.

6. Caching as Architecture, Not Optimization

Caching decisions require clear ownership.

Example: Dashboard Cache

• Use Redis or similar to cache dashboard query results for 5 minutes.
• Cache invalidation triggered by write services emitting invalidation messages.
• Avoid infinite TTLs or guesswork.

7. Reliability Engineering — Circuit Breaker Pattern

Problem:

Email service is flaky and causes request timeouts.

Solution:

• Add a circuit breaker to email calls.
• After 5 failures in 10 seconds, circuit opens.
• Requests fail fast, emails queued for later.
• Circuit resets when email service recovers.

This prevents cascading failures and improves user experience.

8. Observability — Distributed Tracing

• Use OpenTelemetry to propagate trace IDs.
• Each service logs structured spans with start/end times.
• Visualization tools (Jaeger, Zipkin) show request flow and latency bottlenecks.

9. Performance & Tail Latency

• Track latency percentiles (P50, P95, P99).
• Identify tail latency sources: slow DB queries, network timeouts.
• Use timeouts, circuit breakers, caching to reduce tail effects.

10. Security as Architecture — Zero Trust Model

• Mutual TLS between services.
• JWT-based auth and authorization for every internal call.
• Audit logs for sensitive operations.

11. Cost-Aware Design — AWS Lambda Example

• Combine small functions to reduce invocation count.
• Use provisioned concurrency for critical flows.
• Analyze cost per request and optimize.

12. Maintainability Over Cleverness

• Favor explicit, readable code.
• Avoid abstractions that obscure flow.
• Write code new engineers can understand in days, not weeks.

13. Senior, Lead, and Staff Engineer Differences

• Senior: solves problems reliably.
• Lead: designs systems and teams that prevent problems.
• Staff: aligns architecture and multiplies impact organization-wide.

Final Words

Building production-grade backends is a craft of judgment under uncertainty.

Mastering these patterns and tools positions you to design systems that:

• Fail gracefully
• Scale predictably
• Are maintainable and observable

In the world of software development, writing maintainable and scalable code is crucial for long-term success. The SOLID principles, a set of five design principles, are designed to help developers achieve these goals by promoting good software design practices. In this article, we'll explore how to apply the SOLID principles in a real-world Node.js application using TypeScript and Apollo Server to build a GraphQL API.

This article is divided into several sections:

1. Introduction to SOLID Principles
2. Setting Up the Project
3. Single Responsibility Principle (SRP)
4. Open/Closed Principle (OCP)
5. Liskov Substitution Principle (LSP)
6. Interface Segregation Principle (ISP)
7. Dependency Inversion Principle (DIP)
8. Conclusion

1. Introduction to SOLID Principles

SOLID is an acronym for five design principles that aim to make software more understandable, flexible, and maintainable. Here's a quick overview:

• Single Responsibility Principle (SRP): A class should have only one reason to change, meaning it should have only one job or responsibility.
• Open/Closed Principle (OCP): Software entities should be open for extension but closed for modification.
• Liskov Substitution Principle (LSP): Objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program.
• Interface Segregation Principle (ISP): No client should be forced to depend on methods it does not use.
• Dependency Inversion Principle (DIP): High-level modules should not depend on low-level modules. Both should depend on abstractions.

In this article, we'll implement a GraphQL API using Apollo Server and TypeScript, applying these principles to create a robust and scalable architecture.

2. Setting Up the Project

Before applying the SOLID principles, let's develop a basic Node.js project with TypeScript and Apollo Server.

step 1: Initialize the project

On the terminal, execute the following command:

mkdir solid-graphql && cd solid-graphql && npm init -y

step 2: Install dependencies

On the terminal, execute the following command:

npm install apollo-server graphql reflect-metadata type-graphql 
npm install --save-dev typescript ts-node nodemon @types/node

step 3: Configure TypeScript

Create a tsconfig.json file:

{
  "compilerOptions": {
    "target": "ES2020",
    "module": "commonjs",
    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "outDir": "./dist"
  },
  "include": ["src"],
  "exclude": ["node_modules"]
}

step 4: Create the project structure

mkdir src && touch src/index.ts

step 5: Set up Apollo Server

Let's start by setting up a basic Apollo Server in src/index.ts:

import 'reflect-metadata';
import { ApolloServer } from 'apollo-server';
import { buildSchema } from 'type-graphql';

async function startServer() {
  const schema = await buildSchema({
    // Resolvers will be added here
  });

  const server = new ApolloServer({ schema });

  server.listen({ port: 4000 }, () =>
    console.log('Server is running on http://localhost:4000/graphql')
  );
}

startServer();

With this setup, we're ready to start applying the SOLID principles. Let's Go 🧑‍💻

3. Single Responsibility Principle (SRP)

The Single Responsibility Principle states that a class should have only one reason to change. In the context of our GraphQL API, this means that each part of our application should be responsible for a single aspect of functionality. Let's implement a simple user management feature to demonstrate SRP.

Example: User Entity and Resolver

Let's create a  User entity and its corresponding resolver.

Step 1: Create the User Entity

mkdir -p src/entities
touch src/entities/User.ts

Step 2: Create the User Resolver

mkdir -p src/resolvers
touch src/resolvers/UserResolver.ts

import { Query, Resolver } from 'type-graphql';
import { User } from '../entities/User';

@Resolver(User)
export class UserResolver {
  private users: User[] = [
    { id: '1', name: 'John Doe', email: 'john@example.com' },
    { id: '2', name: 'Jane Smith', email: 'jane@example.com' },
  ];

  @Query(() => [User])
  getUsers(): User[] {
    return this.users;
  }
}

Step 3: Register the Resolver

Update the src/index.ts file to include the resolver:

import { UserResolver } from './resolvers/UserResolver';

const schema = await buildSchema({
  resolvers: [UserResolver],
});

SRP in Action

In this example, the User entity is only responsible for defining the structure of a user, and the UserResolver is responsible for handling GraphQL queries related to users. This separation ensures that changes to how we fetch or modify users will not affect the user structure, adhering to SRP. Each class has a single responsibility, making the code easier to maintain.

SRP Violation Example

Now, let's see how violating SRP can cause issues. Imagine we decide to add user logging functionality directly into the UserResolver.

import { Query, Resolver } from 'type-graphql';
import { User } from '../entities/User';

@Resolver(User)
export class UserResolver {
  private users: User[] = [
    { id: '1', name: 'John Doe', email: 'john@example.com' },
    { id: '2', name: 'Jane Smith', email: 'jane@example.com' },
  ];

  @Query(() => [User])
  getUsers(): User[] {
    this.logUsers(); // Added logging functionality
    return this.users;
  }

  private logUsers() {
    console.log('Users:', this.users);
  }
}

Why This Violates SRP

The UserResolver now has two responsibilities: fetching users and logging them. This coupling can make the code harder to change and test. If the logging requirement changes, you'll need to modify the UserResolver, which violates SRP.

Solution: Create a separate UserLogger class that handles logging:

class UserLogger {
  log(users: User[]) {
    console.log('Users:', users);
  }
}

Then use it in the UserResolver:

@Resolver(User)
export class UserResolver {
  private userLogger = new UserLogger();

  @Query(() => [User])
  getUsers(): User[] {
    this.userLogger.log(this.users);
    return this.users;
  }
}

This way, the UserResolver remains focused on its primary responsibility.

4. Open/Closed Principle (OCP)

OCP in Action

The Open/Closed Principle suggests that software entities should be open for extension but closed for modification. Let's extend the UserResolver to support filtering users by name without modifying the existing getUsers method.

Step 1: Add a New Query

import { Arg, Query } from 'type-graphql';

@Resolver(User)
export class UserResolver {
  private users: User[] = [
    { id: '1', name: 'John Doe', email: 'john@example.com' },
    { id: '2', name: 'Jane Smith', email: 'jane@example.com' },
  ];

  @Query(() => [User])
  getUsers(): User[] {
    return this.users;
  }

  @Query(() => [User])
  filterUsersByName(@Arg('name') name: string): User[] {
    return this.users.filter(user => user.name.includes(name));
  }
}

OCP Violation Example

Now, let's violate the OCP by directly modifying the getUsers method to include filtering.

@Query(() => [User])
getUsers(@Arg('name', { nullable: true }) name?: string): User[] {
  if (name) {
    return this.users.filter(user => user.name.includes(name));
  }
  return this.users;
}

Why This Violates OCP

By modifying the getUsers method to include filtering logic, we are changing the existing functionality. This violates OCP because any changes to the filtering logic could potentially break the original getUsers method.

Solution: Instead of modifying the existing method, we should add a new method (like filterUsersByName) that extends the functionality while keeping the original method unchanged.

5. Liskov Substitution Principle (LSP)

LSP in Action

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. Let's create a SpecialUser class that extends the User class.

Step 1: Create the SpecialUser Class

import { Field, ObjectType } from 'type-graphql';
import { User } from './User';

@ObjectType()
export class SpecialUser extends User {
  @Field()
  isAdmin: boolean;
}

Step 2: Update the Resolver

@Resolver(User)
export class UserResolver {
  private users: User[] = [
    { id: '1', name: 'John Doe', email: 'john@example.com' },
    { id: '2', name: 'Jane Smith', email: 'jane@example.com' },
  ];

  @Query(() => [User])
  getUsers(): User[] {
    return this.users;
  }

  @Query(() => [SpecialUser])
  getSpecialUsers(): SpecialUser[] {
    return this.users.map(user => ({
      ...user,
      isAdmin: false,
    })) as SpecialUser[];
  }
}

LSP Violation Example

Let's violate the LSP by changing the behavior of the subclass in a way that breaks the expected behavior.

@ObjectType()
export class SpecialUser extends User {
  @Field()
  isAdmin: boolean;

  // Overriding a method to break LSP
  getUserEmail() {
    throw new Error('Email is restricted');
  }
}

Why This Violates LSP

The getUserEmail method in SpecialUser behaves differently from what is expected in the User class. If we substitute a User object with a SpecialUser object, the application will break when trying to access the user's email. This violates LSP because the subclass does not adhere to the contract established by the superclass.

Solution: Ensure that the subclass does not change the expected behavior of the superclass. Any new functionality should be additive and not modify the existing contract.

6. Interface Segregation Principle (ISP)

ISP in Action

The Interface Segregation Principle states that no client should be forced to depend on methods it does not use. Let's create interfaces for different user services.

Step 1: Define Interfaces

// src/services/IUserService.ts
export interface IUserService {
  getUsers(): User[];
  getUserById(id: string): User | undefined;
}

// src/services/IAdminService.ts
export interface IAdminService {
  promoteToAdmin(id: string): void;
}

ISP Violation Example

Let's violate the ISP by creating a single interface that combines both user and admin services.

export interface IUserAdminService {
  getUsers(): User[];
  getUserById(id: string): User | undefined;
  promoteToAdmin(id: string): void;
}

Why This Violates ISP

By combining user and admin services into one interface, we force all clients to implement methods they might not need. For example, a client that only needs to retrieve users would also have to implement promoteToAdmin, even if it's not relevant to their functionality.

Solution: Break down the interface into smaller, more specific interfaces (like IUserService and IAdminService). Clients should only implement the interfaces that are relevant to their needs.

7. Dependency Inversion Principle (DIP)

DIP in Action

The Dependency Inversion Principle suggests that high-level modules should not depend on low-level modules but on abstractions. Let's implement a simple user repository.

Step 1: Define the Repository Interface

// src/repositories/IUserRepository.ts
export interface IUserRepository {
  findAll(): User[];
  findById(id: string): User | undefined;
}

Step 2: Implement the Repository

// src/repositories/UserRepository.ts
import { IUserRepository } from './IUserRepository';
import { User } from '../entities/User';

export class UserRepository implements IUserRepository {
  private users: User[] = [
    { id: '1', name: 'John Doe', email: 'john@example.com' },
    { id: '2', name: 'Jane Smith', email: 'jane@example.com' },
  ];

  findAll(): User[] {
    return this.users;
  }

  findById(id: string): User | undefined {
    return this.users.find(user => user.id === id);
  }
}

Step 3: Use the Repository in the Resolver

import { UserRepository } from '../repositories/UserRepository';

@Resolver(User)
export class UserResolver {
  private userRepository: IUserRepository;

  constructor() {
    this.userRepository = new UserRepository();
  }

  @Query(() => [User])
  getUsers(): User[] {
    return this.userRepository.findAll();
  }
}

DIP Violation Example

Let's violate DIP by directly depending on a low-level implementation instead of an abstraction.

import { UserRepository } from '../repositories/UserRepository';

@Resolver(User)
export class UserResolver {
  private userRepository = new UserRepository(); // Direct dependency

  @Query(() => [User])
  getUsers(): User[] {
    return this.userRepository.findAll();
  }
}

Why This Violates DIP

The UserResolver is tightly coupled to the UserRepository implementation. If we ever need to switch to a different repository implementation, we would need to modify the UserResolver, which violates the DIP.

Solution: Depend on abstractions, not implementations. Use an interface (IUserRepository) and inject the implementation:

@Resolver(User)
export class UserResolver {
  constructor(private userRepository: IUserRepository) {}

  @Query(() => [User])
  getUsers(): User[] {
    return this.userRepository.findAll();
  }
}

This allows you to swap out the repository implementation without modifying the resolver.

8. Conclusion

Applying SOLID principles in your TypeScript and Node.js applications can significantly improve code quality, making it more maintainable, scalable, and robust. By understanding and adhering to these principles, you can avoid common pitfalls and create a cleaner, more modular architecture. However, it's also important to recognize when these principles are being violated and the potential consequences of such violations. Through careful design and thoughtful application of SOLID principles, you can build better software that stands the test of time.

Objective: An advanced, production-grade, full-stack backend guide for mastering GraphQL . It covers architecture patterns, performance optimization, security, team conventions, scaling strategies, schema governance, multi-tenancy, federation, observability, testing, and more. Includes examples in TypeScript, both with and without NestJS, and Apollo Server setups.

Table of Contents

1. GraphQL Deep Dive — Concepts, History, and Evolution
2. Schema Design Principles and Anti-patterns
3. Clean Architecture and Domain-driven Design for GraphQL
4. Implementation Layers: Schema, Resolver, Service, Repository
5. Apollo Server Advanced Configuration (with Plugins, Middleware, and Caching)
6. NestJS GraphQL Deep Integration (Code-First + Federation)
7. Schema Federation and Microservice Design (Federated Architecture Blueprint (Multi-Service Apollo Gateway))
8. Multi-Tenant Federation Strategies
9. Cross-Service Caching and DataLoader Integration
10. Performance and Scaling — DataLoader, Batching, Persisted Queries, CDN, and Query Costing
11. Security Architecture (AuthN/Z, Complexity, Depth, Rate Limits, Abuse Protection)
12. API Governance, Versioning, and Schema Registry
13. Advanced Pagination, Filtering, Sorting, and Cursor Design
14. Subscriptions and Real-Time GraphQL (WebSockets, Kafka, Redis, RabbitMQ)
15. Testing Strategy (Unit, Integration, Contract, E2E, Snapshot Testing)
16. Observability and Monitoring (OpenTelemetry, Tracing, Metrics, Logs)
17. DevOps, CI/CD, and Deployment Strategies (Kubernetes, Serverless, CDN)
18. Developer Experience: Tooling, Codegen, Linting, Type Safety, Documentation
19. Error Handling, Logging, and Resilience Patterns
20. Performance Benchmarks, Profiling, and Query Optimization
21. Production Checklists and Best Practices
22. Common Interview Scenarios, System Design Questions, and Answers
23. Appendix: Tools, Libraries, and Resources

Introduction and Philosophy

GraphQL is not just a replacement for REST — it’s a declarative contract between clients and servers. As a GraphQL Developer, your responsibilities are to ensure:

• Schema quality (easy to use, stable, evolvable)
• Separation of concerns (thin resolvers, rich services)
• Performance & security (DataLoader, depth limits, complexity analysis)
• Observability (resolver-level tracing and metrics)
• Developer experience (documentation, codegen, secure playground)

1. GraphQL Deep Dive — Concepts, History, and Evolution

GraphQL was introduced by Facebook (2012, public 2015) to replace inefficient REST endpoints with a single endpoint that allows declarative, shape-specific data fetching. Its declarative query model lets clients specify what they need, while the server defines how to fetch it.

Strengths

• Eliminates over-fetching and under-fetching.
• Enables schema-driven contracts.
• Integrates perfectly with type systems like TypeScript.
• Enables schema introspection, developer tooling, and powerful self-documentation.

Challenges

• Performance pitfalls (N+1 problem).
• Complexity and depth abuse.
• Evolving schemas safely.

Key Features

• Single endpoint, multiple entry points (Query/Mutation/Subscription)
• Introspection for self-documentation
• Custom Scalars for advanced types (e.g., DateTime, Email, Decimal)
• Directives for metadata or logic control (e.g., @auth, @deprecated)

2. Schema Design Principles and Anti-patterns

A schema is the public contract of your API. Treat it like an API product.

Principles

2.1 Model around business capabilities, not database tables.

Concept:
Design your GraphQL schema based on what the business does, not how the database stores data.
GraphQL is a domain API, not a direct reflection of your persistence layer.

Bad Example (DB-driven):

type User {
  id: ID!
  name: String!
  email: String!
  roleId: ID!
}

type Role {
  id: ID!
  name: String!
}

type Query {
  users: [User!]!
  roles: [Role!]!
}

❌ The schema mirrors your tables directly.
There’s no concept of what the user does or represents in the business.

Good Example (Business-driven):

type User {
  id: ID!
  name: String!
  email: String!
  role: Role!
  permissions: [Permission!]!
  organization: Organization
}

type Organization {
  id: ID!
  name: String!
  members: [User!]!
  activeProjects: [Project!]!
}

type Query {
  getOrganizationOverview(id: ID!): OrganizationOverview!
}

Resolver (NestJS example):

@Resolver(() => Organization)
export class OrganizationResolver {
  constructor(private readonly orgService: OrganizationService) {}

  @Query(() => OrganizationOverview)
  async getOrganizationOverview(@Args('id') id: string) {
    return this.orgService.getOverview(id); // Fetches users, projects, KPIs
  }
}

✅ The schema now reflects business capabilities like “organization overview,” “active projects,” etc., not raw tables.

2.2 Favor composition over inheritance

Concept:
GraphQL’s type system supports interfaces and unions, but overusing inheritance leads to rigid APIs.
Instead, compose small reusable types.

Bad Example (Inheritance abuse):

interface Content {
  id: ID!
  title: String!
}

type BlogPost implements Content {
  id: ID!
  title: String!
  body: String!
}

type VideoPost implements Content {
  id: ID!
  title: String!
  videoUrl: String!
}

❌ Tightly coupled — every content type must implement Content.
Hard to evolve if a new type doesn’t fit exactly.

Good Example (Composition):

type Metadata {
  title: String!
  slug: String!
}

type BlogPost {
  id: ID!
  metadata: Metadata!
  body: String!
}

type VideoPost {
  id: ID!
  metadata: Metadata!
  videoUrl: String!
}

✅ Shared structure (metadata) via composition — more flexible, easier to extend.

2.3 Avoid overloading queries — separate mutations clearly.

Concept:
Queries should read. Mutations should change state.
Avoid overloading queries to perform side effects (like logging, updates, etc.).

Bad Example (Violates separation):

type Query {
  getUserAndIncrementViews(userId: ID!): User!
}

Good Example (Separation of concerns):

type Query {
  getUser(userId: ID!): User!
}

type Mutation {
  incrementUserViews(userId: ID!): User!
}

Resolvers:

@Query(() => User)
getUser(@Args('userId') userId: string) {
  return this.userService.findById(userId);
}

@Mutation(() => User)
incrementUserViews(@Args('userId') userId: string) {
  return this.userService.incrementViews(userId);
}

2.4 Keep inputs granular, and avoid nested mutations (complex transaction handling)

Concept:
Don’t build giant nested input trees where one mutation creates a parent, several children, and grandchildren in one call.
It’s brittle and hard to manage transactions across layers.

Bad Example:

mutation {
  createOrder(input: {
    customer: { name: "John" }
    products: [
      { id: "p1", quantity: 2 },
      { id: "p2", quantity: 1 }
    ]
  }) {
    id
  }
}

❌ One mutation triggers multiple table writes (Customer, Order, OrderItems).
Hard to validate or rollback partially failed operations.

Good Example (Granular inputs):

input CreateCustomerInput {
  name: String!
}

input AddProductToOrderInput {
  orderId: ID!
  productId: ID!
  quantity: Int!
}

type Mutation {
  createCustomer(input: CreateCustomerInput!): Customer!
  createOrder(customerId: ID!): Order!
  addProductToOrder(input: AddProductToOrderInput!): Order!
}

✅ Smaller mutations are easier to validate, test, and scale independently.
✅ If you need a “composite operation,” handle it in your service layer, not the schema.

Service Layer Example (TypeScript):

async createOrderWithProducts(customerId: string, items: ProductItemInput[]) {
  const order = await this.orderRepo.create({ customerId });
  for (const item of items) {
    await this.orderRepo.addProduct(order.id, item);
  }
  return order;
}

2.5 Anti-Patterns

• “God Query”: One query returning everything.
• “Thin Schema, Fat Resolver”: schema with poor type definitions, logic in resolvers.
• Field explosion — too many optional fields without grouping or pagination.

Example — Correct Design

type Query {
me: User!
users(filter: UserFilter, pagination: PageInput): UserConnection!
post(id: ID!): Post
}


type Mutation {
createUser(input: CreateUserInput!): User!
updateUser(input: UpdateUserInput!): User!
}


input CreateUserInput {
email: String!
name: String
}


input UserFilter {
search: String
isActive: Boolean
}

3. Clean Architecture and DDD for GraphQL

GraphQL is an interface layer — your business logic should live below it.

Clean Layer Separation

src/
├── domain/ # Entities, Value Objects, Repositories
├── usecases/ # Business rules
├── infra/ # DB, external services
├── graphql/ # Schema + Resolvers (presentation)
└── app.ts # Server bootstrap

Benefits

• Framework-agnostic
• Testable usecases
• No direct dependency between GraphQL resolvers and persistence

Example

// domain/user.entity.ts
export class User {
    constructor(public id: string, public email: string, public name ? : string) {}
}


// usecases/create-user.usecase.ts

export class CreateUserUsecase {
    constructor(private userRepo: UserRepo) {}
    async execute(input: CreateUserInput): Promise < User > {
        const existing = await this.userRepo.findByEmail(input.email);
        if (existing) throw new Error('Email exists');
        return this.userRepo.create(new User(uuid(), input.email, input.name));
    }
}

4. Implementation Layers

a) Concept Overview

GraphQL apps are often built too tightly — schema definitions and database queries end up mixed in resolvers.
At scale, this leads to technical debt and coupling.

Instead, you should follow a layered architecture:

This ensures:

• Each layer is independently testable.
• The domain logic stays clean, not tied to GraphQL.
• You can swap the ORM or even the transport (REST, gRPC) easily.

b) Example (Schema → Resolver → Service → Repository)

We demonstrating this pattern with:

• GraphQL schema using decorators (NestJS)
• Clean separation between layers
• Prisma-based repository
• Validation and error handling

Example — Apollo + Prisma

// src/users/users.module.ts
import { Module, Injectable } from '@nestjs/common';
import { Resolver, Query, Mutation, Args, ObjectType, Field, InputType, ID } from '@nestjs/graphql';
import { PrismaClient, User as PrismaUser } from '@prisma/client';
import { GraphQLError } from 'graphql';

// =======================
// SCHEMA (GraphQL Types)
// =======================
@ObjectType()
class User {
  @Field(() => ID)
  id: string;

  @Field()
  email: string;

  @Field({ nullable: true })
  name?: string;

  @Field()
  createdAt: Date;
}

@InputType()
class CreateUserInput {
  @Field()
  email: string;

  @Field({ nullable: true })
  name?: string;
}

@InputType()
class UpdateUserInput {
  @Field(() => ID)
  id: string;

  @Field({ nullable: true })
  name?: string;
}

// =======================
// REPOSITORY LAYER
// =======================
@Injectable()
class UserRepository {
  private prisma = new PrismaClient();

  async findAll(): Promise<PrismaUser[]> {
    return this.prisma.user.findMany();
  }

  async findById(id: string): Promise<PrismaUser | null> {
    return this.prisma.user.findUnique({ where: { id } });
  }

  async create(data: { email: string; name?: string }): Promise<PrismaUser> {
    return this.prisma.user.create({ data });
  }

  async update(id: string, data: { name?: string }): Promise<PrismaUser> {
    return this.prisma.user.update({ where: { id }, data });
  }

  async delete(id: string): Promise<PrismaUser> {
    return this.prisma.user.delete({ where: { id } });
  }
}

// =======================
// SERVICE LAYER
// =======================
@Injectable()
class UserService {
  constructor(private readonly repo: UserRepository) {}

  async listUsers() {
    return this.repo.findAll();
  }

  async getUser(id: string) {
    const user = await this.repo.findById(id);
    if (!user) throw new GraphQLError(`User ${id} not found`);
    return user;
  }

  async createUser(input: CreateUserInput) {
    const existing = await this.repo.findAll();
    if (existing.some((u) => u.email === input.email)) {
      throw new GraphQLError('Email already in use');
    }
    return this.repo.create(input);
  }

  async updateUser(input: UpdateUserInput) {
    await this.getUser(input.id); // validate existence
    return this.repo.update(input.id, { name: input.name });
  }

  async deleteUser(id: string) {
    await this.getUser(id);
    return this.repo.delete(id);
  }
}

// =======================
// RESOLVER LAYER
// =======================
@Resolver(() => User)
class UserResolver {
  constructor(private readonly service: UserService) {}

  @Query(() => [User])
  async users() {
    return this.service.listUsers();
  }

  @Query(() => User)
  async user(@Args('id', { type: () => String }) id: string) {
    return this.service.getUser(id);
  }

  @Mutation(() => User)
  async createUser(@Args('data') data: CreateUserInput) {
    return this.service.createUser(data);
  }

  @Mutation(() => User)
  async updateUser(@Args('data') data: UpdateUserInput) {
    return this.service.updateUser(data);
  }

  @Mutation(() => User)
  async deleteUser(@Args('id') id: string) {
    return this.service.deleteUser(id);
  }
}

// =======================
// MODULE DEFINITION
// =======================
@Module({
  providers: [UserResolver, UserService, UserRepository],
})
export class UsersModule {}

c) Explanation

✅ Benefits

• Single Responsibility — each layer does one thing well.
• Reusability — service logic can power REST, gRPC, or jobs.
• Testability — easily mock repositories and test services independently.
• Maintainability — large codebases scale better with this separation.
• 🔐 Security & Validation — centralized domain checks in services.

5. Apollo Server Advanced Configuration

Before diving into configuration examples, it’s important to understand that Apollo Server isn’t just a schema + resolver runner — it’s a gateway for observability, security, performance, and developer experience.

When working at scale or in production environments, advanced configuration becomes critical to handle:

• Performance optimization — controlling query depth, cost, batching, and caching.
• Security & validation — applying query whitelisting, complexity analysis, and request limits.
• Telemetry & monitoring — integrating OpenTelemetry, Prometheus, or Apollo Studio metrics.
• Schema modularization — loading schemas dynamically from multiple services or modules.
• Context enrichment — injecting user sessions, auth tokens, or request-scoped data.
• Plugin ecosystem — adding logging, tracing, or auditing middleware hooks.
• Server lifecycle management — customizing startup, shutdown, and error handling flows.

In a real-world GraphQL backend, your Apollo Server is the core execution environment, and configuring it properly can dramatically improve stability, observability, and developer velocity.

Example Setup Overview

An advanced Apollo Server setup usually includes:

• A schema loader (@graphql-tools/load or module federation)
• Performance controls: query depth, cost analysis, caching policies.
• Custom context factory: to inject per-request user/session data.
• Plugins: logging, metrics, tracing, and auditing.
• Health checks and graceful shutdown hooks.
• Integration with external systems (Redis cache, DataLoader batching, etc.).

Exemple:

import { ApolloServer } from '@apollo/server';
import { ApolloServerPluginDrainHttpServer } from '@apollo/server/plugin/drainHttpServer';
import depthLimit from 'graphql-depth-limit';
import { makeExecutableSchema } from '@graphql-tools/schema';
import { typeDefs, resolvers } from './schema';
import http from 'http';
import { contextFactory } from './context';
import { loggingPlugin, tracingPlugin } from './plugins';
import { rateLimitPlugin } from './security/rateLimit';

const schema = makeExecutableSchema({ typeDefs, resolvers });
const httpServer = http.createServer();

const server = new ApolloServer({
  schema,
  validationRules: [depthLimit(10)], // prevent deep queries
  context: contextFactory, // inject user/session info
  plugins: [
    ApolloServerPluginDrainHttpServer({ httpServer }),
    loggingPlugin(),
    tracingPlugin(),
    rateLimitPlugin({ max: 100, window: '1m' }),
  ],
  introspection: process.env.NODE_ENV !== 'production',
  formatError: (error) => {
    console.error('GraphQL Error:', error);
    return { message: error.message, code: error.extensions?.code };
  },
});

await server.start();
httpServer.listen({ port: 4000 });

6. NestJS GraphQL Deep Integration

NestJS is more than a framework: it’s an opinionated architecture that brings Dependency Injection (DI), modularity, and decorator-driven APIs to Node.js. When you combine NestJS with GraphQL you get a powerful platform for building large, maintainable, and testable GraphQL backends.

As a GraphQL developer you should focus on:

• Code-First vs Schema-First — Code-First (decorators + classes) gives excellent TypeScript safety and auto-schema generation; Schema-First (SDL) gives designers and non-TS teams control. Pick based on team needs.
• Scoped providers & per-request state — Create request-scoped providers for DataLoader, auth context, and transaction management to avoid cross-request leakage.
• Field-level guards & interceptors — Use Nest guards for auth/authorization and interceptors for logging, tracing and response shaping.
• Federation support — Build subgraphs with @nestjs/graphql federation features (@Key, @ResolveReference) for microservice ownership.
• Performance & caching — Leverage DataLoader, Redis caching, and field projection to minimize DB load.
• Testing & lifecycle hooks — Unit-test resolvers with DI mocks, integration-test modules with in-memory DB or testcontainers; use lifecycle hooks for startup/shutdown tasks.
• Observability — Integrate OpenTelemetry instrumentation at resolver/service level and export traces/metrics.

Example — NestJS Code-First GraphQL (TypeScript)

This example shows:

• UsersModule with UsersService and UsersResolver
• Request-scoped LoadersService providing DataLoader instances
• A guard for auth
• Federation-ready entity with ResolveReference
• Context injection in GraphQLModule.forRoot

// main.ts
import { NestFactory } from '@nestjs/core';
import { AppModule } from './app.module';
import { ValidationPipe } from '@nestjs/common';

async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  app.useGlobalPipes(new ValidationPipe({ whitelist: true }));
  await app.listen(4000);
}
bootstrap();

// app.module.ts
import { Module } from '@nestjs/common';
import { GraphQLModule } from '@nestjs/graphql';
import { join } from 'path';
import { UsersModule } from './users/users.module';

@Module({
  imports: [
    GraphQLModule.forRoot({
      autoSchemaFile: join(process.cwd(), 'src/schema.gql'), // Code-First
      context: ({ req }) => ({ req }), 
      buildSchemaOptions: { fieldResolverEnhancers: ['guards', 'interceptors'] },
      playground: process.env.NODE_ENV !== 'production',
      introspection: process.env.NODE_ENV !== 'production',
    }),
    UsersModule,
  ],
})
export class AppModule {}

// users/user.entity.ts
import { ObjectType, Field, ID } from '@nestjs/graphql';
import { Key } from '@nestjs/graphql/dist/federation'; // federation decorators

@ObjectType()
@Key('id') // federation key
export class UserEntity {
  @Field(() => ID) id: string;
  @Field() email: string;
  @Field({ nullable: true }) name?: string;
}

// users/loaders.service.ts
import { Injectable, Scope } from '@nestjs/common';
import DataLoader from 'dataloader';
import { UsersService } from './users.service';

// Request-scoped provider so loaders are per-request and safe to cache
@Injectable({ scope: Scope.REQUEST })
export class LoadersService {
  public userLoader: DataLoader<string, any>;

  constructor(private usersService: UsersService) {
    this.userLoader = new DataLoader(async (ids: readonly string[]) => {
      const users = await this.usersService.findByIds(ids as string[]);
      const map = new Map(users.map(u => [u.id, u]));
      return ids.map(id => map.get(id) ?? null);
    });
  }
}

// users/users.service.ts
import { Injectable } from '@nestjs/common';
// imagine prisma injected or repo pattern
@Injectable()
export class UsersService {
  constructor(private readonly repo /* e.g. PrismaService */) {}

  async findByIds(ids: string[]) {
    // use repo with `where id in (...)` and projection based on need
    return this.repo.user.findMany({ where: { id: { in: ids } }});
  }

  async findOneById(id: string) {
    return this.repo.user.findUnique({ where: { id }});
  }
}

// users/users.resolver.ts
import { Resolver, Query, Args, ResolveReference, ResolveField, Parent, Context } from '@nestjs/graphql';
import { UseGuards } from '@nestjs/common';
import { GqlAuthGuard } from '../auth/gql-auth.guard';
import { UsersService } from './users.service';
import { LoadersService } from './loaders.service';
import { UserEntity } from './user.entity';

@Resolver(() => UserEntity)
export class UsersResolver {
  constructor(private usersService: UsersService, private loaders: LoadersService) {}

  @Query(() => UserEntity)
  @UseGuards(GqlAuthGuard)
  async user(@Args('id') id: string) {
    return this.usersService.findOneById(id);
  }

  // Field resolver using the request-scoped DataLoader
  @ResolveField('friends', () => [UserEntity])
  async friends(@Parent() user: any) {
    return this.loaders.userLoader.loadMany(user.friendIds || []);
  }

  // Federation: resolve reference when gateway asks
  @ResolveReference()
  resolveReference(reference: { __typename: string; id: string }) {
    return this.usersService.findOneById(reference.id);
  }
}

// users/users.module.ts
import { Module } from '@nestjs/common';
import { UsersResolver } from './users.resolver';
import { UsersService } from './users.service';
import { LoadersService } from './loaders.service';

@Module({
  providers: [UsersResolver, UsersService, LoadersService],
  exports: [UsersService],
})
export class UsersModule {}

Notes & Best Practices for this pattern

• Scoped Loaders: mark loader providers as Scope.REQUEST so each HTTP request gets its own loaders (no cross-request caching).
• Guards & Roles: implement GqlAuthGuard to extract JWT from headers (or cookies) and attach user to context. Use role guards on resolvers or fields.
• Field Resolver Enhancers: buildSchemaOptions.fieldResolverEnhancers enables using Nest guards/interceptors on field resolvers.
• Projections: when possible, use info or custom decorators to project DB fields to minimize selects (Prisma select).
• Transactions: orchestrate complex multi-entity writes in service/usecase layer and manage DB transactions there (not in resolvers).
• Testing: use Nest’s Test.createTestingModule and mock injected providers (e.g., a mocked UsersService) to unit-test resolvers.
• Federation: to make the module a federated subgraph, use @Key, @ResolveReference, and the @nestjs/graphql federation utilities.

Federation Support

GraphQLFederationModule.forRoot({
    autoSchemaFile: true,
    gateway: {
        serviceList: [{
            name: 'users',
            url: 'http://users:4001/graphql'
        }]
    }
});

7. Schema Federation and Microservice Design

Apollo Federation enables multiple microservices (subgraphs) to provide portions of a unified GraphQL schema, combined via an Apollo Gateway. This allows:

• Independent deployments per service
• Service-level ownership of entities
• Schema evolution without breaking other teams
• Efficient modular development
• Each service defines a subgraph.
• Apollo Gateway composes schemas.
• Use entity references with @key directive.

Components

1. Gateway: Central schema composition, query planning, and routing
2. Subgraph Services: Each service exposes its portion of the schema
3. Shared Entities: Entities are resolved across services using @key and @requires
4. Data Sources: Each service may use its own database, cache, or API

Example Setup

graphqld-federation-project/
├── gateway/
│ └── index.ts
├── services/
│ ├── users/
│ │ ├── src/
│ │ │ ├── user.entity.ts
│ │ │ ├── users.resolver.ts
│ │ │ └── users.module.ts
│ ├── posts/
│ │ ├── src/
│ │ │ ├── post.entity.ts
│ │ │ ├── posts.resolver.ts
│ │ │ └── posts.module.ts
│ └── comments/
│ ├── src/
│ │ ├── comment.entity.ts
│ │ ├── comments.resolver.ts
│ │ └── comments.module.ts

User Service (Subgraph)

// users/user.entity.ts
import {
    ObjectType,
    Field,
    ID
} from '@nestjs/graphql';
import {
    Directive,
    Key
} from '@apollo/federation';


@ObjectType()
@Key(fields: 'id')
export class UserEntity {
    @Field(() => ID)
    id: string;


    @Field()
    email: string;
    @Field({
        nullable: true
    })
    name ? : string;
}


// users/users.resolver.ts
@Resolver(() => UserEntity)
export class UsersResolver {
    constructor(private usersService: UsersService) {}


    @Query(() => UserEntity)
    user(@Args('id') id: string) {
        return this.usersService.findOneById(id);
    }


    @ResolveReference()
    resolveReference(reference: {
        __typename: string;id: string
    }) {
        return this.usersService.findOneById(reference.id);
    }
}

Posts Service (Subgraph)

@ObjectType()
@Key(fields: 'id')
export class PostEntity {
    @Field(() => ID)
    id: string;


    @Field()
    title: string;


    @Field(() => UserEntity)
    @Directive('@provides(fields: "email")')
    author: UserEntity;
}

Apollo Gateway (Central Schema Composition)

import {
    ApolloGateway
} from '@apollo/gateway';
import {
    ApolloServer
} from 'apollo-server';


const gateway = new ApolloGateway({
    serviceList: [{
            name: 'users',
            url: 'http://localhost:4001/graphql'
        },
        {
            name: 'posts',
            url: 'http://localhost:4002/graphql'
        },
        {
            name: 'comments',
            url: 'http://localhost:4003/graphql'
        },
    ],
});


const server = new ApolloServer({
    gateway,
    subscriptions: false,
    context: ({
        req
    }) => ({
        user: authenticate(req)
    }),
});


server.listen({
    port: 4000
}).then(({
    url
}) => console.log(`Gateway running at ${url}`));

Key Federation Patterns

• @key: marks unique identifier for entity across services
• @extends: extend entity from another service
• @provides: service can provide additional fields to other services
• @requires: request fields from another service to resolve entity

Deployment Considerations

• Each subgraph deploys independently; updates do not break gateway if backwards-compatible
• Use service discovery (DNS, Consul, or Kubernetes services)
• Horizontal scaling at service-level
• Cache entity resolutions for high-demand queries
• Monitor per-service metrics (latency, error rate, throughput)

Advanced Features

• Partial Schema Ownership: each team owns one subgraph
• Versioning per Subgraph: independent release cycles
• Federated Tracing: trace resolution across services
• Security per Subgraph: JWT validation, field-level authorization
• Subscription Federation: use shared pubsub (Redis/Kafka) for real-time updates

This allow you to build microservice-based GraphQL backends with Apollo Federation, ensuring modularity, scalability, and maintainability.

8. Multi-Tenant Federation Strategies

Overview

n a multi-tenant GraphQL federation, each client (tenant) interacts with the same GraphQL API surface — but data, permissions, and analytics must remain isolated.
The challenge is to balance schema consistency with tenant-level isolation and performance efficiency.

Let’s go through each strategy with example code and how it fits into a federated architecture.

1. Context-Based Tenant Resolution: Inject tenant info into context per request.

Every incoming request includes a tenant identifier (JWT claims, API key, or x-tenant-id header).
This ID is injected into the GraphQL context and propagated across all subgraphs through the Apollo Gateway.

Gateway Example

// gateway/index.ts
import { ApolloGateway, IntrospectAndCompose } from '@apollo/gateway';
import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';

const gateway = new ApolloGateway({
  supergraphSdl: new IntrospectAndCompose({
    subgraphs: [
      { name: 'users', url: 'http://localhost:4001/graphql' },
      { name: 'billing', url: 'http://localhost:4002/graphql' },
    ],
  }),
});

const server = new ApolloServer({
  gateway,
  context: async ({ req }) => {
    const tenantId = req.headers['x-tenant-id'];
    if (!tenantId) throw new Error('Tenant header missing');
    return { tenantId };
  },
});

await startStandaloneServer(server, { listen: { port: 4000 } });

Subgraph Example (NestJS)

// app.module.ts
GraphQLModule.forRoot({
  autoSchemaFile: true,
  federationMetadata: true,
  context: ({ req }) => ({ tenantId: req.headers['x-tenant-id'] }),
});

// users.service.ts
@Injectable()
export class UsersService {
  constructor(private readonly prisma: PrismaService) {}

  async findAll(tenantId: string) {
    return this.prisma.user.findMany({ where: { tenantId } });
  }
}

// users.resolver.ts
@Resolver(() => UserEntity)
export class UsersResolver {
  constructor(private readonly service: UsersService) {}

  @Query(() => [UserEntity])
  async users(@Context('tenantId') tenantId: string) {
    return this.service.findAll(tenantId);
  }
}

2. Schema Partitioning:

For strict tenant isolation, each tenant gets a separate schema instance — possibly deployed as an isolated subgraph.
Useful when tenants have custom fields, features, or compliance requirements (e.g., GDPR, HIPAA).

// schema-loader.ts
import { buildSchema } from 'graphql';
import { TenantConfigService } from './tenant-config.service';

export async function buildTenantSchema(tenantId: string) {
  const config = await TenantConfigService.getConfig(tenantId);
  const typeDefs = `
    type Query {
      hello: String
      ${config.customFields.join('\n')}
    }
  `;
  return buildSchema(typeDefs);
}

3. Database Scoping: Single DB with tenant_id column or schema-per-tenant pattern. Data isolation is enforced at the persistence layer, not the schema.
Two common patterns:

a) Single Database, tenant_id column: All tenants share tables; every table includes tenant_id.

CREATE TABLE users (
  id UUID PRIMARY KEY,
  tenant_id UUID NOT NULL,
  name TEXT,
  email TEXT
);

Then every query filters by tenant_id:

// user.service.ts
async findAll(tenantId: string) {
  return this.prisma.user.findMany({ where: { tenantId } });
}

b) Schema-per-tenant: Each tenant gets their own database schema (Postgres):

public.users
tenant_a.users
tenant_b.users

Switch schemas dynamically at runtime:

await prisma.$executeRawUnsafe(`SET search_path TO ${tenantId}, public`);

This offers stronger isolation but requires connection pooling and migration management (e.g., using pgbouncer + prisma-multi-tenant).

4. Field-Level RBAC: Use middleware or directives to restrict field access depending on tenant role or tier (e.g., “Pro” customers only see analytics fields).

Example with GraphQL Shield

// permissions.ts
import { rule, shield } from 'graphql-shield';

const isProTenant = rule()(async (_parent, _args, ctx) => {
  return ctx.user?.plan === 'pro';
});

export const permissions = shield({
  Query: {
    analyticsReport: isProTenant,
  },
});

GraphQLModule.forRoot({
  schema: applyMiddleware(schema, permissions),
});

For Federation, RBAC can be applied both in subgraphs and at the gateway level for centralized policy enforcement.

Multi-Tenant Federation Flow Summary

                +-------------------+
                |  Apollo Gateway   |
                |-------------------|
                |  Auth + Context   |
                |  Tenant Resolver  |
                +--------+----------+
                         |
             +-----------+------------+
             |                        |
   +---------+----------+   +---------+----------+
   |  Users Subgraph    |   |  Billing Subgraph  |
   |  Scoped by Tenant  |   |  Scoped by Tenant  |
   +--------------------+   +--------------------+
             |
         +---+---+
         | DB per|
         | Tenant|
         +-------+

• Gateway injects tenant ID → shared context
• Subgraphs filter data by tenantId
• Optional: per-tenant schema or DB
• RBAC enforced via middleware or directives

Subgraph Considerations

• Each service must enforce tenant scoping at repository or ORM level.
• Use shared middleware to validate tenant consistency across services.
• Optional: per-tenant caching to improve isolation and performance.

Best Practices & Production Tips

✅ Keep tenant context immutable – don’t reassign or alter it mid-request.
✅ Audit everything – log tenant ID in every service call and DB query.
✅ Cache isolation – partition cache keys with tenant prefixes (tenantId:resource:id).
✅ Metrics separation – tag traces/metrics with tenant_id (for Prometheus/OpenTelemetry).
✅ Schema customization – if offering custom tenant extensions, use @extends or Apollo schema composition.
✅ Automated migrations – use CI/CD tasks to deploy schema/DB migrations per tenant.

9. Cross-Service Caching and DataLoader Integration

In large-scale federated GraphQL systems (multiple services: users, billing, inventory, etc.), cross-service requests often cause N+1 query problems and unnecessary network chatter between subgraphs.

To achieve optimal performance and scalability, you combine DataLoader-based batching and caching (for per-request deduplication) with gateway-level caching (for persistent response and entity caching).

Why This Matters

Without loaders and caching:

• Each resolver triggers separate downstream calls (e.g., for each user or product).
• Federated entity resolution can become network-heavy.
• You lose opportunities to reuse query results or deduplicate calls.
• With a well-designed DataLoader + caching setup:
• Repeated entity lookups (e.g., User references across services) are batched into one request.
• Cached entities are re-used across resolvers during a request.
• Responses or entity results can be persisted in Redis or memory with TTL-based invalidation.

Architecture Overview

                        +---------------------+
                        |   Apollo Gateway    |
                        |---------------------|
                        | - Response Cache    |
                        | - Entity Cache      |
                        | - Per-request ctx   |
                        +----------+----------+
                                   |
                  +----------------+-----------------+
                  |                                  |
       +----------+----------+            +----------+----------+
       |   Users Subgraph    |            |  Orders Subgraph    |
       |---------------------|            |---------------------|
       | - DataLoader layer  |            | - DataLoader layer  |
       | - Redis cache       |            | - Redis cache       |
       +---------------------+            +---------------------+

9.1 Cross-Service DataLoader(per subgraph)

• ach subgraph that references external entities (like User or Product) should define a DataLoader.
  This ensures that all requests for the same entity within a single operation are batched and cached.

Example — orders subgraph fetching User from users subgraph

// loaders/user.loader.ts
import DataLoader from 'dataloader';
import { UserAPI } from '../datasources/user.api';

export function createUserLoader(userAPI: UserAPI) {
  return new DataLoader(async (userIds: readonly string[]) => {
    const users = await userAPI.getUsersByIds(userIds as string[]);
    const userMap = new Map(users.map(u => [u.id, u]));
    return userIds.map(id => userMap.get(id));
  });
}

// context.ts
import { createUserLoader } from './loaders/user.loader';
import { UserAPI } from './datasources/user.api';

export function buildContext() {
  const userAPI = new UserAPI();
  return {
    loaders: {
      userLoader: createUserLoader(userAPI),
    },
  };
}

// order.resolver.ts
@Resolver(() => Order)
export class OrderResolver {
  @ResolveField(() => User)
  async user(@Parent() order: Order, @Context() ctx) {
    return ctx.loaders.userLoader.load(order.userId);
  }
}

✅ Benefit: Within a single GraphQL request, all user lookups are batched into one network call:

{
  orders {
    id
    user { name }
  }
}

→ results in 1 call to users service instead of N calls.

9.2 Gateway-Level Loader Integration

At the Apollo Gateway, you can inject cross-service loaders into the context for shared caching across subgraphs.
This is especially helpful when entity references are resolved across services.

// gateway/index.ts
import { ApolloGateway, IntrospectAndCompose } from '@apollo/gateway';
import { ApolloServer } from '@apollo/server';
import { startStandaloneServer } from '@apollo/server/standalone';
import { RedisCache } from 'apollo-server-cache-redis';
import DataLoader from 'dataloader';
import fetch from 'node-fetch';

const cache = new RedisCache({ host: 'localhost', ttl: 60 });

const gateway = new ApolloGateway({
  supergraphSdl: new IntrospectAndCompose({
    subgraphs: [
      { name: 'users', url: 'http://localhost:4001/graphql' },
      { name: 'orders', url: 'http://localhost:4002/graphql' },
    ],
  }),
});

const userLoader = new DataLoader(async (userIds: readonly string[]) => {
  const response = await fetch('http://localhost:4001/graphql', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({
      query: `query ($ids: [ID!]!) { usersByIds(ids: $ids) { id name } }`,
      variables: { ids: userIds },
    }),
  });
  const { data } = await response.json();
  return userIds.map(id => data.usersByIds.find((u: any) => u.id === id));
});

const server = new ApolloServer({
  gateway,
  cache,
  context: async ({ req }) => ({
    tenantId: req.headers['x-tenant-id'],
    loaders: { userLoader },
  }),
});

✅ Result: Entity references across subgraphs (@key(fields: "id")) reuse the same cached entity resolution via the gateway.

Example — Apollo Gateway Context

• Use DataLoader per request to batch and cache requests.

// loaders/user.loader.ts
import DataLoader from 'dataloader';
export const createUserLoader = (fetchUsers) => new DataLoader(async (ids) => {
    const users = await fetchUsers(ids);
    return ids.map(id => users.find(u => u.id === id) || null);
});

9.3 Caching Strategies

Caching should happen at two levels:

• Gateway (response-level or entity-level caching)
• Subgraph (request-scoped DataLoader caching or Redis persistence)

Let’s break these down 👇

a) Response Caching (Gateway)

You can cache entire GraphQL responses (great for read-heavy queries) using Apollo’s built-in apollo-server-plugin-response-cache or custom Redis cache.

import { ApolloServerPluginResponseCache } from '@apollo/server-plugin-response-cache';

const server = new ApolloServer({
  gateway,
  cache,
  plugins: [
    ApolloServerPluginResponseCache({
      ttl: 30, // 30 seconds cache
      sessionId: (ctx) => ctx.tenantId, // isolate per-tenant cache
    }),
  ],
});

✅ Use case: Cache popular dashboards or reports that don’t change frequently.

b) Entity Caching (Subgraph-Level)

Each DataLoader can store entity lookups in Redis for cross-request reuse.

// user.loader.ts
import DataLoader from 'dataloader';
import Redis from 'ioredis';

const redis = new Redis();

export function createUserLoader(userAPI: UserAPI) {
  return new DataLoader(async (userIds: readonly string[]) => {
    // Try cache first
    const cached = await Promise.all(userIds.map(id => redis.get(`user:${id}`)));
    const missingIds = userIds.filter((_, i) => !cached[i]);
    
    let fetched = [];
    if (missingIds.length > 0) {
      fetched = await userAPI.getUsersByIds(missingIds as string[]);
      for (const user of fetched) {
        redis.set(`user:${user.id}`, JSON.stringify(user), 'EX', 60);
      }
    }

    const allUsers = userIds.map((id, i) => cached[i] ? JSON.parse(cached[i]!) : fetched.find(u => u.id === id));
    return allUsers;
  });
}

✅ Benefit:

• Prevents re-fetching the same user across requests.
• Cache TTL ensures consistency with eventual updates.

C) Cross-Service Redis Cache (Shared Cache Bus)

In federated setups, caches must often be shared across microservices to prevent duplication.
Use Redis as a central cache bus for all entity lookups.

Example topology:

[Apollo Gateway]
       |
   [Redis Cache]
       |
  +----+----+
  |         |
[Users]   [Billing]

• Each service uses the same Redis instance or cluster.
• Keys are namespaced: tenant:user:123, tenant:invoice:456.
• Gateway and subgraphs can share the same cache API.

d)Cache Invalidation Strategies

• TTL-based (simple, safe): expire keys automatically after N seconds.
• Event-based: publish update events to Redis channels (e.g., USER_UPDATED) to invalidate keys in all caches.
• Manual busting: Admin endpoint to clear cache when performing migrations.

e) Combined Pattern — Gateway + DataLoader + Redis

A real-world federated caching stack typically looks like this:

+------------------------+
|     Apollo Gateway     |
|------------------------|
| Response Cache (TTL)   |
| Cross-Service Loaders  |
+-----------+------------+
            |
   +--------+---------+
   |    Redis Cache   |
   +--------+---------+
            |
     +------+------+
     |   Subgraph  |
     | (Users, etc)|
     | DataLoader  |
     +-------------+

Flow example:

• Gateway receives query → checks response cache.
• If not found → uses DataLoader to fetch federated entities.
• Subgraphs use Redis-backed DataLoader to fetch & cache entities.
• Responses are cached per tenant at both levels.

f) Production Tips

✅ Use per-request DataLoader — never reuse across requests (causes data leaks).
✅ Namespace cache keys by tenant ID to prevent cross-tenant pollution.
✅ Monitor cache hit rates with Prometheus/OpenTelemetry.
✅ Use Redis cluster for scale; in-memory cache for ultra-low latency.
✅ For dynamic invalidation, prefer Pub/Sub over manual busting.
✅ Limit cache size and use TTL with jitter (to prevent thundering herd).

10. Security Architecture

• Use DataLoader for N+1 batching.
• Enable Response Caching.
• Use query cost analysis.
• Add a CDN layer (Akamai, Cloudflare) for persisted queries.
• Depth & complexity limits.
• Disable introspection in production.
• Enforce Auth via context (JWT, OAuth, session).
• Use auth directives (@auth) or Nest guards.

import {
    createComplexityLimitRule
} from 'graphql-validation-complexity';
const validationRules = [createComplexityLimitRule(1000)];

directive @auth(role: Role!) on FIELD_DEFINITION

const server = new ApolloServer({
    schema: applyMiddleware(schema, authMiddleware),
});

12. API Governance and Versioning

GraphQL’s power comes from its evolving schema, but in large organizations or federated setups, uncontrolled evolution leads to breaking changes, inconsistent schemas, and deployment chaos.

• API governance ensures:
• ✅ Safe schema evolution
• ✅ Predictable versioning and deprecation
• ✅ Consistency across multiple teams/services
• ✅ Continuous validation during CI/CD

a) Core Concepts

Project Structure

/users-service
 ├── src/
 │   ├── schema.graphql
 │   ├── index.ts
 │   └── apollo.config.js
 ├── package.json
 ├── .env
 └── .github/workflows/schema-check.yml

a) Schema Definition with Deprecation

# src/schema.graphql
type User @key(fields: "id") {
  id: ID!
  name: String!
  email: String! @deprecated(reason: "Use contactEmail instead")
  contactEmail: String!
}

type Query {
  user(id: ID!): User
  users: [User!]!
}

Here we’ve gracefully deprecated the email field and introduced contactEmail.
Existing clients can continue to use email until it’s removed in a later version.

b) Apollo Config for Schema Registry

// apollo.config.js
module.exports = {
  service: {
    name: 'users',
    localSchemaFile: './src/schema.graphql',
  },
};

Apollo key (from Apollo Studio) should be in .env:

APOLLO_KEY=service:my-supergraph-key
APOLLO_GRAPH_REF=my-supergraph@current

c) CI/CD: Schema Governance with GitHub Actions

This pipeline:

• Installs dependencies
• Checks for breaking changes
• Publishes the schema if valid

# .github/workflows/schema-check.yml
name: Validate and Publish GraphQL Schema

on:
  push:
    branches: [main]
  pull_request:
    branches: [main]

jobs:
  schema-validation:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repo
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 18

      - name: Install dependencies
        run: npm ci

      - name: Validate Schema against Registry
        env:
          APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
          APOLLO_GRAPH_REF: my-supergraph@current
        run: npx rover subgraph check my-supergraph@current \
              --name users \
              --schema ./src/schema.graphql

      - name: Publish Schema (only on main)
        if: github.ref == 'refs/heads/main'
        env:
          APOLLO_KEY: ${{ secrets.APOLLO_KEY }}
          APOLLO_GRAPH_REF: my-supergraph@current
        run: npx rover subgraph publish my-supergraph@current \
              --name users \
              --schema ./src/schema.graphql \
              --routing-url https://users-service.prod/graphql

✅ Behavior:

• On pull request → checks schema compatibility (fails CI if breaking changes).
• On main branch → publishes the new version to Apollo Studio registry.
• Registry automatically composes the supergraph and alerts if composition fails.

Schema Compatibility Rules (Validated by Apollo)

Rover (CLI) validates:

• Field removals → ❌ breaking
• Type changes (String → Int) → ❌ breaking
• New fields → ✅ safe
• Deprecated fields → ✅ safe, warns clients

Example output:

Detected one breaking change:
⚠️  Field "User.email" was removed. Clients still use this field.

his protects downstream clients and federated subgraphs from unintentional schema drift.

d) Optional: GraphQL Hive Alternative (Open Source)

If you prefer open source:

npm install -g @graphql-hive/cli
hive schema:check --project users --registry https://hive.mycompany.dev --token $HIVE_TOKEN
hive schema:publish --project users --service-url https://users-service.prod/graphql

Global Governance Lifecycle

  ┌────────────────────────────────────────────┐
  │              Developer Pushes              │
  └───────────────┬────────────────────────────┘
                  │
        1️⃣ Rover CI runs schema check
                  │
        2️⃣ Compares against registry
                  │
        3️⃣ Detects breaking changes
                  │
        4️⃣ Publishes valid schemas
                  │
        5️⃣ Apollo Studio composes supergraph
                  │
        6️⃣ Gateway auto-updates configuration

Best Practices

✅ Always publish schemas through CI, never manually.
✅ Deprecate → Warn → Remove (after 2 release cycles).
✅ Use Schema Linting (graphql-schema-linter) in pre-commit hooks.
✅ Tag every published schema (@staging, @prod) for rollback support.
✅ Generate and publish changelogs from schema diffs.
✅ Monitor schema usage via Apollo Studio Metrics or Hive usage reports.

✅ TL;DR – One Global Flow

• Developer modifies schema → commits PR.
• CI uses Rover/Hive → validates against registry.
• If safe → schema published → supergraph updated.
• Deprecated fields tracked and reported.
• Gateway auto-pulls new supergraph SDL.

13. Pagination, Filtering, Sorting

GraphQL’s flexibility allows clients to define exactly what data they need — but this also means you must carefully design your query patterns, input arguments, and cursor logic to keep APIs efficient, predictable, and secure.

a) A robust backend should support:

b) Exemple

Below is a complete and self-contained implementation showing a production-ready design using NestJS + Apollo + Prisma with cursor-based pagination, filtering, and sorting, all in a single code block.

// src/posts/posts.module.ts
import { Module, Query, Resolver, Args, Field, ObjectType, InputType, registerEnumType } from '@nestjs/graphql';
import { PrismaClient } from '@prisma/client';
import { Injectable } from '@nestjs/common';
import { GraphQLScalarType } from 'graphql';
import { Kind } from 'graphql/language';
import { Buffer } from 'buffer';

// --- ENUMS FOR SORTING ---
export enum SortOrder {
  ASC = 'asc',
  DESC = 'desc',
}
registerEnumType(SortOrder, { name: 'SortOrder' });

// --- CURSOR SCALAR (OPAQUE BASE64 ID) ---
export const CursorScalar = new GraphQLScalarType({
  name: 'Cursor',
  description: 'Opaque Base64-encoded cursor ID',
  serialize(value: string) {
    return Buffer.from(value).toString('base64');
  },
  parseValue(value: string) {
    return Buffer.from(value, 'base64').toString('ascii');
  },
  parseLiteral(ast) {
    return ast.kind === Kind.STRING ? Buffer.from(ast.value, 'base64').toString('ascii') : null;
  },
});

// --- GRAPHQL OBJECT TYPES ---
@ObjectType()
class Post {
  @Field(() => String)
  id: string;

  @Field()
  title: string;

  @Field()
  createdAt: Date;

  @Field()
  authorId: string;
}

@ObjectType()
class PageInfo {
  @Field(() => CursorScalar, { nullable: true })
  endCursor?: string;

  @Field(() => Boolean)
  hasNextPage: boolean;
}

@ObjectType()
class PostConnection {
  @Field(() => [Post])
  edges: Post[];

  @Field(() => PageInfo)
  pageInfo: PageInfo;
}

// --- INPUT TYPES FOR FILTERING & SORTING ---
@InputType()
class PostFilterInput {
  @Field({ nullable: true })
  titleContains?: string;

  @Field({ nullable: true })
  authorId?: string;

  @Field({ nullable: true })
  createdAfter?: Date;

  @Field({ nullable: true })
  createdBefore?: Date;
}

@InputType()
class PostSortInput {
  @Field(() => String)
  field: keyof Post;

  @Field(() => SortOrder)
  order: SortOrder;
}

// --- SERVICE LAYER ---
@Injectable()
class PostService {
  private prisma = new PrismaClient();

  async findManyPaginated(args: {
    first?: number;
    after?: string;
    filters?: PostFilterInput;
    sort?: PostSortInput;
  }) {
    const take = args.first ?? 10;

    const where: any = {};
    if (args.filters?.titleContains) where.title = { contains: args.filters.titleContains };
    if (args.filters?.authorId) where.authorId = args.filters.authorId;
    if (args.filters?.createdAfter || args.filters?.createdBefore)
      where.createdAt = {
        ...(args.filters.createdAfter && { gte: args.filters.createdAfter }),
        ...(args.filters.createdBefore && { lte: args.filters.createdBefore }),
      };

    const orderBy = args.sort
      ? { [args.sort.field]: args.sort.order }
      : { createdAt: 'desc' };

    const cursor = args.after ? { id: args.after } : undefined;

    const items = await this.prisma.post.findMany({
      take: take + 1, // fetch one extra for hasNextPage
      where,
      orderBy,
      ...(cursor && { skip: 1, cursor }),
    });

    const hasNextPage = items.length > take;
    const edges = hasNextPage ? items.slice(0, -1) : items;
    const endCursor = edges.length > 0 ? edges[edges.length - 1].id : null;

    return {
      edges,
      pageInfo: {
        endCursor,
        hasNextPage,
      },
    };
  }
}

// --- RESOLVER ---
@Resolver(() => Post)
class PostResolver {
  constructor(private readonly postService: PostService) {}

  @Query(() => PostConnection)
  async posts(
    @Args('first', { type: () => Number, nullable: true }) first: number,
    @Args('after', { type: () => CursorScalar, nullable: true }) after?: string,
    @Args('filters', { type: () => PostFilterInput, nullable: true }) filters?: PostFilterInput,
    @Args('sort', { type: () => PostSortInput, nullable: true }) sort?: PostSortInput,
  ): Promise<PostConnection> {
    return this.postService.findManyPaginated({ first, after, filters, sort });
  }
}

// --- MODULE EXPORT ---
@Module({
  providers: [PostResolver, PostService],
})
export class PostsModule {}

c) Explanation of Key Concepts

d) Example Query

query {
  posts(
    first: 5
    after: "QmFzZTY0Q3Vyc29ySWQxMjM="
    filters: { titleContains: "GraphQL", createdAfter: "2025-01-01" }
    sort: { field: "createdAt", order: DESC }
  ) {
    edges {
      id
      title
      createdAt
    }
    pageInfo {
      endCursor
      hasNextPage
    }
  }
}

Production Best Practices

✅ Use opaque cursors (never expose numeric offsets).
✅ Always enforce pagination limits (e.g., max: 100).
✅ Index fields used in sorting or filtering.
✅ Avoid offset pagination for large datasets (unstable under concurrent writes).
✅ Implement totalCount via cached count queries if needed.
✅ Combine with DataLoader to batch entity lookups per page.

14. Subscriptions and Real-time GraphQL

a) Overview

GraphQL Subscriptions allow clients to receive live updates whenever data changes, using WebSockets or other persistent transports.
They’re essential for use cases like:

• Live dashboards and metrics
• Chat and notifications
• Collaborative document editing
• Realtime feed updates (posts, likes, etc.)
• In production, a robust setup requires:

b) Example (NestJS + Apollo Server + Redis PubSub)

The following single code block shows a complete production-ready setup with:

• GraphQL subscription for postCreated
• Redis PubSub for cross-instance broadcasting
• Auth-aware WebSocket context
• Dynamic filtering by tenant/user
• Integration into NestJS GraphQL module

// src/posts/posts.module.ts
import { Module, Resolver, Query, Mutation, Args, Subscription, ObjectType, Field, InputType } from '@nestjs/graphql';
import { Injectable } from '@nestjs/common';
import { PubSub } from 'graphql-subscriptions';
import Redis from 'ioredis';
import { RedisPubSub } from 'graphql-redis-subscriptions';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloDriver, ApolloDriverConfig } from '@nestjs/apollo';
import { ApolloServerPluginLandingPageLocalDefault } from '@apollo/server/plugin/landingPage/default';
import { ExecutionContext } from '@nestjs/common';
import { GqlExecutionContext } from '@nestjs/graphql';

// --- REDIS PUBSUB CONFIG ---
const pubSub = new RedisPubSub({
  publisher: new Redis({ host: 'localhost', port: 6379 }),
  subscriber: new Redis({ host: 'localhost', port: 6379 }),
});

// --- GRAPHQL TYPES ---
@ObjectType()
class Post {
  @Field()
  id: string;

  @Field()
  title: string;

  @Field()
  content: string;

  @Field()
  authorId: string;

  @Field()
  createdAt: Date;
}

@InputType()
class CreatePostInput {
  @Field()
  title: string;

  @Field()
  content: string;
}

// --- SERVICE LAYER ---
@Injectable()
class PostService {
  private posts: Post[] = [];

  async createPost(data: CreatePostInput, userId: string): Promise<Post> {
    const newPost: Post = {
      id: `${this.posts.length + 1}`,
      title: data.title,
      content: data.content,
      authorId: userId,
      createdAt: new Date(),
    };
    this.posts.push(newPost);

    // Publish event for subscribers
    await pubSub.publish('postCreated', { postCreated: newPost });
    return newPost;
  }

  async findAll(): Promise<Post[]> {
    return this.posts;
  }
}

// --- RESOLVER ---
@Resolver(() => Post)
class PostResolver {
  constructor(private readonly postService: PostService) {}

  @Query(() => [Post])
  async posts() {
    return this.postService.findAll();
  }

  @Mutation(() => Post)
  async createPost(
    @Args('data') data: CreatePostInput,
    @Args('userId') userId: string,
  ) {
    return this.postService.createPost(data, userId);
  }

  @Subscription(() => Post, {
    filter: (payload, variables, context) => {
      // Example: filter events only for posts authored by user
      return payload.postCreated.authorId === context.user?.id;
    },
    resolve: (value) => value.postCreated,
  })
  postCreated() {
    return pubSub.asyncIterator('postCreated');
  }
}

// --- GRAPHQL MODULE ---
@Module({
  imports: [
    GraphQLModule.forRoot<ApolloDriverConfig>({
      driver: ApolloDriver,
      autoSchemaFile: true,
      playground: false,
      plugins: [ApolloServerPluginLandingPageLocalDefault()],
      subscriptions: {
        'graphql-ws': {
          onConnect: async (ctx) => {
            const token = ctx.connectionParams?.authorization || null;
            // Verify token (mocked example)
            const user = token ? { id: 'user-123', name: 'John Doe' } : null;
            return { user };
          },
        },
      },
      context: ({ req, extra }) => {
        // Context for both HTTP and WS
        if (extra && extra.user) return { user: extra.user };
        const auth = req?.headers?.authorization;
        return { user: auth ? { id: 'user-123', name: 'John Doe' } : null };
      },
    }),
  ],
  providers: [PostResolver, PostService],
})
export class PostsModule {}

c) Explanation

d) Example  Operations

Subscribe

subscription {
  postCreated {
    id
    title
    authorId
    createdAt
  }
}

Mutate (to trigger event)

mutation {
  createPost(data: { title: "Hello Subscriptions", content: "GraphQL Rocks!" }, userId: "user-123") {
    id
    title
  }
}

e) Production Best Practices

✅ Use Redis or Kafka for distributed pub/sub scaling.
✅ Authenticate and authorize WebSocket connections securely.
✅ Limit subscription count per user to prevent DoS.
✅ Apply TTL and message filtering for event performance.
✅ Use dedicated gateway or subscription service under load.
✅ Integrate metrics & tracing with OpenTelemetry for monitoring.

15. Testing Strategy

• Unit: Test services.
• Integration: Run resolvers with in-memory schema.
• E2E: Test full API + DB.
• Contract: Validate schema compatibility.

16. Observability

• Use OpenTelemetry instrumentation.
• Add tracing IDs in logs.
• Expose Prometheus metrics: latency per resolver.

17 — Example CI/CD Pipeline for Federated GraphQL

Goals

• Automate build, test, and deploy for gateway and subgraphs.
• Validate schema compatibility before deployment.
• Ensure rollback in case of failed federation compatibility.

Example (GitHub Actions)

name: Federated GraphQL CI / CD

on:
    push:
    branches: [main]

jobs:
    test:
    runs - on: ubuntu - latest
strategy:
    matrix:
    service: [users, posts, comments]
steps:
    -uses: actions / checkout @v3 -
    name: Set up Node
uses: actions / setup - node @v3
with:
    node - version: '18' -
    run: npm ci -
    run: npm run test


validate - schema:
    runs - on: ubuntu - latest
needs: test
steps:
    -uses: actions / checkout @v3 -
    name: Validate Federation
run: |
    npx apollo service: check--endpoint = http: //gateway:4000/graphql


    deploy:
    runs - on: ubuntu - latest
needs: [test, validate - schema]
steps:
    -uses: actions / checkout @v3 -
    name: Build and Deploy Users Service
run: |
    docker build - t users - service. / services / users
docker push myregistry / users - service: latest
kubectl apply - f k8s / users - deployment.yaml -
    name: Deploy Gateway
run: |
    docker build - t gateway. / gateway
docker push myregistry / gateway: latest
kubectl apply - f k8s / gateway - deployment.yaml

Notes

• Schema validation ensures federation compatibility across services.
• Deploy subgraphs independently; gateway deploy last or with rolling updates.
• Rollback on schema validation failure prevents breaking clients.

18. Deployment Strategies

• Apollo Gateway in Kubernetes.
• Federation services as independent pods.
• Use horizontal pod autoscaling.
• Cache persisted queries at CDN level.

19. Developer Experience

• GraphQL Code Generator → type safety.
• ESLint + Prettier + Husky.
• Doc generation via GraphQL Voyager or GraphiQL Explorer.

20. Error Handling & Logging

• Standardize error codes.
• Hide internal errors in production.
• Log context and userId.

21. Performance Benchmarks

Use tools like Apollo studio, graphql-bench and Artillery.

23. Production Checklist

✅ Schema registry + versioning
✅ Query complexity limits
✅ Dataloader cache
✅ Persisted queries
✅ Structured logging
✅ Observability stack
✅ CI/CD validation

24. Tools & Resources

• Apollo Server: A spec-compliant GraphQL server compatible with any GraphQL client, including Apollo Client. It's a production-ready solution for building self-documenting GraphQL APIs that can use data from any source. apollographql.com
• Apollo Federation: An architecture for declaratively composing APIs into a unified graph. Each team can own their slice of the graph independently, empowering them to deliver autonomously and incrementally. apollographql.com
• Apollo Gateway: The gateway sits in front of subgraphs, executing operations across them. It processes the supergraph schema and creates query plans for incoming requests. apollographql.com
• NestJS GraphQL: A progressive Node.js framework that provides a simple and flexible way to build GraphQL APIs using the @nestjs/graphql module. docs.nestjs.com

Data Access & ORM

Prisma: A next-generation Node.js and TypeScript ORM for PostgreSQL, MySQL, SQL Server, SQLite, MongoDB, and CockroachDB. It provides type-safety, auto-completion, and a powerful query engine. Prisma

TypeORM: An ORM for TypeScript and JavaScript that supports MySQL, PostgreSQL, MariaDB, SQLite, MS SQL Server, Oracle, SAP Hana, and WebSQL databases. Works in NodeJS, Browser, Ionic, Cordova, and Electron platforms. typeorm.io

MikroORM: A TypeScript ORM for Node.js based on Data Mapper, Unit of Work, and Identity Map patterns. mikro-orm.io

Developer Tools

GraphQL Code Generator: A plugin-based tool that helps you get the best out of your GraphQL stack. From back-end to front-end, it automates the generation of typed Queries, Mutations, and Subscriptions for React, Vue, Angular, Next.js, Svelte, whether you are using Apollo Client, URQL, or React Query. The Guild

GraphQL Shield: A library for creating permission layers for your GraphQL schema using a functional approach.

GraphQL Depth Limit: A middleware for limiting the depth of queries to prevent malicious or accidental deep queries.

GraphQL Query Complexity: A utility to calculate the complexity of a GraphQL query to prevent overly expensive operations.

Observability & Monitoring

OpenTelemetry: An open-source project that provides APIs, libraries, agents, and instrumentation to enable observability for applications.

Prometheus: An open-source system monitoring and alerting toolkit designed for reliability and scalability.

Jaeger: An open-source, end-to-end distributed tracing system.

Integration & Ecosystem

GraphQL Mesh: A tool that allows you to access any data source as GraphQL, including REST APIs, SOAP, gRPC, and more.

Apollo Studio: A platform for building, testing, and managing GraphQL APIs.

GraphQL is a query language for API created by Facebook in 2012 and open-sourced in 2015. It provides a set of features that allows building Back-end and a very optimized way for Data fetching. According to https://graphql.org GraphQL provides a complete and understandable description of the data in your API, gives clients the power to ask for exactly what they need and nothing more, makes it easier to evolve APIs over time, and enables powerful developer tools.

To do this, GraphQL is centered around an element called The GraphQL Schema which is the Contract between the Back-end service and the Front-end on how to consume the service and what can be served by the service.

As you will have understood, everything goes through this GraphQL schema. 😉 Now this being said, let's see what are the different ways to build it

As a backend developer, I sometimes had to wonder which approach to adopt when I had to build a GraphQL Backend. When I started working on GraphQL, I used to work with the standard way to do this task, what is called the "Schema-first" approach where the GraphQL Schema defining type, fields, resolvers function, and relationships between data are defined first to say which fields can be exposed by the service and which functions resolvers can be called to ask for those fields and which parameters are required by each resolver.

On the other hand, this approach is not the only way to build a GraphQL service since the "Code-first" approach can be another way to build a GraphQL API. In this way, you only need to write the resolvers function needed to serve a specific need with some annotations, and a build tool will compile the schema and the SDL based on types and provided annotations. We will dive deeper into it later. let's jump into each approach now.

1. Schema-first

This way of building GraphQL services has been the only way to build a GraphQL backend at the beginning and it is based on a simple concept, the "Contract" ☝️

The "Contract" here represents an agreement between the Front-end and the Back-end on how Data are defined (field names, resolvers functions, available fields, etc ..) and how all the Frontend can consume those Data. This way, Front-end developers can work asynchronously when the GraphQL schema is ready. To do so, we use the SDL (Schema Définition Language) to define the schema and then create all the resolver functions that execute and return data at runtime. Therefore, the GraphQL schema is like a Blueprint of a GraphQL API.

type Query {
  welcome: String!
  users: [User!]!
}
  
type User {
 _id: ID!
 firstName: String!
 lastName: String!
 email:	String!
}

This pattern is used by many popular GraphQL servers. let's see this with a real example. To see this in the real world, let's build a simple service using Apollo Server and Typescript. Let's follow the same approach as shown on their website

Step 1: Create a new project

Open your favorite terminal and create a folder

mkdir demo-schema-first 
cd demo-schema-first

then run the following commands yarn init --yes to initialize a node.js project using Yarn as a package manager. this will create a package.json

Step 2: Install dependencies

• yarn add @apollo/server graphql to install useful packages
• yarn add -D typescript nodemon @types/node to install typescript and corresponding types
• Now run touch tsconfig.json to create a tsconfig.json and paste the following code into

{
  "compilerOptions": {
    "rootDirs": ["src"],
    "outDir": "dist",
    "lib": ["es2020"],
    "target": "es2020",
    "module": "esnext",
    "moduleResolution": "node",
    "esModuleInterop": true,
    "types": ["node"]
  }
}

Add the following in your pakage.json

"type": "module", 
"scripts": {
   "compile": "tsc",
   "start": "npm run compile && nodemon ./dist/index.js"
  }

Our package.json will look like this

{
  "name": "demo-schema-first",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "type": "module",
  "scripts": {
    "compile": "tsc",
    "start": "npm run compile && node ./dist/index.js"
  },
  "dependencies": {
    "@apollo/server": "^4.3.0",
    "graphql": "^16.6.0"
  },
  "devDependencies": {
    "@types/node": "^18.11.18",
    "ts-node": "^10.9.1",
    "typescript": "^4.9.4"
  }
}

Create a src folder with

mkdir src
touch src/index.ts

and paste the following to bootstrap a basic Apollo Server

import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from "@apollo/server/standalone";

const typeDefs = `
  type Book {
	id:ID!
    title: String
    author: String
  }

  type Query {
    books: [Book]
  }
`;

const books = [
  {
    id:1,
    title: "The Awakening",
    author: "Kate Chopin",
  },
  {
    id:2,
    title: "City of Glass",
    author: "Paul Auster",
  },
];

const resolvers = {
  Query: {
    books: () => books,
  },
};

const server = new ApolloServer({
  typeDefs, // IMPORTANT
  resolvers, // IMPORTANT
});

const { url } = await startStandaloneServer(server, {
  listen: { port: 4000 },
});

console.log(`🚀  Server ready at: ${url}`);

On the terminal, run the command yarn start and you will have the following output when you open http:localhost:4000 and execute the query to get all books

In this example, there is something very important to mention. The way the Apollo Server is created. We first define the schema using SDL syntax, define the corresponding resolvers, and pass both to the ApolloServer constructor.

However, the downside to a schema-first approach is that the resolver functions must match the schema exactly. Since developers need to write the schema and resolvers separately, this becomes a challenge for very large APIs with thousands of lines.

To this day, this approach does work, but it requires a lot of workarounds and tools to help keep the code clean and inconsistencies to a minimum.

2. Code-first

As described previously, the code-first approach focuses on writing resolvers functions and annotations, then a build tool will compile the schema and the SDL based on types and provided annotations and generate a GraphQL schema based on resolvers types. This approach can speed up the development process since there is no need to check each time that the resolvers match any schema.

To work with the code-first approach, you will need some third-party libraries like tpegraphql or Nexus. Let's build a GraphQL API from our previous example using TypeGraphQL

1. Create a new project

Open your favorite terminal and create a folder with

mkdir demo-code-first 
cd demo-code-first

then run the following commands

• yarn init --yes to initialize a node.js project using Yarn as a package manager. this will create a package.json and add the following

 "scripts": {
   "compile": "tsc",
   "start": "npm run compile && nodemon ./src/index.ts"
  }

2. Install dependencies

• yarn add -D typescript ts-node nodemon @types/node to install typescript and corresponding types
•  yarn add @apollo/server typedi class-validator reflect-metadata graphql@15.8.0 type-graphql@2.0.0-beta.1 which are dependencies required for our use case.

Note: Since we are working with Apollo server v4, we use type-graphql version 2.0.0-beta.1 to avoid errors since Apollo Server V4.0 has "Dropped support for versions of the GraphQL library prior to v16.6.0". You can have a look at the issue here 👉 on GitHub for more details

Our package.json look like this

{
  "name": "demo-code-first",
  "version": "1.0.0",
  "main": "index.js",
  "license": "MIT",
  "scripts": {
    "compile": "tsc",
    "start": "yarn compile && nodemon ./src/index.ts"
  },
  "dependencies": {
    "@apollo/server": "^4.3.0",
    "class-validator": "^0.14.0",
    "graphql": "^16.6.0",
    "reflect-metadata": "^0.1.13",
    "type-graphql": "2.0.0-beta.1",
    "typedi": "^0.10.0"
  },
  "devDependencies": {
    "@types/node": "^18.11.18",
    "ts-node": "^10.9.1",
    "typescript": "^4.9.4"
  }
}

Create a src folder with

mkdir src
touch src/index.ts

and paste the following to bootstrap a basic Apollo Server

We must ensure that it is imported at the top of our entry file (before we use/import type-graphql or our resolvers):

import "reflect-metadata";

3.TypeScript configuration

It's important to set these options in the tsconfig.json file of our project:

{
  "emitDecoratorMetadata": true,
  "experimentalDecorators": true
}

TypeGraphQL is designed to work with Node.js LTS (10.3+, 12+) and the latest stable releases. It uses features from ES2018 so we should set our tsconfig.json file appropriately:

{
  "target": "es2018" // or newer if your node.js version supports this
}

Due to using the graphql-subscription dependency that relies on an AsyncIterator, we may also have to provide the esnext.asynciterable to the lib option:

{
  "lib": ["es2018", "esnext.asynciterable"]
}

All in all, the minimal tsconfig.json file example looks like this:

{
  "compilerOptions": {
    "target": "es2018",
    "module": "commonjs",
    "outDir": "dist",
    "esModuleInterop": true,
    "lib": ["es2018", "esnext.asynciterable"],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

4.TypeScript configuration

It's important to set these options in the tsconfig.json file of our project:

{
  "emitDecoratorMetadata": true,
  "experimentalDecorators": true
}

TypeGraphQL is designed to work with Node.js LTS (10.3+, 12+) and the latest stable releases. It uses features from ES2018 so we should set our tsconfig.json file appropriately:

{
  "target": "es2018" // or newer if your node.js version supports this
}

Due to using the graphql-subscription dependency that relies on an AsyncIterator, we may also have to provide the esnext.asynciterable to the lib option:

{
  "lib": ["es2018", "esnext.asynciterable"]
}

All in all, the minimal tsconfig.json file example looks like this:

{
  "compilerOptions": {
    "target": "es2018",
    "module": "commonjs",
    "lib": ["es2018", "esnext.asynciterable"],
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

Let's create our server. First, create the following files inside srcfolder

• book.ts

import { Field, ID, ObjectType } from "type-graphql";

@ObjectType()
export class Book {
  @Field((type) => ID)
  id: number;

  @Field()
  title: string;

  @Field()
  author: string;

  constructor(id: number, title: string, author: string) {
    this.title = title;
    this.author = author;
    this.id = id;
  }
}

• bookResolver.ts

import { Arg, Query, Resolver } from "type-graphql";
import { Book } from "./book";
import { BookService } from "./bookService";
import { Container } from "typedi";

@Resolver((of) => Book)
export class BookResolver {
  constructor(private bookService: BookService) {}

  @Query((returns) => [Book])
  async books() {
    return Container.get(BookService).getBooks();
  }

  @Query((returns) => Book)
  async book(@Arg("id") id: number) {
    return Container.get(BookService).getBook(id);
  }
}

• bookService.ts thas will behave like our layer between resolvers and Database where we fetch data

import { Service } from "typedi";
import { Book } from "./book";

@Service()
export class BookService {
  books = [
    {
      id: 1,
      title: "The Awakening",
      author: "Kate Chopin",
    },
    {
      id: 2,
      title: "City of Glass",
      author: "Paul Auster",
    },
  ];
  getBooks = (): Book[] => {
    return this.books;
  };

  getBook = (id: number): Book => {
    return this.books.find((book) => book.id === id);
  };
}

• index.ts

import "reflect-metadata";
import { ApolloServer } from "@apollo/server";
import { startStandaloneServer } from "@apollo/server/standalone";
import { buildSchema } from "type-graphql";
import { BookResolver } from "./bookResolver";
import * as path from "path";

const bootstrap = async () => {
  const schema = await buildSchema({
    resolvers: [BookResolver],
    emitSchemaFile: path.resolve(__dirname, "schema.gql"),
  });
  const server = new ApolloServer({ schema });

  const { url } = await startStandaloneServer(server, {
    listen: { port: 4000 },
  });

  console.log(`🚀  Server ready at: ${url}`);
};

bootstrap();

On the terminal, run the command yarn start and you will have the following output when you open http:localhost:4000 and execute the query to get all books

This will output the exact same result as the previous approach using schema first.

Note. Something important to mention is this line on our index.ts file

const schema = await buildSchema({
    resolvers: [BookResolver],
    emitSchemaFile: path.resolve(__dirname, "schema.gql"), /// THIS LINE
  });

With this option, we tell our server to output the schema file at the root of our src folder. If we take a look at the root folder, we will see a  schema.gql file which contains the blueprint of our Graphql API.

3. Conclusion

There are always pros and cons to everything. In my opinion, you should choose the one that is good for you and which you are comfortable with.  I can also say that the schema-first approach is good for people who just started working with graphql since you will understand if it is the ideal way for you to develop Apis and is the most popular way on the market. However, if you find that over time, it becomes difficult to keep up with the complexity of the project, you can learn Code-first.

• The code source for code-first is available here
• The code source for schema-first is available here

Thanks for reading 😉

Follow me on social media to stay up to date with latest posts.

In the previous post, we covered the Part 1 of this series. We focused on creating a github repository and configured Github Actions to host a docker image of a NestJS backend. In this post, we will see how to update our Github actions workflow to deploy the image to Heroku.

1.  Create Heroku App

As described in the previous post, Heroku is a platform as a service (PaaS) that enables developers to build, run, and operate applications entirely in the cloud. We will host our NestJS Backend here. To do this, go to https://signup.heroku.com/ to create a free Heroku account. Once done, you will access the dashboard.

Click on New -> Create new app

set the app name, then choose the region and then hit the Create app button.

Get an HEROKU_API_KEY for Github Actions. On the dashboard, Go to Account settings -> API Key. Then click on Reveal Button at the right to display your API Key.

Copy this Key as HEROKU_API_KEY on Github Actions secrets as described on the previous post. You will also need to set HEROKU_APP_NAME (the name of the heroku app) and HEROKU_EMAIL (the email you used to create your heroku account). Our secrets now are the following.

Now, lets update the Github Actions workflow. Open .github/workflows/main.yml and update as follow.  

name: NestJS-Backend:CI

on:
  push:
    branches: ['master']

jobs:
  build:
    name: 'Build Image'
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-west-2

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{secrets.ECR_REPOSITORY}}
          IMAGE_TAG: ${{github.sha}}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

      - name: Logout to Amazon ECR
        if: always()
        run: docker logout ${{steps.login-ecr.outputs.registry}}

deploy: ## <= ADDED
    if: ${{ github.ref == 'refs/heads/master' }}
    needs: [build]
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: akhileshns/heroku-deploy@v3.12.12
        with:
          heroku_api_key: ${{secrets.HEROKU_API_KEY}}
          heroku_app_name: ${{secrets.HEROKU_APP_NAME}}
          heroku_email: ${{secrets.HEROKU_EMAIL}}
          remote_branch: master

Then push it on github. The following will be displayed

and you will see the following at the end of the deploy

Now let's see what's happening on Heroku.

If we click on the logs of the heroku app on the dashboard here  

we can see the following output.

We have an error message Process exited with status 127 because of a not found command. This command is the one to start the NestJS app, to fix this issue, we need to update the package.json file and replace the start script from nest start to node dist/main as follow:

"scripts":{
    ..
    "start":"node dist/main" 
}

then stage and push this on github. After all the github actions Jobs, we will see the following on the Heroku Logs

Our app is now running properly on Heroku but we still have one issue to fix to be able to Run some http request on our NestJS app.

if we click on the Open app button at the top, heroku will try to open our app at `https://nestjs-heroku-docker.herokuapp.com/` but we will see the following error

Why do we get this error ? let's see the logs output

We have this error Error R10 (Boot timeout) -> Web process failed to bind to $PORT within 60 seconds of launch. What does it means ?

The answer is simple. Each time you deploy on app on Heroku, Heroku will bind your app to a random port and will set this port to environment variable with the name PORT. So the correct way to make your app listen to this port is by using process.env.PORT . Let's update the main.ts file of our app.

..
async function bootstrap() {
  const app = await NestFactory.create(AppModule);
  await app.listen(process.env.PORT || 3000);
}
bootstrap();

Now stage everything and push to github. Our app build and deploy success fully. To test it open https://nestjs-heroku-docker.herokuapp.com/ and you will see the Hello World ! message printed.

In the next posts we will for sure dive more deeper into NestJS and see how to create a Robust GraphQL backend with.

Thanks for reading. The source code is available here.

Follow me on socials media to stay up to date with latest posts.

Hey guys 🤚, Glad to have you here! In this post we are going to cover how to configure github actions with docker to deploy a Node.js backend.

To complete this post, you need to have to have:

• A Github account
• A AWS account
• A Heroku account
• Basics knowledge of Node.js and Javascript
• Basic Understanding of Docker

We will divide this post in 4 parts.

• Part 1 : Create a basic NestJS backend, create and configure Github  Actions and Amazon ECR to deploy a docker image of our NestJS backend
• Part 2 : Update the Github Actions workflow to pull image from Amazon ECR and deploy it to Heroku

1. Our tools

Some key concepts we are going to cover here in this post:

• CI/CD: those two expressions stands for Continuous integration (CI) and continuous delivery (CD). They represents a coding philosophy and set of practices that drive development teams to frequently implement and deliver small code changes and check them in to a version control repository.
• Github Actions: according to https://resources.github.com/, GitHub Actions gives developers the ability to automate their workflows across issues, pull requests, and more—plus native CI/CD functionality
• Heroku: Heroku is a cloud application platform that makes it easy to both develop and deploy web applications in a variety of languages.
• Docker : is an open source platform for building, deploying, and managing containerized applications.
• NestJS : is a progressive Node.js framework for building efficient, reliable and scalable server-side applications
• Amazon ECR: Amazon Elastic Container Registry (Amazon ECR) is an Amazon Web Service (AWS) product that stores, manages and deploys Docker images, which are managed clusters of Amazon EC2 instances

With this brief introduction our the main tools we are going to use, let's start.

1. Create a NestJS Application

to start working with the Nestjs framework, we need to install the Nestjs CLI. Open your favorite terminal and run the following command

npm install -g @nestjs/cli

This will install NestJS cli globally. Now we can creaate a new NestJS project. run the following command on the terminal

nest new nestjs-docker-heroku

The new command initialise a new nestjs project with the given name. After running this command, nest will ask you wich package manager you want to use. You can choose npm or yarn i'm going to use Yarn . If you have an error while installing depencies with yarn, run the following command npm i -g yarn and then retry the nest new xxx command.

At the end o the install process, you will see the following message

🚀  Successfully created project nestjs-docker-heroku
👉  Get started with the following commands:

$ cd nestjs-docker-heroku
$ yarn run start

The basic setup of our nestJS project expose a unique endpoint / which display an Hello World! message at http://localhost:3000

Now we have a basic NestJS backend. Let's  consider our backend only expose this basic endpoint. Let's create a github repository.

2. Prepare a Github Repo

Create a git repository here  and link to the newly created project. If you don't have a github account, sign up here.

Go to github and get the repository url. We will set this url as the github url origin of our newly created nestJS project.

Copy the repository url and go to the root of your project to run the following.

git remote add origin https://github.com/Doha26/nestjs-docker-heroku.git

Add all our project files to version control and push it to the github repo. To do this, run the following:

git add . // To stage all files

git commit -am "initial setup" // commit our files

git push -u origin master // Push everything to github

3.  Create a Docker file for the NestJS app

Now that we have our Back-End API app up and running, let's containerize it using Docker.

Start by creating a Dockerfile named Dockerfile file in the project's root directory with the following content:

FROM node:lts-alpine as build

WORKDIR /usr/src/app

COPY package.json yarn.lock ./

RUN yarn 

COPY . .

# Build
RUN yarn build

### Build production image

FROM node:lts-alpine as prod

WORKDIR /usr/src/app

COPY --from=build /usr/src/app/dist ./dist
COPY --from=build /usr/src/app/package.json ./
COPY --from=build /usr/src/app/yarn.lock ./

EXPOSE 3000

RUN yarn install --frozen-lockfile --production

CMD ["node", "dist/main"]

In this single Docker file, we create an image from existing Node image node:lts-alpine that will be pulled from docker hub.

Test the docker image locally

We can build and run our docker container locally to see if it works as expected. Open the command line and run the following at the root of the project.

docker build -t nestjs-docker-heroku .

Once this complete successfully, run it in detached mode with the following command and bind the port 3000 of our container to port 4000 on our localhost

docker run -d -p4000:3000 nestjs-docker-heroku

If you open you go to http://localhost:4000  you will see the message Hello World!  that is displayed when you access the /route.

With  all this set, let's  go to the next step.

5.  Configuring Amazon ECR

Go to AWS Management console and login. Once connected, search for ECR in the search area and then choose Elastic Container Registry. On the next screen choose private and then set a repository name in the given input as follow

Note ☝️ : We used the same name nestjs-docker-heroku that we use for ECR_REPOSITORY in our workflow file main.yml

Once created, we have our repository created

AWS Region

An important point to note is the AWS region where the repository is hosted. if we take a look at the repository URI we have the following. xxxxxxxx.dkr.ecr.us-west-2.amazonaws.com/nestjs-docker-heroku. In this URI the AWS Region is us-west-2. You can see it on your management console next to your Account name on the top menu bar.

We will use this same region in our Github Actions workflow file.

Since we have to deploy the docker image to ECR. So, we have to reference some AWS secrets in the GitHub Actions workflow. These secrets are  AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY  and they should be present in “repository secrets”. To do so, go to your AWS Account, click on your name at the top right then choose Security credentials.

On the screen that appear, click on Access keys (access key ID and secret access key) dropdown and click on Create new Access key , a popup will open and here, click on Show Access key and you will see both keys.

5.  Configuring Github Actions

Github actions as described previously is a tool that will provide us with configurable workflow that will host Jobs that will be executed concurrently as well as sequentially  every time we push some code changes on the master branch of our repository. A job A job is a set of steps in a workflow that execute on the same runner. Each step is either a shell script that will be executed, or an action that will be run. For our use case, our jobs will do the following :

• Use the Dockerfile of our NestJS app to build a Docker image and push it to AWS ECR, An Amazon Container Registry.
• Pull the image from AWS ECR to deploy it to Heroku

Workflow in GitHub Actions

• A Workflow is a process that consists of one or multiple jobs.
• Workflow gets triggered by an event or manually.
• An event is a specific activity in a repository that triggers a workflow run. E.g- When someone creates a pull request or pushes a commit to a repository.
• Workflows use a YAML syntax and are present in the .github/workflows directory in your repository.

Creating a Workflow

Let’s create a workflow to deploy the docker image to the ECR repository. Go to your Github repository and click on the Actions menu. In the  page that appear, click on set up a workflow yourself ->

You will see the following

Keep the default settings and click start commit to commit the file with the default main.yml name. The workfow file is not added to your repository. With this changes on the remote repository, we need to sync it with your local repository. Make a git pull to fetch remotes changes on your local repository. Now on your project root folder your will be able to see a .github folder with a main.yml inside. We are going to update this main.yml with the following

name: NestJS-Backend:CI

on:
  push:
    branches: ['master']

jobs:
  build:
    name: 'Build Image'
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: Configure AWS Credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY_ID }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
          aws-region: us-west-2

      - name: Login to Amazon ECR
        id: login-ecr
        uses: aws-actions/amazon-ecr-login@v1

      - name: Build, tag, and push image to Amazon ECR
        env:
          ECR_REGISTRY: ${{ steps.login-ecr.outputs.registry }}
          ECR_REPOSITORY: ${{secrets.ECR_REPOSITORY}}
          IMAGE_TAG: ${{github.sha}}
        run: |
          docker build -t $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG .
          docker push $ECR_REGISTRY/$ECR_REPOSITORY:$IMAGE_TAG

      - name: Logout to Amazon ECR
        if: always()
        run: docker logout ${{steps.login-ecr.outputs.registry}}

Let's explain the content of this file.

• name  This is just the name of our Action
• on push branches master the action will be triggered each time with push on branch master or when a pull request is created to be merged on master
• env Some environment variable the workflow will use to run jobs.
• jobs | build | runs-on this tell the workflow to create a Ubuntu remote environment to run and build the image
• Chekout Log in to the Remote Machine via SSH using the pre-written workflow by Official GitHub Actions i.e Checkout. It simply checks out our GitHub repository for Dockerfile to build the docker image
• Configure AWS Credentials Setting up AWS CLI/SDK on Remote Host and Configuring AWS Login Credentials and Assuming Roles using the pre-written workflow by Official AWS Teams i.e Configure AWS Credentials. For accessing the AWS ECR we need to define a custom Role in later steps.
• Login to Amazon ECR Use AWS/CLI Sdk to login to Amazon ECR
• Build, tag, and push image to Amazon ECR Building the Docker Image by  using the Dockerfile at the root of the repository, Tagging the Image with a version, and Pushing it to an Elastic Container Registry (Private ECR)
• Logout to Amazon ECR this logout to Amazon ECR once the image is pushed successfully

To Understand the GitHub Actions syntax please refer to this link.With all this set, let's go to AWS Management console to create an AWS ECR repository.

Setting AWS Secrets

In the previous section , we have seen how to get AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, now we need to provide this key for our Github Actions workflow. Go to Github Settings, then Secrets, and then New repository secret.

• AWS_ACCESS_KEY_ID — The AWS Access Key ID
• AWS_SECRET_ACCESS_KEY — The AWS Secret Access Key
• ECR_REPOSITORY — The name of the AWS ECR repository you created

Once we have all this set, let's push our local changes including Dockerfile, main.yml and .dockerignore on our repository to trigger Github actions jobs. Stage all changes and push to github. You will see a new Workflow in Github Actions tab.

And if you click on the workflow, you will see workflow jobs that are running

After everything complete, you will see the following output

Great! Our docker image is now hosted on AWS ECR. That's the end of this first part, in the part, we will see how to update our workflow file to pull and deploy this image on Heroku.

Thanks for reading. The source code is available here

Follow me on socials media to stay up to date with latest posts.

Hey guys 🤚, Glad to have you here.

In the previous post, we covered the Part 2 of this series about building a complete Fullstack app called FoxNews  using Amazon Web Services. The Part 1 was focused on setting our tools and host the basic setup of our Next.js app on Amazon Amplify using Amplify Framework.

In this post, we will be able to fetch and displays news from remote API called NewsCatcherAPI. Since we have a limited plan (Trial Plan with 1000 request) at https://newscatcherapi.com/,  we don't want to exhaust our plan. That's why we are going to  to fetch news once when the user open the app and then store the result in a kind of local database for all future actions when user brows the app. to do so, we are going to use Redux with Redux toolkit. The main purpose of this part will be :

• setup redux with redux toolkit
• deploy the result on Amazon Amplify

1. Put everything in place

As we are using existing project, we just need to clone the project at the stage we left in our previous post where we hosted the basic version of our Next.js App with the main and the detail page. To do so, we need to run this in the terminal

git clone -b feat/part2-ui-layer --single-branch https://github.com/Doha26/Foxnews-nextjs-aws.git

With this, you fetch all the branches in the repository, checkout to the one you specified, and the specific branch becomes the configured local branch for git push and git pull The --single-branch flag (introduced in Git version 1.7.10) allows you to only fetch files from the specified branch without fetching other branches

Go tot the root of the project with cd foxnews-nextjs-aws and yarn

Create a new branch to track all the changes we will make during this Part 2. To do so, run this inside the terminal.

• git checkout -b feat/part3-redux to create a new branch called feat/part3-redux
• git push --set-upstream origin feat/part3-redux push everything on github to start
• run yarn dev to serve the default setup at localhost:3000 that looks like this

Well 👏, if you have this, it's means we are ready for the next step. Let's go 🏄🏼‍♂️

In the previous post, we hardcoded the displayed news in the code in the src/utils file. In this post, we are going to refacto this and fetch news from the remote newscacther API. Let's start.

2. Get an API Key

Go to newsCatcherAPI website here and on the top menu, got to Get API Key.

you will be asked to register and choose a plan. You can choose the free plan that is absolutely good for our use case. Once Done, you will have access to the dashboard and here you will se your API key displayed.

now you have an API Key, create a file named .env.local that will host environment variables. Next.js comes with built-in support for environment variables, which allows you to do the following:

• Use .env.local to load environment variables
• Expose environment variables to the browser by prefixing with NEXT_PUBLIC_

So inside .env.local add the following

NEXT_PUBLIC_NEWS_API_KEY=XXXXX_YOUR_API_KEY_XXXXXX

This, done, make sure this file is not tracked by git. check the .gitignore and if not present, add it manually.

2. Fetch News with your API Key

we are going to create a utils function to fetch news using the API Key. Inside the lib folder at the root of the project, create a file named getNews.ts and add the following:

const getNews = async (url: string) => {
  const response = await fetch(url, {
    method: 'GET',
    headers: {
      'Content-Type': 'aplication/json',
      'x-api-key': process.env.NEXT_PUBLIC_NEWS_API_KEY || ''
    }
  })
  const data = await response.json()
  return data
}

export default getNews

Note the line 6 with this 'x-api-key': process.env.NEXT_PUBLIC_NEWS_API_KEY || ''. This line set an Http header with the Newscatcher API Key. Without this key, you will not be able to get results from the remote API.

2. Setup Redux and Redux toolkit

before we start explaining how to setup Redux, we will take some lines to explain what is behind the tool and when it can be useful to use.

What is Redux ?

Redux is a predictable state container for JavaScript apps. As the application grows, it becomes difficult to keep it organized and maintain data flow. Redux solves this problem by managing application’s state with a single global object called Store. Redux fundamental principles help in maintaining consistency throughout your application, which makes debugging and testing easier.

Why Should I Use Redux?​

Redux helps you manage "global" state - state that is needed across many parts of your application.

The patterns and tools provided by Redux make it easier to understand when, where, why, and how the state in your application is being updated, and how your application logic will behave when those changes occur. Redux guides you towards writing code that is predictable and testable, which helps give you confidence that your application will work as expected.

When Should I Use Redux?​

Redux helps you deal with shared state management, but like any tool, it has tradeoffs. There are more concepts to learn, and more code to write. It also adds some indirection to your code, and asks you to follow certain restrictions. It's a trade-off between short term and long term productivity.

Redux is more useful when:

• You have large amounts of application state that are needed in many places in the app
• The app state is updated frequently over time
• The logic to update that state may be complex
• The app has a medium or large-sized codebase, and might be worked on by many people

The following image from redux documentation let you understand the redux flow

You can read more at the Redux documentation here https://redux.js.org/tutorials/fundamentals/part-1-overview

Redux toolkit

According to the Redux team, Redux Toolkit was created to address three major concerns:

1. "Configuring a Redux store is too complicated"
2. "I have to add a lot of packages to get Redux to do anything useful"
3. "Redux requires too much boilerplate code"

Simply, Redux Toolkit provides us with tools that help abstract over the setup process that used to be troublesome.

Some of  functions that simplify the different parts of Redux are :

• configureStore : to simplify store creation
• createAction : to create actions easily
• createReducer : to simplify reducers creation

ReduxToolkit also provide us with another way to combine createAction and createReducer in a single call using Slice with createSlice() function. Let's see all this in action. to start, we need to install required packages. Open your favorite terminal and run the followings.

yarn add @reduxjs/toolkit next-redux-wrapper react-redux redux-persist 

create a slice file under src/stores/slice/articleSlice.ts

import { createAsyncThunk, createSlice, Draft, PayloadAction } from '@reduxjs/toolkit'
import type { RootState } from '../store'
import { NewsAPIObject, NEWS_API_URL } from '../../utils'
import { HYDRATE } from 'next-redux-wrapper'
import getNews from '../../../lib/getNews'

// declaring the types for our state
export type NewsState = {
  articles: NewsAPIObject[]
  pending: boolean
  error: boolean
  fetched: boolean
  error_code: string
}

const initialState: NewsState = {
  articles: [],
  pending: false,
  error: false,
  fetched: false,
  error_code: ''
}

// Get NEWS from NewsCatcherAPI
export const getArticles = createAsyncThunk('getAticles', async (_, { rejectWithValue }) => {
  const { status, articles, error_code } = await getNews(`${NEWS_API_URL}News`)
  return status === 'ok' ? { error: null, articles } : rejectWithValue({ articles: [], error_code })
})

// HeadersWithoutKey
export const articlesSlice = createSlice({
  name: 'news',
  initialState,
  reducers: {
    setArticles: (state: Draft<typeof initialState>, action: PayloadAction<NewsAPIObject[]>) => {
      state.articles = action.payload
    }
  },
  extraReducers: builder => {
    builder
      .addCase(HYDRATE, (_state: Draft<typeof initialState>) => {
        console.log('HYDRATE', _state)
      })
      .addCase(getArticles.fulfilled, (state, { payload }) => {
        console.log('FULFILLED')
        state.pending = false
        state.articles = payload.articles
        state.fetched = true
      })
      .addCase(getArticles.pending, state => {
        console.log('PENDING')
        state.pending = true
        state.fetched = false
      })
      .addCase(getArticles.rejected, (state, { payload }) => {
        console.log('rejected')
        state.pending = false
        state.error = true
        state.fetched = false
        //@ts-ignore
        state.error_code = payload.error_code
      })
  }
})
// Here we are just exporting the actions from this slice, so that we can call them anywhere in our app.
export const { setArticles } = articlesSlice.actions

// calling the above actions would be useless if we could not access the data in the state. So, we use something called a selector which allows us to select a value from the state.
export const selectArticles = (state: RootState) => state?.news || initialState

// exporting the reducer here, as we need to add this to the store
export default articlesSlice.reducer

With all this installed, let's create a redux store. Under src/store/store.ts

import { Action, combineReducers, configureStore, createStore, ThunkAction, applyMiddleware } from '@reduxjs/toolkit';
import { createWrapper } from 'next-redux-wrapper'
import storage from 'redux-persist/lib/storage'
import { persistReducer, persistStore } from 'redux-persist'
import newsReducer from './slice/articleSlice'

//@ts-ignore
const makeConfiguredStore = reducer => createStore(reducer, undefined, applyMiddleware())

const reducers = combineReducers({
  news: newsReducer
})

const persistConfig = {
  key: 'foxnews',
  whitelist: ['news'],
  storage
}
const persistedReducer = persistReducer(persistConfig, reducers)

const makeStore = () => {
  let store
  const isServer = typeof window === 'undefined'
  if (isServer) {
    store = makeConfiguredStore(newsReducer)
  } else {
    store = configureStore({
      reducer: persistedReducer,
      middleware: getDefaultMiddleware =>
        getDefaultMiddleware({
          serializableCheck: false
        }),
      devTools: true
    })
    //@ts-ignore
    store.__persistor = persistStore(store)
  }
  return store
}

export type AppDispatch = ReturnType<typeof makeStore>['dispatch']
export type AppStore = ReturnType<typeof makeStore>
export type RootState = ReturnType<AppStore['getState']>
export type AppThunk<ReturnType = void> = ThunkAction<ReturnType, RootState, unknown, Action<string>>
export const wrapper = createWrapper<AppStore>(makeStore, { debug: true })

NB: You can see that we create a persistable store using redux-persist. This way, we will fetch data once and then persist to the localStorage and prevent our App to fetch everytime the user refresh the browser.

Now we have a Slice and the store, let's create our customs Hooks that override the default behavior of two Redux function. useDispatch() and useSelector()

under src/store create a file named hooks.ts with the following

import { TypedUseSelectorHook, useDispatch, useSelector } from 'react-redux'
import type { AppDispatch, RootState } from './store'

export const useAppDispatch = () => useDispatch<AppDispatch>()
export const useAppSelector: TypedUseSelectorHook<RootState> = useSelector

With all this set, we now just have to wrap our main _app.tsx component logic inside a component provided by redux-persist and provide the component with our created store. Open _app.tsx at the root and add the following :

import '../../styles/globals.css'
import type { AppProps } from 'next/app'
import { wrapper } from '../store/store'
import { PersistGate } from 'redux-persist/integration/react'
import { useStore } from 'react-redux'
function MyApp({ Component, pageProps }: AppProps) {
  const store = useStore()

  return (
    /* 
    // @ts-ignore */
    <PersistGate persistor={store.__persistor} loading={null}>
      <Component {...pageProps} />
    </PersistGate>
  )
}

export default wrapper.withRedux(MyApp)

With this set, we are good to go with redux. let's update our pages components to see it in action.

Update src/pages/index.tsx and add some logic.

...
import { useAppDispatch, useAppSelector } from '../store/hooks'
import { getArticles, selectArticles } from '../store/slice/articleSlice'
...

const Home: NextPage = () => {
    const dispatch = useAppDispatch()
  const { articles, error, error_code } = useAppSelector(selectArticles)
  .. 
  
  useEffect(() => {
    //@ts-ignore
    dispatch(getArticles())
    setMessageTitle('Loading...')
    if (error || articles.length == 0) {
      if (error_code === 'HeadersWithoutKey') {
        setMessageTitle('No API key provided to fetch News 🧩 ')
      } else if (error_code === 'ConcurrencyViolation' && articles.length == 0) {
        setMessageTitle('API Error Wait and then refresh ⛳️')
      } else {
        setMessageTitle('Latest updates')
      }
    } else {
      setMessageTitle('Latest updates')
    }
  }, [articles, dispatch, error_code, error])
  

   return (
   <div className="flex flex-col scrollbar-hide md:scrollbar-default">
       
      ..
      ..
       
       {error && (
        <div className="flex font-mono font-bold text-md mx-auto w-10/12 justify-center mt-36"> {messageTitle}</div>
      )}
      <Footer />
   </div>
   )
}
export default Home

Let's do the same for article details:

...
import { useAppSelector } from '../../store/hooks'
import { selectArticles } from '../../store/slice/articleSlice'
...
// import { fakeNews } from '../../utils' <= REMOVE THIS LINE

const NewsItem = () => {
... 
  const { articles } = useAppSelector(selectArticles)
  //const articles = fakeNews <= REMOVE THIS LINE

}

This produce the following result:

We have all the news and the detail page

Now let's fix something we have on the main page. when you scroll, you will see a scrollbar that appear at the right of the screen. let's fix this behavior by hiding the scrollbar with a Tailwind CSS plugin. (Yes i know, it's possible to do this with pure CSS 😆 but let me show you how to do the same with a Tailwind plugin that will work for any browser). On the terminal, run the following to install the plugin:

yarn add tailwind-scrollbar-hide

Open tailwind.config.js at the root of the project and register the plugin

module.exports = {

...

plugins:[require('@tailwindcss/line-clamp'), require('tailwind-scrollbar-hide')]

}

Now update src/pages/index.tsx file with the following

...

const Home: NextPage = () => {

...

return (
	<div className="flex flex-col scrollbar-hide">
    
    ... .. // Content here
    
    </div>
)
}

export default Home

And that's all. we always have everything working fine. Push everything on github and merge with the main branch. If the merge is not possible, merge locally by resolving conflicts and then retry.

3. Deploy on Amazon Amplify

On the first part of this tutorials series, we completed how to configure and setup amazon amplify with the project. If you did'nt complete this part, you will not be able to complete this part. make sure to complete the Part 1 with Amplify setup.

To deploy our app to amplify, let's add the NewsCatecherAPI key on Amplify console with the following steps

1. Open the Amplify console.
2. In the Amplify console, choose App Settings, and then choose Environment variables.
3. In the Environment variables section, choose Manage variables.
4. In the Manage variables section, under Variable, enter NEXT_PUBLIC_NEWS_API_KEY key. For Value, enter the value of your API Key value. By default, Amplify applies the environment variables across all branches, so you don’t have to re-enter variables when you connect a new branch.

Next, configure the project: run amplify configure project

? Which setting do you want to configure? Project information
? Enter a name for the project xxxxxxxxxxxxx // <= project name on amplify console
? Choose your default editor: Visual Studio Code // or your IDE
? Choose the type of app that you're building javascript
Please tell us about your project
? What javascript framework are you using react
? Source Directory Path:  src
? Distribution Directory Path: .next // <= `.next (VERY IMPORTANT)` directory 
? Build Command:  npm run-script build
? Start Command: npm run-script start
Using default provider  awscloudformation

Successfully made configuration changes to your project.

NB: Note that for most of the options Amplify should be able to infer the right choice. According to Amplify documentation, some updates are required  wether we are deploying SSG Only or SSG + SSR Next.js app. To be more precise, here are the different scenarios:

• SSG Only

Inside package.json

"scripts": {
  "build": "next build && next export",
  ...
}

Run this command.

amplify configure project

Then, keep every thing the way it is, except this:

Distribution Directory Path: out

• SSG & SSR:

Inside package.json

"scripts": {
  "build": "next build",
  ...
}

Run this command.

amplify configure project

Then, keep every thing the way it is, except this:

Distribution Directory Path: .next

In our case, we are using SSG + SSR so we are going to set the distribution directory path to  .next  - that's where next export spits out our static files.

Now we just have to publish with the command amplify publish. The amplify CLI with proceed some steps and you prompt a success message once everything done.

✔ Deployment complete!
https://dev.xxxxxx_app_id.amplifyapp.com

NB: Another way is to trigger the deploy manually on the Amplify console when everything is pushed on the configured branch (In our case, we configured the main branch on the part 1 ) of your github repository.

We have completed the third Part of this tutorial series 👏

Thanks for reading.

Follow me on socials media to stay up to date with latest posts.

Hey guys 🤚, Glad to have you here.

In the previous post, we covered the Part 1 of this series about building a complete Fullstack app called FoxNews  using Amazon Web Services. The Part 1 was focused on setting our tools and host the basic setup of our Next.js app on Amazon Amplify using Amplify Framework. In this part, we will be building the main logic of our app using Next.js and Tailwind CSS. The main purpose of this part will be :

• Being able to Fetch and display news from external API. We will use https://newscatcherapi.com/ to fetch randoms news.
• Display some specifics details about a news

Some usefull tools we will be using in this part

• Next.js  
• Tailwind CSS to style everything
• NewscatcherAPI to fetch Random news (For now, we will add some logic to create and store news on our own remote server later 😉)

1. Put everything in place

As we are using existing project, we just need to clone the project at the stage we left in our previous post where we hosted the basic version of our Next.js App. To do so, run this command inside the terminal

git clone -b feat/part1-setup-with-amplify --single-branch https://github.com/Doha26/Foxnews-nextjs-aws.git

With this, you fetch all the branches in the repository, checkout to the one you specified, and the specific branch becomes the configured local branch for git push and git pull The --single-branch flag (introduced in Git version 1.7.10) allows you to only fetch files from the specified branch without fetching other branches

Go tot the root of the project with cd foxnews-nextjs-aws and yarn  

Create a new branch to track all the changes we will make during this Part 2. To do so, run this inside the terminal.

• git checkout -b feat/part2-ui-layer to create a new branch called feat/part2-ui-layer
• git push --set-upstream origin feat/part2-ui-layer push everything on github to start
• run yarn dev to serve the default setup at localhost:3000 that looks like this

Well 👏, if you have this, it's means we are ready for the next step. Let's go 🏄🏼‍♂️

2. Setup Tailwind CSS

In this section, we are going to build the UI Layer of this second part with next.Js and Tailwind CSS. First of all we are going to create our folder structure and replace the default one provided by Next.js  with the following steps:

• move /pages folder inside src folder
• create a new folder named /ui inside src and inside the ui folder, create another folder named component that will host our components

With this setup, we are good to go. Let's setup tailwind CSS to work with our Next.js setup. According to Tailwind documentation here, it's very simple to do.

• Install Tailwind CSS:  To install Tailwind and its peer dependencies, Run this on your favorite terminal yarn add -D tailwindcss postcss autoprefixer and then run the init command to generate both tailwind.config.js and postcss.config.js with  npx tailwindcss init -p
• Configure your template paths: Add the paths to all of your template files in your tailwind.config.js file.

module.exports = {
  content: [  // ADD this content block
    "./src/pages/**/*.{js,ts,jsx,tsx}",  
    "./src/ui/components/**/*.{js,ts,jsx,tsx}", 
  ],
  theme: {
    extend: {},
  },
  plugins: [],
}

• Add the Tailwind directives to the global CSS file : add the following inside  ./styles/globals.css file

@tailwind base;
@tailwind components;
@tailwind utilities;

That's all. Tailwind is now set with our Next.js setup. Let's add custom font and styles that we will use in our app. For the font, we will use Inter, a free google font. Next, create a file name _document.tsx inside /src/pages folder and add the following:

import Document, { Html, Head, Main, NextScript } from 'next/document'
import { DocumentContext } from 'next/document'
class MyDocument extends Document {
  static async getInitialProps(ctx: DocumentContext) {
    const initialProps = await Document.getInitialProps(ctx)
    return initialProps
  }

  render() {
    return (
      <Html>
        <Head>
          <link href="https://fonts.googleapis.com/css2?family=Inter&display=swap" rel="stylesheet" /> 
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    )
  }
}

export default MyDocument

This will override the default Document object and update the html of our page to import the font we need. Now Open tailwind.config.js file and add the following:

/** @type {import('tailwindcss').Config} */
const defaultTheme = require('tailwindcss/defaultTheme')
module.exports = {
  ..
  theme: { 
    extend: {
      fontFamily: { // Add this to register the theme with tailwind
        sans: ['Inter', ...defaultTheme.fontFamily.sans]
      }
    },
    colors: { // Add some colors with variant
      description: '#54595F',
      white: '#fff',
      black: '#000',
      grey: {
        100: '#cfd8dc'
      },
      blue: {
        400: '#5c6bc0'
      },
      red: {
        400: '#ef5350',
        500: '#f44336'
      }
    }
  },
  plugins: []
}

That's all, we are our Font and Tailwind set with the project

3. Create components

Inside src/ui/components create the following functional components.

• Footer.tsx

import Image from 'next/image'
import Link from 'next/link'

const Footer = () => (
  <nav className="mb-0 fixed w-full z-10 bottom-0 bg-black ">
    <div className="flex flex-row items-center justify-between h-10 sm:w-9/12 sm:mx-auto mx-4 ">
      <Image src="/logo-img.svg" alt="Logo" width="25" height="25" />
      <Link href="">
        <h1 className="font-mono font-bold text-sm hidden md:block text-white cursor-pointer">© Your Name :)</h1>
      </Link>
    </div>
  </nav>
)

export default Footer

• Header.tsx

import Head from 'next/head'

const Header = () => (
  <Head>
    <title>FoxNews</title>
    <meta name="description" content="Generated by create next app" />
    <link rel="icon" href="/favicon.ico" />
  </Head>
)

export default Header

• Nav.tsx

import Image from 'next/image'
import Link from 'next/link'

const Nav = () => (
  <nav className="mt-0 fixed w-full z-10 top-0 bg-black ">
    <div className="flex flex-row items-center justify-between h-16 sm:w-9/12 sm:mx-auto mx-4 ">
      <div className="flex flex-row">
        <Image src="/logo-img.svg" alt="Logo" width="36" height="36" />
        <Link href="/">
          <a className="font-mono font-bold text-3xl p-2 hidden sm:block cursor-pointer text-white">FoxNews</a>
        </Link>
      </div>
      <h1 className="font-mono font-bold text-sm hidden md:block text-white">
        Call Us (348)981.872 / hello@foxnews.com
      </h1>
      <h1 className="font-mono font-bold text-sm hover:underline hover:cursor-pointer hover:font-bold text-white">
        Login
      </h1>
    </div>
  </nav>
)

export default Nav

4. The main page

Inside /src/pages/index.tsx add the following code to import our created components

import Header from '../ui/components/Header'
import type { NextPage } from 'next'
import Nav from '../ui/components/Nav'
import Footer from '../ui/components/Footer'

const Home: NextPage = () => {
  return (
    <div className="flex flex-col">
      <Header />
      <Nav />
      <Footer />
    </div>
  )
}
export default Home

And we have the following result that display only the Navbar and the footer

Now, let's create  NewsItem component. For this we need to first create associated type.  Create a file name utils.ts inside src folder.  According to NewsCatcherAPI, a News type will have the following attribute.

export type NewsAPIObject = {
  media: string
  title: string
  summary?: string
  authorImg?: string
  author?: string
  authorRole?: string
  hasImage?: boolean
  largeImage?: boolean
  itemIndex?: number
  link?: string
  published_date?: string
  topic?: string
  country?: string
  language?: string
  _id?: string
  _score?: number
  twitter_account?: string
  clean_url?: string
  expand?: boolean
}

export type NewsAPIResponse = {
  status?: string
  total_pages?: number
  page_size?: number
  articles?: NewsAPIObject[]
}

Now create NewsItem.tsx inside src/ui/components. Before adding html inside our component, there is 2 things to note.

• A NewsItem will have a  description that will not be full displayed. We will display 150 characters and add  a Read more >>  button that will hide or display the full description. to do so, we will use create a function called toggleReadMore() to change the state according to if the button Read More >> is clicked or not and use a plugin that provides utilities for visually truncating text after a fixed number of lines.
• A NewsItem also have a published_date and we will format it using moment.js

let's install required lib. Run the following on your terminal: yarn add moment @tailwindcss/line-clamp.

As @tailwindcss/line-clamp is a Tailwind CSS plugin, we need to register it inside tailwind.config.js

/** @type {import('tailwindcss').Config} */
module.exports = {
  theme: {
    ..
  },
  plugins: [require('@tailwindcss/line-clamp'))] // <= TAILWIND PLUGINS
}

The NewsItem.tsx file will have the following

import { useState } from 'react'
import moment from 'moment'
import { NewsAPIObject } from '../../utils'

const News = ({ media, title, summary, author, country, published_date, expand }: NewsAPIObject) => {
  const [isReadMore, setIsReadMore] = useState(false)
  const toggleReadMore = () => {
    setIsReadMore(!isReadMore)
  }

  return (
    <div
      className={`flex flex-col ${
        !expand ? 'cursor-pointer transition hover:scale-105 duration-300 ease-in-out delay-50 mt-4' : 'mt-8'
      }`}
    >
      <img className={`object-cover rounded w-full ${expand ? 'h-80' : 'h-48'}`} src={media} alt="Img" />
      <h1
        className={`line-clamp-3 py-3 font-Inter font-semibold ${
          expand ? 'text-3xl' : 'text-2xl'
        } text-black hover:text-primary text-left text-ellipsis overflow-clip `}
      >
        {title}
      </h1>
      <p className="line-clamp-4 font-medium text-base text-description  mb-5 text-left">
		 {isReadMore ? summary?.slice(0, 150) : summary}
        <span onClick={() => toggleReadMore()} className="font-semibold text-sm cursor-pointer text-blue-400">
          {isReadMore ? '...read more' : ' show less'}
        </span>
      </p>
      <div className="flex items-center">
        <img className="rounded-lg w-10 h-10 object-cover" src={media} alt="Img" />
        <div className="flex flex-col ml-2">
          <strong>
            {author} <span className="text-xs text-description">| {country}</span>
          </strong>
          <span className="text-sm text-description">{moment(published_date).format('MMMM Do YYYY, h:mm:ss a')}</span>
        </div>
      </div>
    </div>
  )
}

export default News

Create some data inside src/utils.ts with the following:

..

export const fakeNews = [
  {
    title: "Chelsea Marcantel's The Upstairs Department Finishes World Premiere Run June 12",
    author: 'Leah Putnam',
    published_date: '2022-06-12 04:30:00',
    link: 'https://playbill.com/article/chelsea-marcantels-the-upstairs-department-finishes-world-premiere-run-june-12',
    clean_url: 'playbill.com',
    summary:
      'Regional News Regional News Regional News Regional News Regional News Video Los Angeles News Regional News Regional News Regional News Awards Video Regional News Regional News Video Video Regional News Production Photos Production Photos Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Los Angeles News Regional News Regional News Production Photos Cast Recordings &',
    topic: 'news',
    country: 'US',
    language: null,
    media: 'https://assets.playbill.com/editorial/_1200x630_crop_center-center_82_none/1cVRwy-4.jpeg?mtime=1648834896',
    authorImg:
      'https://assets.playbill.com/editorial/_1200x630_crop_center-center_82_none/1cVRwy-4.jpeg?mtime=1648834896',
    twitter_account: '@playbill',
    _score: 5.424161,
    _id: 'c17698032111425760dac1cf58bd8778'
  },
  {
    title: "Britta Johnson's Life After Begins Previews at Chicago's Goodman Theatre June 11",
    author: 'Leah Putnam',
    published_date: '2022-06-11 04:01:28',
    link: 'https://playbill.com/article/britta-johnsons-life-after-begins-previews-at-chicagos-goodman-theatre-june-11',
    clean_url: 'playbill.com',
    summary:
      'Regional News Regional News Regional News Regional News Video Los Angeles News Regional News Regional News Regional News Awards Video Regional News Regional News Video Video Regional News Production Photos Production Photos Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Regional News Los Angeles News Regional News Regional News Production Photos Cast Recordings & Albums Region',
    topic: 'science',
    country: 'US',
    language: 'en',
    authorImg:
      'https://assets.playbill.com/editorial/_1200x630_crop_center-center_82_none/1cVRwy-4.jpeg?mtime=1648834896',
    media:
      'https://assets.playbill.com/editorial/_1200x630_crop_center-center_82_none/Samantha-Williams-Paul-Alexander-Nolan-and-Bryonha-Marie-Parham_HR.jpg?mtime=1654788330',
    twitter_account: '@playbill',
    _score: 5.418454,
    _id: 'f54468ea81e6026241e6af6b2bb07848'
  }
]

Update src/index.tsx to use the new component.

..
import { NewsAPIObject } from '../utils'
import Link from 'next/link'
import News from '../ui/components/NewsItem'
import { fakeNews, NewsAPIObject } from '../utils'

const articles: NewsAPIObject[] = fakeNews

const Home: NextPage = () => {
return (
    <div className="flex flex-col">
      <Header />
      <Nav />
      {articles?.length && (
        <div className=" flex justify-center font-bold mt-24 text-2xl underline text-black items-center">
          {messageTitle}
          <span className="flex h-3 w-3 ml-2">
            <div className="animate-ping inline-flex h-3 w-3 rounded-full bg-red-400 opacity-75"></div>
            <span className="absolute rounded-full h-3 w-3 bg-red-500"></span>
          </span>
        </div>
      )}

      {articles?.length && (
        <div className="sm:px-16 py-8 grid grid-cols-1 sm:grid-cols-2 md:grid-cols-3  gap-6 mx-auto w-10/12 mb-32">
          {articles?.map((item: NewsAPIObject) => {
            return (
              <Link href={`/news/${item._id}`} key={item._id}>
                <a>
                  {/* To avoid forwardRef issue with Next/link*/}{' '}
                  <News
                    media={item.media}
                    title={item.title}
                    summary={item.summary}
                    author={item.author}
                    authorImg={item.authorImg}
                    country={item.country}
                    _id={item._id}
                    published_date={item.published_date}
                    expand={false}
                  />
                </a>
              </Link>
            )
          })}
        </div>
      )}
      {error && (
        <div className="flex font-mono font-bold text-md mx-auto w-10/12 justify-center mt-36"> {messageTitle}</div>
      )}
      <Footer />
    </div>
  )
}
export default Home

At his step, let's add a title for this page. Inside the index.tsx

import { useState } from 'react'

const Home: NextPage = () => {
const [messageTitle, setMessageTitle] = useState('Latest updates')
 
 return (
     ..
   <Nav/>
     {articles?.length && (
        <div className=" flex justify-center font-bold mt-24 text-2xl underline text-black items-center">
          {messageTitle}
          <span className="flex h-3 w-3 ml-2">
            <div className="animate-ping inline-flex h-3 w-3 rounded-full bg-red-400 opacity-75"></div>
            <span className="absolute rounded-full h-3 w-3 bg-red-500"></span>
          </span>
        </div>
      )}
 )
}

The result look like this

5. The detail page

Next.js has a file-system based router built on the concept of pages with two essentials things to know about Routing.

• Each file inside pages directory is associated with a route based on its file name. This means, if you create pages/about.tsx that exports a React component like below, and it will be accessible at /about
• Dynamic routes : if you create a file called pages/posts/[id].js, then it will be accessible at posts/1, posts/2, etc.
• To learn more about dynamic routing, check the Dynamic Routing documentation

So, When a file is added to the pages directory, it's automatically available as a route.

The files inside the pages directory can be used to define most common patterns.

Index routes

The router will automatically route files named index to the root of the directory.

• pages/index.js → /
• pages/blog/index.js → /blog

Nested routes

The router supports nested files. If you create a nested folder structure, files will automatically be routed in the same way still.

• pages/blog/first-post.js → /blog/first-post
• pages/dashboard/settings/username.js → /dashboard/settings/username

Dynamic route segments

To match a dynamic segment, you can use the bracket syntax. This allows you to match named parameters.

• pages/blog/[slug].js → /blog/:slug (/blog/hello-world)
• pages/[username]/settings.js → /:username/settings (/foo/settings)
• pages/post/[...all].js → /post/* (/post/2020/id/title)

Check out the Dynamic Routes documentation to learn more about how they work.

So Let's create the detail page. In src/pages create a new folder named news and add a file named [id].tsx and add the following.

import Image from 'next/image'
import { useRouter } from 'next/router'
import { fakeNews } from '../utils'
import Header from '../../ui/components/Header'
import Nav from '../../ui/components/Nav'
import News from '../../ui/components/NewsItem'
import Link from 'next/link'

const articles: NewsAPIObject[] = fakeNews // we will update later

interface IQueryParam {
  id: string
}
const NewsItem = () => {
  const router = useRouter()
  const { id } = router.query as unknown as IQueryParam
  
  const item = articles?.find(article => article._id === id)
  
  return (
    <div className="flex flex-col">
      <Header />
      <Nav />
      <div className="sm:mx-auto md:w-11/12 sm:w-11/12 mt-32 lg:w-6/12">
        <Link href="/" title="Back to Home">
          <Image src="/back.svg" alt="Logo" width="39" height="32" className="cursor-pointer" />
        </Link>
        {item && (
          <News
            media={item.media}
            title={item.title}
            summary={item.summary}
            author={item.author}
            authorImg={item.authorImg}
            country={item.country}
            _id={item._id}
            published_date={item.published_date}
            expand={true}
          />
        )}
      </div>
    </div>
  )
}

export default NewsItem

That's all. if we click on one item on the main page, it will display the follow result

Now lets add some pagination Item at the bottom to navigate over Previous and Next News

Inside src/ui/components create two components

• PaginationItem.tsx

import moment from 'moment'
import Link from 'next/link'

interface PaginationItemProps {
  position: 'right' | 'left'
  title?: string
  mediaSource?: string
  date?: string
  id?: string
}
const PaginationItem = ({ position, title, mediaSource, date, id }: PaginationItemProps) => {
  const image = mediaSource as string
  return position == 'left' ? (
    <Link href={`/news/${id}`}>
      <div className="flex max-w-sm cursor-pointer transition hover:scale-105 duration-300 ease-in-out delay-50 w-full">
        {image && <img className="rounded w-16 h-16" src={image} alt="Img" />}
        <div className="flex flex-col ml-2 max-w-xs hover:underline justify-items-start ">
          <strong className="line-clamp-3 text-ellipsis overflow-hidden">{title}</strong>
          <span className="text-sm text-description">{moment(date).format('MMMM Do YYYY, h:mm:ss a')}</span>
        </div>
      </div>
    </Link>
  ) : (
    <Link href={`/news/${id}`}>
      <div className="flex mt-10 md:mt-0 cursor-pointer w-full transition hover:scale-105 duration-300 ease-in-out delay-50 ">
        <div className="flex flex-col  mr-2 max-w-xs hover:underline text-right ">
          <strong className="line-clamp-3">{title}</strong>
          <span className="text-sm ">{moment(date).format('MMMM Do YYYY, h:mm:ss a')}</span>
        </div>
        {image && <img className="rounded pl-22 w-16 h-16 " src={image} alt="Img" />}
      </div>
    </Link>
  )
}

export default PaginationItem

• PaginationBottom.tsx

import { NewsAPIObject } from '../../utils'
import PaginationItem from './PaginationItem'

interface IPaginationBottomProps {
  leftItem?: NewsAPIObject
  rightItem?: NewsAPIObject
}
const PaginationBottom = ({ leftItem, rightItem }: IPaginationBottomProps) => {
  const {
    title: leftItemTitle,
    media: leftItemMediaSource,
    published_date: leftItemDate,
    _id: leftItemId
  } = leftItem as NewsAPIObject
  const {
    title: rightItemTitle,
    media: rightItemMediaSource,
    published_date: rightItemDate,
    _id: rightItemId
  } = rightItem as NewsAPIObject

  return (
    <div className="mt-10 mb-20 md:flex flex-row justify-between w-full">
      <PaginationItem
        position="left"
        title={leftItemTitle}
        mediaSource={leftItemMediaSource}
        date={leftItemDate}
        id={leftItemId}
      />
      <PaginationItem
        position="right"
        title={rightItemTitle}
        mediaSource={rightItemMediaSource}
        date={rightItemDate}
        id={rightItemId}
      />
    </div>
  )
}

export default PaginationBottom

Update the detail page [id].tsx file inside src/news folder

import PaginationBottom from '../../ui/components/PaginationBottom'

const NewsItem = () => {
.. 
const item = articles?.find(article => article._id === id)
  const itemIndex = articles?.findIndex(article => article._id === id)
  const leftItem = itemIndex === 0 ? item : articles[itemIndex - 1]
  const rightItem = itemIndex == articles.length - 1 ? item : articles[itemIndex + 1]
  
   return (
   <div className="sm:mx-auto md:w-11/12 sm:w-11/12 mt-32 lg:w-6/12">
   ..
   <PaginationBottom leftItem={leftItem} rightItem={rightItem} /> // <= THIS LINE
   </div>
   )

}
export default NewsItem

And this produce the following result

We have completed this Second Part of the tutorial. In the next tutorial, we will see how to setup Redux with Redux toolkit.

Thanks for reading.

Follow me on socials media to stay up to date with latest posts.

Hey guys 🤚, Glad to have you here. In this post, we are going to cover how to build and deploy a Fullstack web application using Amazon Web Services.  

We are going to build an app called FoxNews, step by step. The final result will look like this:

This post will be the first in a long series (4 Parts) covering the use of Amazon Web Services

• Part 1 : We will setup our Dev environment and deploy the v1 of our app on AWS Amplify using Amplify Framework.
• Part2: Will be focused on building the main logic of our app using Next.js and Tailwind CSS.
• Part3 : We will be able to fetch and displays news from remote API and setup Redux with Redux Toolkit to persist news.
• Part 4 (Upcoming): Will be focused on creating a complete authentication system  with login, signing, password recovery using Amazon Cognito.

Here bellow is the list of services we will use:

• Amazon Amplify Framework A  comprehensive library for building sophisticated cloud-powered apps on a flexible, scalable, and reliable serverless backend on AWS.
• AWS CloudFront’s CDN to distribute around the world
• AWS S3 to upload images
• AWS IAM(Identity and Access Management which provides fine-grained access control across all of AWS
• AWS Lambda to create a serverless function that will resize images befre storing them on S3
• AWS Route 53  for domain name
• AWS Certificate Manager  that will provide us an SSL certificate for the domain name
• Amazon Cognito for registration, authentication, and account recovery
• Amazon DynamoDB which is is a fully managed, serverless, key-value NoSQL database designed to run high-performance applications at any scale
• AWS AppSync that will help us create and manage a GraphQL backend. In our case, we will should be able to read, create, update, delete news.
• Amazon S3 bucket to store your app's static assets
• Lambda@Edge function to SSR pages
• Next.js with Typescript as the frontend framework
• Tailwind CSS as the css framework

For this First Part, we will setup our Dev environment and deploy the v1 of our app on AWS. So let's start by setting everything we will need up !

1. Setup Amplify CLI

The Amplify Command Line Interface (CLI) is a unified toolchain to create AWS cloud services for your app. Let's go ahead and install the Amplify CLI.

Before we start coding our application, we need to setup amazon amplify on our local machine. Let's go step by step.

First go here and create an AWS account if you don't have one. you will need it to create and manage apps and services on AWS

Follow thees instructions to set it up on your local machine

# NPM
$ npm install -g @aws-amplify/cli

# cURL (Mac & Linux)
curl -sL https://aws-amplify.github.io/amplify-cli/install | bash && $SHELL

# cURL (Windows)
curl -sL https://aws-amplify.github.io/amplify-cli/install-win -o install.cmd && install.cmd

Once completed, run amplify configure

This will open amplify console and try to connect to https://console.aws.amazon.com/ . Once connected, it will ask you to hit Enter        to continue to the second step.

• Specify the AWS Region. (Use arrow keys to select a region)
• Specify the username for the new IAM. We will cover IAM in another blog post. But basically, IAM stand for Identity Access Management and according to AWS doc, its a service that secure access to your ressources. Follow the steps as illustrated in the following gif from AWS doc.

As recommended in the Amplify doc, Create a user with AdministratorAccess-Amplify to your account to provision AWS resources for you like AppSync, Cognito etc

Once the user is created, Amplify CLI will ask you to provide the accessKeyId and the secretAccessKey to connect Amplify CLI with your newly created IAM user.

Enter the access key of the newly created user: (You have it on the last step of  IAM creation step wizard)

• ? accessKeyId:  # YOUR_ACCESS_KEY_ID
• ? secretAccessKey:  # YOUR_SECRET_ACCESS_KEY
• ? Profile Name:  # (default) <== YOU CAN USE THE DEFAULT PROFLE HERE

You will see the message in the console Successfully set up the new user , you are good to go.  Next we'll set up the app and initialize Amplify!

2. Setup the Next.js project

For this project, we will use Yarn as node package manager.

On the CLI, run the following to initialize an empty next.js project with typescript language yarn create next-app foxnews --typescript && cd foxnews

Now we have a basic Next.js project. run yarn dev and it will display the default welcome page of Next.js app.

Create a git repository here  and link to the newly created project. If you don't have a github account, sign up here

You can find your repository URL here.

Now initialize git on the project we just created and link to the remote project with the following:

git init
git remote add origin https://github.com/Doha26/Foxnews-nextjs-aws.git // REPLACE WITH YOUR REPO URL 
git add .
git commit -m ‘first commit’
git branch -M main
git push -u origin main

Good, the project is ready for version control. Let's setup Amplify now !

3. Configure Amplify with the project

On the command line, run amplify init to register your project with the amplify framework. It will ask you some questions:

• ? Enter a name for the project your project name
• ? Initialize the project with the above configuration? Yes
• ? Select the authentication method you want to use  AWS profile
• ? Please choose the profile you want to use  default

Lets amplify create everything and when everything will be set, you will see the following output

✔ Successfully created initial AWS cloud resources for deployments.
✔ Initialized provider successfully.
✅ Initialized your environment successfully.

Your project has been successfully initialized and connected to the cloud!

At this step, our project is ready with Amplify framework. Let's deploy this basic setup on AWS as Amplify now support SSR web apps.  

4. Deploy  

For this step, go to the Amplify console ️and follow the steps bellow to connect amplify to your github repo.

On the Next screen, choose your repo and select the branch to deploy. In our case, we want to deploy the main branch.  

On the Next screen, Amplify will automatically detect that we are trying to host a Next.Js App with SSR and build settings will auto-populate.

• Check Enable full-stack continuous deployments (CI/CD)
• On Environment dropdown , leave it empty and amplify will use the default branch main for now.
• On select existing services. Click on Create new role this will open a new window and ask you to create a new user

On this screen, make sure Amplify service is selected and click  Next:Permissions

Here, click Next

Click Create role

Here is the newly created user role. Select this role for Configure build settings and you click Continue.

On the last screen,  you can Review your settings and YEAH. Your app is ready for deploy. On this screen, click Save and Deploy.  AWS will complete the following steps during few minutes and then deploy your Next.js app on a subdomain main.app_id.amplifyapp.com

Behind the scenes, Amplify creates AWS resources used to deploy your app -- first an Amazon S3 bucket to store your app's static assets, then an Amazon CloudFront to serve your app itself, finally a Lambda@Edge function to SSR pages.

Click on the preview link , you will see the welcome page of the next.js app. Our App is ready on Amplify 🎉

We have completed this First Part of the tutorial. In the next tutorial, we will build the UI Layer of the app to fetch and display news.

Thanks for reading. The source code is available here

Follow me on socials media to stay up to date with latest posts.

Hey guys 🤚, Glad to have you here! In this post we are going to cover something different. Once we have an app running, it's VERY IMPORTANT to see how our app behave for end users and ensure that everything works as expected. to do so, we need to monitor performances , track bugs and fix them as soon as they arrive. One of the most powerful SDK to do this is Sentry. In this tutorial, we will cover how to configure our GraphQL Backend with.

1. What is sentry ☝️ ?

Sentry.io is an external monitoring and logging platform as a service which can help you identify and triage errors API's and Services, webapps and mobile and desktop applications. This makes it an essential and versatile tool for any serious business or developer.

To have a quick overview of how sentry help you track errors, you can take a look at the sentry demo sandbox that show you something like this.

In this tutorial, we will setup sentry on a GraphQL API running on Apollo Server 3. Wether you are building a REST API or a GraphQL Backend, this tutorial will also working for you.

2. Setup 🛠

For this implementation, we will use a ready to use node.js graphql server we built on another post using Typescript. So we will fetch the source code that run a graphQL server with mocked data and JWT configured for authorization.

Since the directory containing the initial setup is part of a repository that host multiples tutorials source code each on a single folder, we will only clone the one with the initial setup we need to get start. Follow the folling steps from the terminal.

git clone --no-checkout https://github.com/Doha26/fullstack-hebdo-posts.git

cd fullstack-hebdo-posts

git sparse-checkout init --cone

git sparse-checkout set  05-nodejs-graphql-sentry

And now inside the folder, install node dependencies and start the server

 cd 05-nodejs-graphql-sentry && yarn && yarn start:dev

you will see the following output

This display the apollo server v3 landing page.

2. Let's setup a sentry project💻

First of all, go to sentry.io and register. After registration, you will see the following onboarding page.

Choose Install Sentry and click on the Start Button. The next page will ask you to choose the platform you are setting sentry for. In our case, we want to set this for a Node.JS GraphQL Backend. So we will choose Node.JS to create a Node.Js project on sentry platform.

The next step will display the following page that help you configure sentry for your Node.Js project.

In this screenshot, two elements are very important:

• The DSN: This stand for Data Source Name. According to sentry documentation, A DSN tells a Sentry SDK where to send events so the events are associated with the correct project. The DSN configures the protocol, public key, server address, and project identifier. It is composed of the following parts:

{PROTOCOL}://{PUBLIC_KEY}:{SECRET_KEY}@{HOST}{PATH}/{PROJECT_ID}

Note:  The DSN should be treated as a secret and not shared with anyone. (We will place it inside a .env file)

• The TracesSampleRate: determines the percent of events the monitor should send to the dashboard. A value of 1.0 sends 100% of the captured events – but if you find this to be too noisy you can reduce this number.

Next, you will see the sentry dashboard waiting for event and ready to catch errors.

3. Let's install  🪄

# Using yarn
yarn add @sentry/node @sentry/tracing @sentry/integrations

# Using npm
npm install --save @sentry/node @sentry/tracing @sentry/integrations

For this tutorial, we will create some environment variable inside a .env file containing JWT_USER_SECRET usefull for the previous blog post on how to Secure a GraphQL backend with JWT.  

JWT_USER_SECRET=ksjsjshbsid_fake_JWT_Token_Secret_Key_key_Here
APP_ENV=development
APP_NAME=Your_app_name_here
APP_REVISION=0.0.1
SENTRY_DSN=Your_DSN_here

Create a file under src/utils named sentry.ts or whatever you want that will host our sentry logic.

import * as Sentry from '@sentry/node'
import * as Tracing from '@sentry/tracing'
import * as core from 'express-serve-static-core'

import {
  RewriteFrames as RewriteFramesIntegration,
  ReportingObserver as ReportingObserverIntegration,
  ExtraErrorData as ExtraErrorDataIntegration,
  CaptureConsole as CaptureConsoleIntegration,
  Dedupe as DedupeIntegration
} from '@sentry/integrations'

const InitSentry = (app: core.Express): void => {
  Sentry.init({
    environment: process.env.APP_ENV,
    release: `${process.env.APP_NAME}-${process.env.APP_REVISION}` || '0.0.1',
    dsn: process.env.SENTRY_DSN,
    integrations: [
      new RewriteFramesIntegration({
        root: process.cwd()
      }) as RewriteFramesIntegration,
      new ExtraErrorDataIntegration({
        depth: 10
      }),
      new CaptureConsoleIntegration({
        // array of methods that should be captured
        // defaults to ['log', 'info', 'warn', StatusError, 'debug', 'assert']
        levels: ['error', 'warn', 'assert']
      }),
      new Sentry.Integrations.Http({ tracing: true }),
      new Tracing.Integrations.Express({ app }),
      new DedupeIntegration(),
      new ReportingObserverIntegration()
    ],
    tracesSampleRate: 1.0
  })
  app.use(Sentry.Handlers.requestHandler())
  app.use(Sentry.Handlers.tracingHandler())
  app.use(Sentry.Handlers.errorHandler())
}

export default InitSentry

And all we have to do is to call the InitSentry() function at server start. Inside src/index.ts file, add the following code :

// Bootstrap the server
const bootstrap = async () => {
  const db = await setupDb()
  const schema = await buildSchema({ resolvers: [EventResolver] })
  const app = express()

  // Init Sentry SDK here 
  InitSentry(app) // ADD THIS LINE <==

  // Express JWT Middleware that parse request and decode token
  app.use(
    expressJwt({

Everything is now ready. Let's let's raise an exception and see how sentry catches it. To raise an exception, let's  add a new Line and see how that will be captured by sentry.  

import * as Sentry from '@sentry/node' // Import this 

InitSentry(app) // Sentry init function 

Sentry.captureException(new Error('Testing Sentry SDK')) // Add this After

The Error is sent to sentry dashboard

Here is the error stacktrace.

Then, anywhere in your code base where you are logging errors (such as a try / catch block or a .catch() chain), add Sentry.captureException(error) (replacing error with the variable that represents your error object) to pass that error off to your Sentry monitor.

To query the  GraphQL server , it's required to send a JWT Token for queries. to get a JWT token, call the Login Mutation with email and password ( take a look at loadData() function inside src/index.ts to see how it works) and you will get a valid JWT Token that should be send in the header following the format Bearer xxx_token. Take a look at this Post to have more details.

You can navigate to the Performance tab to monitor and measure important metrics such as the FCP (First Contentful Paint), latency or downtime of any API requests, etc.

And that's is. Your server is now up and running with Sentry SDK well configured ✅

Thanks for reading, the source code is available here.

Follow me on socials media to stay up to date with latest posts.

As covered in other post on this blog, Apollo is a platform that allows you to build scalable and robust web/Mobile application by providing you everything you need for client and server when using GraphQL, a query language for data fetching. The image bellow briefly describe it.

In this blog post, we will work on the server part and will focus how to improve a Node.js GraphQL server by adding some customs features using Plugins.

1. What are plugins

In computer science and software development, plugins are software additions that helps to customize programs, apps, and web browsers.

For Apollo, Plugins extend Apollo Server's functionality by performing custom operations in response to certain events. These events correspond to individual phases of the GraphQL request lifecycle, and to the lifecycle of Apollo Server itself.

A basic example can be one that perform an action before server start. To do this, we will override the serverWillStart event.

const myPlugin = {
  async serverWillStart() {
    console.log('Server starting up!');
  },
};

when there are well used, plugins can behave like middleware where you perform some actions before or after certain events.

To understand how plugins works and how we can create customs ones, it is really important to understand GraphQL request lifecycle methods.

The following diagram illustrates the sequence of events that fire for each request. Each of these events is documented in Apollo Server plugin events and available on apollo website.

So you will be able to create plugins that perform some actions for each of theses specifics operations. To learn more about each of theses methods(), you can read more here.

2. Setup

For this implementation, we will use a ready to use node.js graphql server we built on another post. So we will fetch the source code that run a graphQL server with mocked data and JWT configured for authorization.

Since the directory containing the initial setup is part of a repository that host multiples tutorials source code each on a single folder, we will only clone the one with the initial setup we need to get start. Follow the folling steps from the terminal.

git clone --no-checkout https://github.com/Doha26/fullstack-hebdo-posts.git

cd fullstack-hebdo-posts

git sparse-checkout init --cone

git sparse-checkout set  04-nodejs-graphql-apollo-plugins

And now inside the folder, install node dependencies and start the server

 cd 04-nodejs-graphql-apollo-plugins && yarn && yarn start:dev

you will see the following output

3. Create apollo plugin

From the terminal, install apollo-server-plugin-base with yarn add apollo-server-plugin-base This lib will give us access to some Object  required for graphql server Lifecycle Event methods

Create a folder called utils inside src folder and add a file called plugin.ts

Inside this file, add the following code to create a Custom Apollo Server plugin.

import { GraphQLSchema } from 'graphql'
import {
  ApolloServerPlugin,
  BaseContext,
  GraphQLRequestContext,
  GraphQLRequestExecutionListener,
  GraphQLRequestListener,
  GraphQLRequestListenerParsingDidEnd,
  GraphQLRequestListenerValidationDidEnd,
  GraphQLResponse
} from 'apollo-server-plugin-base'

export class CustomApolloServerPlugin implements ApolloServerPlugin {
  public serverWillStart(): any {
    console.info('- Inside serverWillStart')
  }

  public requestDidStart(): Promise<GraphQLRequestListener<BaseContext>> | any {
    const start = Date.now()
    let variables: any = null
    return {
      didResolveOperation: (): Promise<void> | any => {
        console.info('- Inside didResolveOperation')
      },
      willSendResponse(requestContext: GraphQLRequestContext) {
        const stop = Date.now()
        const elapsed = stop - start
        const size = JSON.stringify(requestContext.response).length * 2
        console.info(
          `operation=${requestContext.operationName},
             duration=${elapsed}ms,
             bytes=${size},
             query=${requestContext.request.query}
             variables:${JSON.stringify(variables)},
             user=${JSON.stringify(requestContext.context.user)}
             responseData=${JSON.stringify(requestContext.response?.data)},
             `
        )
      },
      didEncounterErrors(requestContext: GraphQLRequestContext) {}
    }
  }

  /**
   * Request Lifecycle Handlers
   */

  public parsingDidStart(context: GraphQLRequestContext): Promise<GraphQLRequestListenerParsingDidEnd | void> | any {
    console.info('- Inside parsingDidStart', JSON.stringify(context))
  }

  public validationDidStart(
    context: GraphQLRequestContext
  ): Promise<GraphQLRequestListenerValidationDidEnd | void> | any {
    console.info('- Inside validationDidStart', JSON.stringify(context))
  }

  public didResolveOperation(context: GraphQLRequestContext): Promise<void> | any {
    console.info('- Inside didResolveOperation', JSON.stringify(context))
  }

  public responseForOperation(context: GraphQLRequestContext): GraphQLResponse | any {
    console.info('- Inside responseForOperation', JSON.stringify(context))
    return null
  }

  public executionDidStart(context: GraphQLRequestContext): Promise<GraphQLRequestExecutionListener | void> | any {
    console.info('- Inside executionDidStart', JSON.stringify(context))
  }

  public didEncounterErrors(context: GraphQLRequestContext): Promise<void> | any {
    console.info('- Inside didEncounterErrors', JSON.stringify(context))
  }

  public willSendResponse(context: GraphQLRequestContext): Promise<void> | any {
    console.info('- Inside willSendResponse', JSON.stringify(context))
  }
}

Once done, open src/index.ts file and add the following to enable the plugin.

const server = new ApolloServer({
    schema,
    context: async ({ req, res }): Promise<AppContext | null> => {
       // ...
    },
    plugins: [new CustomApolloServerPlugin()] // NEW 
  })

And that's all. Now if the server is running, you should be able to see the following ouput from the console

which refer to this in our plugin class

4. Let's explain some of theses lifecycle methods and actions that can be handle for each

For better understanding on how it can be useful to configure a Custom Apollo plugin, let's explain (According to apollo) what is behind the scenes of theses methods.

• serverWillStart():  This method is triggered when te apollo server is ready to start. At this level, it would be interesting to make sure that all your production secret keys (.env VARIABLES )  have been loaded. Otherwise, raise an error

• requestDidStart(): Triggered at the beginning of every request cycle, and returns an object (GraphQLRequestListener) that has the functions for each request lifecycle event (didResolveOperation(), willSendResponse(), etc ..)

• didResolveOperation(context: GraphQLRequestContext): This event fires after the graphql library successfully determines the operation to execute from a request's document AST (Abstract Syntax Tree). At this stage, both the operationName string and operation AST are available. the @param context argument expose following items.  metrics | source | document | operationName | operation

• willSendResponse(requestContext: GraphQLRequestContext): The  event fires whenever Apollo Server is about to send a response for a GraphQL operation. This event fires (and Apollo Server sends a response) even if the GraphQL operation encounters one or more errors. The @param context argument provide following items: metrics | response

• didEncounterErrors(requestContext: GraphQLRequestContext): The didEncounterErrors event fires when Apollo Server encounters errors while parsing, validating, or executing a GraphQL operation. The @param context argument provide following items: metrics | source | errors . Here could be the good place to send the error to your favorite error tracking platform (Bugsnag, sentry, firebase, etc ...). We will see how to do this in another blog post.

• parsingDidStart(context: GraphQLRequestContext): This event fires whenever Apollo Server will parse a GraphQL request to create its associated document AST (Abstract Syntax Tree). If Apollo Server receives a request with a query string that matches a previous request, the associated document might already be available in Apollo Server's cache. In this case, parsingDidStart is not called for the request, because parsing does not occur. The @param context argument provide following items:  metrics | source

• validationDidStart(context: GraphQLRequestContext  ): This event fires whenever Apollo Server will validate a request's document AST against your GraphQL schema. Like parsingDidStart, this event does not fire if a request's document is already available in Apollo Server's cache. (only successfully validated documents are cached by Apollo Server). The document AST is guaranteed to be available at this stage, because parsing must succeed for validation to occur. The @param context argument provide following items:  metrics | source | document

• responseForOperation(context: GraphQLRequestContext): This event is fired immediately before GraphQL execution would take place. If its return value resolves to a non-null GraphQLResponse, that result is used instead of executing the query. Hooks from different plugins are invoked in series and the first non-null response is used. The @param context argument provide following items:  metrics | source | document | operationName | operation

• executionDidStart(context: GraphQLRequestContext): This event fires whenever Apollo Server begins executing the GraphQL operation specified by a request's document AST. The @param context argument provide following items: metrics | source | document | operationName | operation

Thanks for reading, the source code is available here.

Follow me on socials media to stay up to date with latest posts.  

In a previous post, we have seen how to create a GraphQL server using Node.js, Apollo, and Type-graphql. Now the server is ready to accept queries, we will add a secure layer to avoid our server to handle non-authorized requests.

1. Why is it important to secure 🤨 ?

Servers play a vital role in organizations. Their primary function is to provide both data and computational services. Imagine you build and deploy an app that fetches data, private information, and sensitive user information from your server, and everyone can access these informations only once having your server endpoint? it would be catastrophic for your organization because Security vulnerabilities can lead to the loss of critical data or loss of capability and control that can jeopardize the whole organization. So If you do not secure your servers, then you are treading a dangerous path.

2. What is JWT 🤔 ?

JWT stand for Json Web Token. According to jwt.io (JWT Official website), JSON Web Token (JWT) is an open standard (RFC 7519) that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (with the HMAC algorithm) or a public/private key pair using RSA or ECDSA.

Although JWTs can be encrypted to also provide secrecy between parties, we will focus on signed tokens. Signed tokens can verify the integrity of the claims contained within it, while encrypted tokens hide those claims from other parties. When tokens are signed using public/private key pairs, the signature also certifies that only the party holding the private key is the one that signed it.

Here are some scenarios where JSON Web Tokens are useful:

• Authorization: This is the most common scenario for using JWT. Once the user is logged in, each subsequent request will include the JWT, allowing the user to access routes, services, and resources that are permitted with that token. Single Sign On is a feature that widely uses JWT nowadays, because of its small overhead and its ability to be easily used across different domains.
• Information Exchange: JSON Web Tokens are a good way of securely transmitting information between parties. Because JWTs can be signed—for example, using public/private key pairs—you can be sure the senders are who they say they are. Additionally, as the signature is calculated using the header and the payload, you can also verify that the content hasn't been tampered with

In its compact form, JSON Web Tokens consist of three parts separated by dots (.), which are:

• Header: Contains information about the token type and the algorithm used to sign the token (for example, HS256)
• Payload: Contains claims about a particular entity. These statements may have predefined meanings in the JWT specification (known as registered claims) or they can be defined by the JWT user (known as public or private claims)
• Signature: Helps to verify that no information was changed during the token’s transmission by hashing together the token header, its payload, and a secret

Therefore, a JWT will have the pattern  xxxxx.yyyyy.zzzzz and will looks like the following

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwczovL2Jsb2cuZm91amV1cGF2ZWwuY29tIjp7InJvbGVzIjpbImFkbWluIl0sInBlcm1pc3Npb25zIjpbInJlYWQ6cXVlcnlfc3BlYWNrZXJzIiwicmVhZDpxdWVyeV9zcGVhY2tlciIsInJlYWQ6cXVlcnlfZXZlbnRzIiwicmVhZDpxdWVyeV9ldmVudCIsInJlYWQ6bXV0YXRpb25fbG9naW4iXX0sImlhdCI6MTU4NjkwMDI1MSwiZXhwIjoxNjUxMjc5MTIzLCJzdWIiOiJmYWtlX3N1YmplY3QifQ.nAkH-LoA9g7-iWwJjaV3BpJXG_pB7N6jthhn739INCc

The header section of the above token would decode to:

{
  "alg": "HS256",
  "typ": "JWT"
}

And the payload section would decode as follows:

{
  "https://blog.foujeupavel.com": {
    "roles": [
      "admin"
    ],
    "permissions": [
    "read:query_speackers",
    "read:query_speacker",
    "read:query_events",
    "read:query_event",
    "read:mutation_login"
    ]
  },
  "iat": 1586900251,
  "exp": 1651279123,
  "sub": "fake_subject"
}

For more information, take a look at jwt.io/introduction 😉

3. Setup

In this post, we will implement JWT authorization on a ready-to-use Graphql server we build in my other post. The source code is available here on GitHub. Just clone and run it locally to get started.  From your favorite terminal, run the following.

Let's clone the directory containing the initial setup

Since the directory containing the initial setup is part of a repository that hosts multiple tutorials source codes each on a single folder, we will only clone the one with the initial setup we need to get started. Follow the following steps from the terminal.

git clone --no-checkout https://github.com/Doha26/fullstack-hebdo-posts.git

cd fullstack-hebdo-posts

git sparse-checkout init --cone

git sparse-checkout set  03-nodejs-graphql-jwt

And now inside the folder, install node dependencies and start the server

 cd 03-nodejs-graphql-jwt && yarn && yarn start:dev

you will see the following output

4. Let's implement JWT.

For now, our server just exposes a list of events and speakers of the events and their corresponding locations. Actually, everyone can query the server. Now we will add subscribers and only allow them to query events and speakers.  

A subscriber's object can have an ID, email, phone number, password, and address.

So we will have the following:

• A subscriber will log in through a login mutation by providing an email and password
• the server will search among users in a mocked array ready on the server and if there is a user with credentials matching the email/password pair provided by the user, the server will generate a token for the user to query the server and return it back on the login mutation response.
• The user will use this token  (if still valid) to query the server and access the list of events and speakers

open src/types.ts and add the following:

@ObjectType({ description: 'Subscriber object' })
export class Subscriber {
  @Field() ID: string
  @Field() name: string
  @Field() phoneNumber: string
  @Field() email: string
  @Field() password: string
  @Field(_type => Location) address: Location
}

@ObjectType({ description: 'Login Response object' })
export class LoginResponse {
  @Field() accessToken: string
  constructor(accessToken: string) {
    this.accessToken = accessToken
  }
}

Inside src/index.ts update loadData() function and add following code to mock Subscribers' data:

// Mock subscribers
  const su1 = new Subscriber()
  su1.ID = '7dd8716b-3fea-46f0-8826-264300557ae2'
  su1.address = l1
  su1.name = 'Jim Coknag'
  su1.email = 'jim.cok@gmail.com'
  su1.password = 'texas90'
  su1.phoneNumber = '+33 6077654543'

  const su2 = new Subscriber()
  su2.ID = '1dce60a4-9761-11ec-b909-0242ac120002'
  su2.address = l2
  su2.email = 'tom.quirk@outlouk.com'
  su2.name = 'Tom QuirkMan'
  su2.password = 'axjkjgdtrfd#400'
  su2.phoneNumber = '+1-202-555-0100'

  const su3 = new Subscriber()
  su3.ID = '9118556a-9761-11ec-b909-8842ac120002'
  su3.address = l3
  su3.name = 'Pavel Foujeu'
  su3.email = 'f.pavel@gmail.com'
  su3.password = '123456FAKE'
  su3.phoneNumber = '+1-202-555-0166'
  
  // ...
  data.subscribers = [su1, su2, su3]

Inside src/shared.ts add the following variable at the top of the file. This will be the SECRET KEY we will use to sign the JWT token that will be sent to the user. For this post, we will keep it inside the resolver class, but in a real-world scenario, secrets should be kept inside a non-versioned .env file. You can see how to easily manage your .env file in my dedicated post available here.

export const jwtSecretKey = 'KSSLJFLKNDJBNFJBDHBKDJBKBD' // Fake SECRET KEY. To be stored in .env file

Inside  src/resolver.ts file, add the following queries for subscribers

 @Query(() => [Subscriber])
  getSubscribers(@Ctx() { db }: AppContext): Subscriber[] | undefined {
    return db.data?.subscribers
  }
  
  @Query(() => Subscriber)
  getSubscriber(@Arg('id', () => String) id: string, @Ctx() { db }: AppContext): Subscriber | undefined {
    return db.data?.subscribers?.find((subscriber: Subscriber) => subscriber.ID === id)
  }

We need to install  jsonwebtoken to sign the token. In the terminal, add the following: yarn add jsonwebtoken @types/jsonwebtoken

 @Mutation(() => LoginResponse, { nullable: true })
  login(
    @Arg('email', () => String) email: string,
    @Arg('password', () => String) password: string,
    @Ctx() { db }: AppContext
  ): LoginResponse | null {
    const user = db.data?.subscribers?.find(
      (subscriber: Subscriber) => subscriber.email === email && subscriber.password === password
    )
    if (user) {
      return new LoginResponse(
        jwt.sign(
          {
            'https://blog.foujeupavel.com': {
              roles: ['admin'],
              permissions: [
                'read:query_speackers',
                'read:query_speacker',
                'read:query_events',
                'read:query_event',
                'read:mutation_login'
              ]
            }
          },
          jwtSecretKey,
          { algorithm: 'HS256', subject: user.ID, expiresIn: '1d' }
        )
      )
    }
    return null
  }

With the server running, open apollo sandbox to test all this.

• Get Subscribers

• Login user with email/password

We’ll paste the returned token into the “HTTP Headers” panel of GraphQL Playground as follows:

{
  "Authorization": "Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJodHRwczovL2Jsb2cuZm91amV1cGF2ZWwuY29tIjp7InJvbGVzIjpbImFkbWluIl0sInBlcm1pc3Npb25zIjpbInJlYWQ6cXVlcnlfc3BlYWNrZXJzIiwicmVhZDpxdWVyeV9zcGVhY2tlciIsInJlYWQ6cXVlcnlfZXZlbnRzIiwicmVhZDpxdWVyeV9ldmVudCIsInJlYWQ6bXV0YXRpb25fbG9naW4iXX0sImlhdCI6MTY0NTkzMDM1MywiZXhwIjoxNjQ2MDE2NzUzLCJzdWIiOiI5MTE4NTU2YS05NzYxLTExZWMtYjkwOS04ODQyYWMxMjAwMDIifQ.tWyHd2xA1LiZPy1Vt-R9l9V8Nb8qh6pM-cXwI-UV2uE"
}

Next, we’ll install Express middleware that verifies and decodes the JWT when it’s sent with requests from GraphQL Playground: yarn add express-jwt

Then we’ll add the middleware to the index.js file, using the same secret that was used to sign the JWT in the mutation, choosing the same signing algorithm, and setting the credentialsRequired option to false so Express won’t throw an error if a JWT hasn’t been included (which would be the case for the initial login mutation or when GraphQL Playground polls for schema updates):

Update src/types.ts and update AppContext type with the following

interface JWTClaim { // NEW 
  [key: string]: {
    roles: string[]
    permissions: string[]
  }
}
export type AppContext = {
  req: Request
  res: Response
  db: Low<JsonData>
  user:
    | (JWTClaim & {
        sub: string
        iat: number
        exp: number
      })
    | Express.User
    | null
}

Update src/index.ts and add the following:

//...
import expressJwt from 'express-jwt'
import { jwtSecretKey } from './shared'
import expressJwt, { UnauthorizedError } from 'express-jwt'

//... Inside bootstrap() function 

 app.use( // NEW 
    expressJwt({
      secret: jwtSecretKey,
      algorithms: ['HS256'],
      credentialsRequired: false
    })
  )

// ... 

const server = new ApolloServer({
    schema,
    context: async ({ req, res }): Promise<AppContext> => {
      const user = req.user || null // NEW
    if (!req.body.query.trim().startsWith('query IntrospectionQuery')) {
        if (req.body.operationName !== 'login') {
          if (!user)
            throw new UnauthorizedError('Invalid_token', {
              message: 'Unauthorized : Invalid or Expired JWT Token provided !'
            })
        }
      }
      return {
        req,
        res,
        db,
        user // NEW
      }
    }
  })

The middleware added to Express will get the token from the Authorization header, decode it, and add it to the request object as req.user. It’s a common practice to add decoded tokens to Apollo Server’s context because the context object is conveniently available in every resolver and it’s recreated with every request.

To avoid even the login mutation that allows the user to get a JWT, the code below has been added to not throw an error if there is no req.user . This way, the login mutation can be called each time needed with corresponding credentials and return a valid accessToken.

if (!req.body.query.trim().startsWith('query IntrospectionQuery')) {
        if (req.body.operationName !== 'login') {
          // ...
        }
      }

Now if you query the server with an INVALID or NO TOKEN in the Header section of the request, you will have the following

And if you provide a valid token following the pattern Authorization: Bearer accessToken, you will get a response.

And that's it. Your server is now up and running with JWT well configured ✅

Thanks for reading, the source code is available here.

Follow me on social media to stay up to date with latest posts.  

According to their documentation, Apollo is a platform for building a unified graph, a communication layer that helps you manage the flow of data between your application clients (such as web and native apps) and your back-end services. At the heart of the graph is a query language called GraphQL.

The platform is Divided into 3 main parts.

• Apollo Clients : it's a set of client libraries that allows you to build awesome frontend apps using React, iOS, Kotlin with Apollo.
• Apollo Backend :  It's Includes a set of tools developed for building backends using Apollo server, Apollo Federation, Apollo Router.
• Apollo tools : It's Includes a set of tools to enhance your GraphQl Backends and monitor your schema metrics. i will write another post to focus on how to use Rover CLI and Apollo Studio.

Since this post is not focus on presenting the Apollo platform, i will only focus on using GraphQL Backend with Apollo Server.

2. Apollo Server

Apollo Server is an open-source, spec-compliant GraphQL server that's compatible with any GraphQL client. It's the best way to build a production-ready, self-documenting GraphQL API that can use data from any source. apollo server can be used as :

• A stand-alone GraphQL server, including in a serverless environment
• An add-on to your application's existing Node.js middleware
• A gateway federated graph

In this post, we will use Apollo server version 3

3. TypeGraphQL

TypeGraphQL is a set of useful features, like validation, authorization and dependency injection, which helps develop GraphQL APIs quickly & easily! I will Cover Typegraphql features in another post. Basically, it allows your to build a graphQl schema by defining classes and a bit of decorators. We will see how to do that.

4. Setup 🏄🏻‍♂️

In this post i will use typescript with this open source  node-typescript-starter project for our purposes.

• Open your favorite terminal and clone the starter template with git clone https://github.com/stemmlerjs/simple-typescript starter.git your_project_name  and cd your_project_name
• Install node dependencies with npm install if you are using npm and yarn add if you are using YARN as a package manager. In this post we will use yarn so you will need to delete the package-lock.json at the root folder to avoid conflict with yarn 's -lock.json file.
• Then in the terminal , npm start You should be able to see the output

• install apollo-server-express (we will be using apollo-server with the express package ) and typegraphql with yarn add graphql@15.5.0 express class-validator reflect-metadata type-graphql apollo-server-express

Once done, we are good to go 👨‍💻

5. Todolist 📃

In this post, we are going to build a backend that expose a GraphQL API showing a list of  Events and related informations. Here are some specs

• Each event has a name, a place where it will take place, a number of available places, a list of speakers, a date and a rating given by subscribers.
• Each speacker has a name, a phone number, a mail address,  a list of topics he will cover
• A speacker can attend several events (Not at the same time)

Thus, the API should be able to :

• List all events and give details for each of them (speackers, rating, etc)
• List all speackers
• Show details about a specific Event or speaker.

To go fast, We are not going to setup a real database but will use LowDB, a tiny in-memory database with typescript support to persist data in a .json file.

To be simple without making a relational database, we will have the following objects:

6. Let's create the server.

create 3 typescript (.ts) files inside the src folder :

• index.ts : this will be the entry point of our graphql server where we will bootstrap our server
• types.ts : this file will contain all our typegraphql class that will be serialized and stored  as json objects.
• resolver.ts : This file will be our resolver where we will define queries

6.1 types.ts 📝

Inside this file, add the following :

import { Field, ObjectType, Int, registerEnumType } from 'type-graphql'

export enum EventStatus {
  PASSED,
  PENDING,
  UPCOMMING
}

registerEnumType(EventStatus, {
  name: 'EventStatus',
  description: 'EventStatus type'
})

@ObjectType({ description: 'Location object' })
export class Location {
  @Field() ID: string
  @Field() city: string
  @Field() country: string
  @Field() postalCode: number
}

@ObjectType({ description: 'Speaker object' })
export class Speaker {
  @Field() ID: string
  @Field() name: string
  @Field() phoneNumber: string
  @Field() email: string
  @Field(_type => [String]) topics: Array<string>
  @Field(_type => [String]) events: Array<string>
}

@ObjectType({ description: 'Subscriber object' })
export class Subscriber {
  @Field() ID: string
  @Field() name: string
  @Field() phoneNumber: string
  @Field() email: string
  @Field(_type => Location) address: Location
}

@ObjectType({ description: 'Event object' })
export class Event {
  @Field() ID: string
  @Field() name: string
  @Field(_type => Location) address: Location
  @Field(_type => EventStatus) status: EventStatus
  @Field(_type => Int) availableplace: number
  @Field(_type => Int) rating: number
  @Field(_type => [Speaker]) speakers: Array<Speaker>
}

6.2 resolver.ts 📝

To get started, we will add a basic query to retrieve empty events array . to do so, add the following inside.

import { Query, Resolver } from 'type-graphql'
import { Event } from './types'

@Resolver()
export default class EventResolver {
  @Query(() => [Event])
  getEvents(): Event[] {
    return []
  }
}

Let's give some explanations.

Typegraphql use decorators for class and field properties to perform some actions.  Everything about typegraphql will be covered in another blog post.  for the previous bloc, we have:

• @Resolver() : this  decorator make a class that will behave like a controller from classic REST frameworks
• @Query() : this decorator above a function specify that the function is a Query typegraphql also provide @Mutation() for mutations
• @Subscription() for subscriptions. A decorator can take an argument where to specify the return type of the function. For getEvents() , the function will return an array of Event

6.3 index.ts  📝

import 'reflect-metadata' // Important
import express from 'express'
import { ApolloServer } from 'apollo-server-express'
import EventResolver from './resolver'
import { buildSchema } from 'type-graphql'

// Set a default port to 4000
const PORT = process.env.PORT || 4000

// Bootstrap the server
const bootstrap = async () => {
  const schema = await buildSchema({ resolvers: [EventResolver] })
  const app = express()
  const server = new ApolloServer({ schema })
  await server.start()
  server.applyMiddleware({ app })
  app.listen(PORT, () => console.log(`🚀 GraphQL server ready at http://localhost:${PORT}`))
}
bootstrap().catch(error => console.log(error))

And at this point, everything is ready to start the server with yarn start:dev inside the terminal. We will have the following output.  

This means our server is ready and will accept request coming from the default port. To be sure our server works well,  open http://localhost:4000/graphql  in the browser, and you will be be able to see the apollo's v3 default landing page.

We're up and running!

Hit the "Query your server" button and you will be redirected to Apollo studio sandbox.

As we now have a single query named getEvents(), It will be listed as in the screen. You can play with the sand box and see how it works.  Since Apollo Studio is a great tools to manage graphql schema, i will cover it in another post.

7. Setup LowDB

As said previously, lowdb is a widely used json database. The library is  a pure ESM package, so cannot be imported with our current project setup which output commonjs. To configure our project to use lowdb, we can update our project configs to output ESM with following.

• Install lowdb with yarn add lowdb
• Add following lines inside  tsconfig.json file  in compilerOptions

"module": "ES2020",
"moduleResolution": "node",

• Add following inside package.json file

  "type": "module",

• Update ts-node package and install 10.x.x version that have  esm support.  In my case i have  ts-node v10.4.0
• Update the exec script inside nodemon.json file at the root with node --loader ts-node/esm --experimental-specifier-resolution=node ./src/index.ts
• Restart the server with yarn start:dev everything should now works fine.

8. Update server

At this step, our server is ready to work with lowDb. Now we will setup our JSON database with some mocked data.

• Update index.ts file and ad the following code

import 'reflect-metadata' // Important
import express from 'express'
import { Low, JSONFile } from 'lowdb'
import { ApolloServer } from 'apollo-server-express'
import EventResolver from './resolver'
import { buildSchema } from 'type-graphql'
import { AppContext, Event, EventStatus, JsonData, Location, Speaker } from './types'

// Set a default port to 4000
const PORT = process.env.PORT || 4000

const loadData = (): JsonData => {
  const data: JsonData = {}

  // Mock locations
  const l1 = new Location()
  l1.ID = '9f9471dc-87bc-11ec-a8a3-0242ac120002'
  l1.country = 'England'
  l1.city = 'London'
  l1.postalCode = 5208

  const l2 = new Location()
  l2.ID = 'e3098c76-87bd-11ec-a8a3-0242ac120002'
  l2.country = 'France'
  l2.city = 'Paris'
  l2.postalCode = 75000

  const l3 = new Location()
  l3.ID = 'db6c8478-87bd-11ec-a8a3-0242ac120002'
  l3.country = 'US'
  l3.city = 'San Francisco, CA'
  l3.postalCode = 94016

  const l4 = new Location()
  l4.ID = 'e8e94ae6-87bd-11ec-a8a3-0242ac120002'
  l4.country = 'Spain'
  l4.city = 'Barcelona'
  l4.postalCode = 8001

  // Mock speakers
  const s1 = new Speaker()
  s1.ID = 'da554858-87be-11ec-a8a3-0242ac120002'
  s1.name = 'Tom kirke'
  s1.phoneNumber = '+44 2045772856'
  s1.email = 'kirke.tom@gmail.com'
  s1.address = l1
  s1.topics = ['GraphQL', 'Docker', 'Typescript', 'React', 'Jamstack']

  const s2 = new Speaker()
  s2.ID = 'da553d18-87be-11ec-a8a3-0242ac120002'
  s2.name = 'Manu Kholns'
  s2.phoneNumber = '+33 678554412'
  s2.email = 'k.manu06@outlook.com'
  s2.address = l2
  s2.topics = ['Node', 'Docker', 'Python', 'CI/CD', 'REST']

  const s3 = new Speaker()
  s3.ID = 'da553c0a-87be-11ec-a8a3-0242ac120002'
  s3.name = 'Adams Renols'
  s3.phoneNumber = '+14844608120'
  s3.email = 'renols.adams@gmail.com'
  s3.address = l3
  s3.topics = ['Docker', 'Kubernetes', 'G-Cloud', 'AWS', 'Devops']

  const s4 = new Speaker()
  s4.ID = 'da55387c-87be-11ec-a8a3-0242ac120002'
  s4.name = 'Franck Zein'
  s4.phoneNumber = '+33 687445512'
  s4.email = 'franck.z@gmail.com'
  s4.address = l4
  s4.topics = ['React', 'Angular', 'Python', 'AWS']

  //Mock events
  const e1 = new Event()
  e1.ID = '7b9b0eb2-87bc-11ec-a8a3-0242ac120002'
  e1.name = 'GraphQL Submit 2022'
  e1.date = '2022-03-07T03:52:44+01:00'
  e1.status = EventStatus.UPCOMING
  e1.availableplaces = 310
  e1.rating = 4
  e1.address = l1
  e1.speakers = [s1, s2]

  const e2 = new Event()
  e2.ID = '7b9b110a-87bc-11ec-a8a3-0242ac120002'
  e2.name = 'Over React-ed 2021'
  e2.date = '2021-11-12T11:30:44+01:00'
  e1.availableplaces = 270
  e2.status = EventStatus.PASSED
  e2.rating = 4
  e2.address = l2
  e2.speakers = [s1, s2, s3]

  const e3 = new Event()
  e3.ID = '7b9b14ca-87bc-11ec-a8a3-0242ac120002'
  e3.name = 'Devops Next Gen'
  e3.date = '2022-05-12T11:30:44+01:00'
  e1.availableplaces = 412
  e3.status = EventStatus.UPCOMING
  e3.rating = 4
  e3.address = l4
  e3.speakers = [s1, s2, s3]

  //Create DB Data
  data.locations = [l1, l2, l3, l4]
  data.speakers = [s1, s2, s3, s4]
  data.events = [e1, e2, e3]

  return data
}
const setupDb = async (): Promise<Low<JsonData>> => {
  const adapter = new JSONFile<JsonData>('db.json')
  const db = new Low(adapter)
  await db.read()
  db.data = loadData()
  await db.write()
  return db
}

// Bootstrap the server
const bootstrap = async () => {
  const db = await setupDb()
  const schema = await buildSchema({ resolvers: [EventResolver] })
  const app = express()
  const server = new ApolloServer({
    schema,
    context: async ({ req, res }): Promise<AppContext> => {
      return {
        req,
        res,
        db
      }
    }
  })
  await server.start()
  server.applyMiddleware({ app })
  app.listen(PORT, () => console.log(`🚀 GraphQL server ready at http://localhost:${PORT}/graphql`))
}
bootstrap().catch(error => console.log(error))

Let's explain theses updates. we added two functions:

• loadData() which is a function that mock some demo data for locations, speakers, and events.
• setupDb() which setup lowDb and load mocked datas into it. Thus, we will be able to query theses data in our resolvers functions

Add two custom types inside type.ts file

export type JsonData = {
  events?: Event[]
  speakers?: Speaker[]
  subscribers?: Subscriber[]
  locations?: Location[]
}

export type AppContext = {
  req: Request
  res: Response
  db: Low<JsonData>
}

• Inside resolver.ts add resolver functions to get events and speackers

import { Arg, Ctx, Query, Resolver } from 'type-graphql'
import { AppContext, Event, Speaker } from './types'

@Resolver()
export default class EventResolver {
  @Query(() => [Event])
  getEvents(@Ctx() { db }: AppContext): Event[] | undefined {
    return db.data?.events
  }

  @Query(() => Event)
  getEvent(@Arg('id', () => String) id: string, @Ctx() { db }: AppContext): Event | undefined {
    return db.data?.events?.find((event: Event) => event.ID === id)
  }

  @Query(() => [Speaker])
  getSpeakers(@Ctx() { db }: AppContext): Speaker[] | undefined {
    return db.data?.speakers
  }

  @Query(() => Event)
  getSpeaker(@Arg('id', () => String) id: string, @Ctx() { db }: AppContext): Speaker | undefined {
    return db.data?.speakers?.find((speaker: Speaker) => speaker.ID === id)
  }
}

And here, everything is ready. But before querying our server, let’s  explain what one of theses functions does. getEvents() function for example.

@Query(() => [Event])
  getEvents(@Ctx() { db }: AppContext): Event[] | undefined {
    return db.data?.events
  }

There is not a lot to say here, we just passed the db instance through the context and got it using @Ctx() decorator. And next, we just return all events.  

9. let's test it all.

Open apollo studio sandbox at localhost:4000/graphql and query the server.

and here we have the result on this screen.

• section 1 : this bloc display all queries, mutations, subscriptions you write inside your resolver class with description about each functions, fields and types
• section 2: this section is where you write your request query, mutation or subscription
• section 3: this section will just display the result.

Thanks for reading, the source code is available here.

Follow me on socials media to stay up to date with latest posts.  

A .env or dotenv file of an app is a text file that contains environment-specific configurations. Most of the time between Local, Staging, and Production environments, your app will need to behave visually the same but behind the scenes, each of these environments can be configured with different keys, constants, API Keys, etc.

2. what a .env file looks like

As I previously said,  a .env file is a text file, containing lines of declaration where each declaration represent a single variable. It is conventionally advised to set each variable name inside the file with uppercase words separated by an underscore ( _ ), follow with  =   (without space) by the value. Here is an example:

VARIABLE_NAME=value

3. Access it in a Node.js app

In Node.Js, there is an object called process which is a global that provides information about, and control over, the current Node.js process. As a global, it is always available to Node.js applications without using require() or import. So in Node.js, you will need to write process.env.VARIABLE_NAME to access the value set in the .env file.

So is it possible to access configurations variables with the process object, what is the purpose of ENVALID ? 🤔

According to Envalid README file, Envalid is a small library for validating and accessing environment variables in Node.js (v8.12 or later) programs, aiming to:

• ensure that your program only runs when all of its environment dependencies are met
• give you executable documentation about the environment your program expects to run in
• give you an immutable API for your environment variables, so they don't change from under you while the program is running.

4. Setup 🏄🏻‍♂️

In this post, i will use typescript with this open-source node-typescript-starter project to show you how it works.

• Open your favorite terminal and clone the starter template with git clone https://github.com/jsynowiec/node-typescript-boilerplate.git your_project_name  and cd your_project_name
• Install node dependencies with npm install. If you are using YARN as a package manager, you will need to delete the package-lock.json at the root folder to avoid conflict with yarn's -lock.json file.
• Delete the following block inside the package.json (starting at line 5) file to remove targeting a specific node.js version. In this post, we will just focus on looking at how Envalid works.

 "engines": {
    "node": ">= 16.13 <17"
  },

• We will also need to install, a useful package that will restart the server each time a file changes and ts-node  a typescript execution engine for node.  So npm install --save-dev nodemon ts-node  
• replace start script inside package.json with the following to add nodemon.

 "start": "npm run build && nodemon build/src/main.js",

• then in the terminal, npm start You should be able to see the output.

Now call the default greeter(name:string) a function that returns a Promise with

greeter('James Bond').then((result) => console.log(result));

this will automatically trigger a build and print Hello, James Bond in the terminal

[nodemon] clean exit - waiting for changes before restart
[nodemon] restarting due to changes...
[nodemon] starting `ts-node src/main.ts`
[nodemon] restarting due to changes...
[nodemon] starting `ts-node src/main.ts`
Hello, James Bond
[nodemon] clean exit - waiting for changes before restart

5. Adding .env 🤾🏼‍♂️

For this app, we will implement something very simple. The app will be a simple one with the main function that displays in the console the redirection link corresponding to a specific user of an array according to its ROLE if we

create a .env file at the root of the folder and add it to .gitignore file. For this post, let's consider our app will store 3 variables, that are:  

• ADMIN_REDIRECT_URL=/v1/custom/path/admin/login  which is where to redirect the user if it's an admin.
• DEFAULT_REDIRECT_URL=/v1/custom/path/user/login  which is the default redirect url for users
• DASHBORD_BASE_URL=https://your_appname.com

Your .env file should look like this

ADMIN_REDIRECT_URL=/v1/custom/path/admin/login
DEFAULT_REDIRECT_URL=/v1/custom/path/user/login
DASHBORD_BASE_URL=https://your_appname.com # REPLACE THIS WITH ANY URL 

Now let's access these variables in our app.

install Envalid with npm install envalid or yarn add envalid if you are using yarn.

create a new file env.ts inside the src folder and add the following code.

import { cleanEnv, str } from 'envalid';
const env = cleanEnv(process.env, {
  ADMIN_REDIRECT_URL: str({ default: 'any_default_url' }),
  DEFAULT_REDIRECT_URL: str({ default: 'any_default_url' }),
  DASHBORD_BASE_URL: str({ default: 'any_default_url' }),
});
export default env;

replace the code inside main.ts file with the following :

import env from './env';

enum UserType {
  admin,
  customer,
}
interface User {
  name: string;
  role: UserType;
}
const users = [
  { name: 'John do', role: UserType.admin },
  { name: 'Marc Vince', role: UserType.customer },
  { name: 'Stephen Huke', role: UserType.admin },
];

const printHello = (user: User): string => {
  const { name, role } = user;
  if (role === UserType.admin) {
    return `Hello ${name}! , Your login URL is: ${env.DASHBORD_BASE_URL}${env.ADMIN_REDIRECT_URL}`;
  }
  return `Hello ${name}! , Your login URL is: ${env.DASHBORD_BASE_URL}${env.DEFAULT_REDIRECT_URL}`;
};

const start = () => {
  users.forEach((user) => {
    console.log(printHello(user));
  });
};

start();

This will print the following in the console :

[nodemon] starting `ts-node src/main.ts`
Hello John do! , Your login URL is: https://your_appname.com/v1/custom/path/admin/login
Hello Marc Vince! , Your login URL is: https://your_appname.com/v1/custom/path/user/login
Hello Stephen Huke! , Your login URL is: https://your_appname.com/v1/custom/path/admin/login

You can see that the .env variables have been well displayed.

6. Envalid API

if you look at the env.ts file, you will notice the import of cleanEnv() to load environment variables. cleanEnv() returns a sanitized, immutable environment object, and accepts three positional arguments:

• environment - An object containing your env vars (eg. process.env)
• validators - An object that specifies the format of required vars.
• options - An (optional) object, which supports the following key:
• reporter - Pass in a function to override the default error handling and console output.

By using cleanEnv(), it will log an error message and exit (in Node) or throw (in browser) if any required env vars are missing or invalid. You can override this behavior by writing your own reporter.

7. Validator types

Node's process.env only stores strings, but sometimes you want to retrieve other types (booleans, numbers), or validate that an env var is in a specific format (JSON, URL, email address). To this end, the following validation functions are available:

• str() - Passes string values through, will ensure a value is present unless a default value is given. Note that an empty string is considered a valid value - if this is undesirable you can easily create your own validator (see below)
• bool() - Parses env var strings "1", "0", "true", "false", "t", "f" into booleans
• num() - Parses an env var (eg. "42", "0.23", "1e5") into a Number
• email() - Ensures an env var is an email address
• host() - Ensures an env var is either a domain name or an ip address (v4 or v6)
• port() - Ensures an env var is a TCP port (1-65535)
• url() - Ensures an env var is a URL with a protocol and hostname
• json() - Parses an env var with JSON.parse

Each validation function accepts an (optional) object with the following attributes:

• choices - An Array that lists the admissible parsed values for the env var.
• default - A fallback value, which will be present in the output if the env var wasn't specified. Providing a default effectively makes the env var optional. Note that default values are not passed through validation logic.
• devDefault - A fallback value to use only when NODE_ENV is not 'production'. This is handy for env vars that are required for production environments but optional for development and testing.
• desc - A string that describes the env var.
• example - An example value for the env var.
• docs - A url that leads to more detailed documentation about the env var.

8. Custom validators

You can easily create your own validator functions with envalid.makeValidator(). It takes a function as its only parameter, and should either return a cleaned value or throw if the input is unacceptable:

import { makeValidator, cleanEnv } from 'envalid'
const twochars = makeValidator(x => {
    if (/^[A-Za-z]{2}$/.test(x)) return x.toUpperCase()
    else throw new Error('Expected two letters')
})

const env = cleanEnv(process.env, {
    INITIALS: twochars()
});

9. Error Reporting

By default, if any required environment variables are missing or have invalid values, Envalid will log a message and call process.exit(1). You can override this behavior by passing in your own function as options.reporter. For example:

const env = cleanEnv(process.env, myValidators, {
    reporter: ({ errors, env }) => {
        emailSiteAdmins('Invalid env vars: ' + Object.keys(errors))
    }
})

Additionally, Envalid exposes EnvError and EnvMissingError, which can be checked in case specific error handling is desired:

const env = cleanEnv(process.env, myValidators, {
    reporter: ({ errors, env }) => {
        for (const [envVar, err] of Object.entries(errors)) {
            if (err instanceof envalid.EnvError) {
                ...
            } else if (err instanceof envalid.EnvMissingError) {
                ...
            } else {
                ...
            }
        }
    }
})

Thanks for reading, the source code is available here.

Follow me on social media to stay up to date with the latest posts.  

When you start working as a software developer, there are plenty area you can get into : Frontend, Backend, Full-stack, DevOps, Mobile Apps, Game, Security, Desktop, Embedded, etc). Most of the time, they can be grouped in 4 majors categories. Frontend, Backend, FullStack, DevOps Engineers.

If you make a quick search with any of theses key words, you will have lots of articles describing each one and associated roles. In this article, i'm not going to go deeper into each of them, i will just give you necessary keys to choose the one that suits you best according to your preferences.

First of all, being a software developer is all about building user experiences that suit and convert end users. As a developer, building all of this requires to master (at least a certain level) of  tools and technologies needed to do it. Thus, it sometimes requires within the same team different's profile of developers. Here i will describe and you will have to choose where you could be the most comfortable.

1. Frontend  (Client-Side)

A Front-end developer is the one specialized in building user interfaces (UI). He is responsible to deliver a great visual experience to the end user who access the app trough a browser or any client side device like mobile app, Desktop app, etc.  Since the result of his work is directly presented to the end user, he must have mastered certain key concepts such as animations, man-machine interactions, responsive design, design systems etc.
Most of the time, everything visual is done by Front-end. The skills required to be Front-end basically include :

• For Web development: HTML, CSS (Sass, Less), JavaScript. With the current evolutions of the web and the development of Internet, it will be great to add to the tech stack UI frameworks such as Tailwind CSS, Bootstrap, Bulma, Semantic UI, Foundation, Materialize, Chakra UI etc. (I cannot name them all 😉), javascript frameworks like React, Vue.js, Ember.js, Meteor.js, jQuery, etc.
• For Mobile Apps : Mobile apps can be built using two approach. Native platform specific SDK (Android  sdk for android apps, IOS sdk for ios apps) or cross-platform framework such as React Native, Cordova, Ionic, NativeScript, Appcelerator, Flutter, Xamarin, RubyMotion, etc. Most of theses framework uses javascript
• For Desktop apps : A desktop developer is a programmer who writes code for software applications that (1) run natively on operating systems like macOS, Windows, and Linux. Desktop apps can be built with programming language such as C/C++, JavaFX, Python, C#, Ruby, Swift, Objective-C.

Since we are more productive with the tools we are most comfortable with, if you think you are more proficient and more comfortable producing rich user interfaces through animation and visuals, the front is for you. For more details, take a look here to see an example of  front-end developer  roadmap https://roadmap.sh/frontend.

2.  Backend (Server-Side)

The backend developer specializes in design, implementation, functional logic and performance and scalability of a piece of software or system running on machines that are remote from the end-user. Backend development refers to server-side development that centers on scripting, databases, and web application architecture. In simple terms, the backend developer handles behind-the-scenes activities that take place while performing a function on the website or application. It’s the backend developer’s responsibility to write code that communicates with databases or APIs, creating libraries, working on data architecture and business processes, and so on. Back-end systems can grow to be very complex, but their complexity is often not visible to the users. The whole complexity is absorbed on the back to deliver the best experience to the user on the front. Backend developer should have strong algorithm skills and will deal with programming languages such as Java, C, C++, ruby, Perl, Python, Scala, Go, Javascript, etc. He should be also been able to understand concepts such as microservices, APIs, distributed systems, storage, databases, Continuous delivering, Architectural Patterns, Scalability ( scaling Vertical vs Horizontal) caching, logging, metrics measurement, etc. For more details, take a look here to see an example of  back-end developer  roadmap https://roadmap.sh/backend.

3.  Full-stack

A Full Stack Developer is someone who works with the Back End — or server side — of the application as well as the Front End, or client side. Full Stack Developers have to have some skills in a wide variety of coding niches, from databases to graphic design and UI/UX management in order to do their job well. They are something of a swing, ready to assist wherever needed in the process.

Some of the responsibilities of a Full Stack Developer include:

• Helping with the design and development of software
• Testing and debugging software to keep it optimized
• Writing clean code for the front and back end of the software
• Designing user interactions on the web application itself
• Creating servers and databases for the back end of the software
• Ensuring cross-platform compatibility and optimization
• Testing and maintaining the responsive design of applications
• Working with graphic designers to design new features
• Developing APIs and RESTful services
• Keeping up with technological advances to optimize their software
• Communicating effectiveness of emerging technologies to decision makers
• Considering security, maintenance, scalability, and more when developing

4.  DevOps

A DevOps engineer is an IT generalist who should have a wide-ranging knowledge of both development and operations, including coding, infrastructure management, system administration, and DevOps toolchains. DevOps engineers should also possess interpersonal skills since they work across company silos to create a more collaborative environment. Some core concepts that constitute the DevOps process can be:

• Agile planning
• Continuous development
• Continuous automated testing
• Continuous integration and continuous delivery (CI/CD)
• Continuous deployment
• Continuous monitoring
• Infrastructure as a code
• Containerization
• Microservices
• Cloud infrastructure
• System architecture and provisioning

A DevOps engineer must have programming experience to cover scripting and coding. Scripting skills usually entail the knowledge of Bash or PowerShell scripts, while coding skills may include Java, C#, C++, Python, PHP, Ruby, etc., or at least some of these languages, Knowledge of database systems, strong communication and collaboration skills, experience with automation tools. Take a look here too see more https://roadmap.sh/devops

Thanks for reading.

Follow me on socials media to stay up to date with latest posts.