GraphQL Federation Hexagonal Architecture — คู่มือฉบับสมบูรณ์ 2026 | SiamCafe Blog

บทนำ: เมื่อ GraphQL Federation พบกับ Hexagonal Architecture

ในโลกของการพัฒนาซอฟต์แวร์ยุค 2026 สถาปัตยกรรมแบบโมโนลิธ (Monolithic) เริ่มกลายเป็นอดีตไปแล้ว องค์กรขนาดใหญ่ทั่วโลกต่างหันมาใช้ Microservices เพื่อเพิ่มความยืดหยุ่นในการพัฒนาและปรับขนาดระบบ อย่างไรก็ตาม การจัดการ API สำหรับบริการที่แยกส่วนกันนั้นกลับกลายเป็นความท้าทายครั้งใหญ่ นี่คือจุดที่ GraphQL Federation เข้ามามีบทบาทสำคัญ

GraphQL Federation เป็นสถาปัตยกรรมที่ช่วยให้เราสามารถรวม GraphQL schemas จากหลายๆ microservices เข้าด้วยกันเป็น gateway เดียว ทำให้ client สามารถ query ข้อมูลจากหลายแหล่งได้ในครั้งเดียว แต่การจะนำ Federation มาใช้ให้มีประสิทธิภาพสูงสุดนั้น เราจำเป็นต้องมีโครงสร้างพื้นฐานที่แข็งแกร่ง นั่นคือ Hexagonal Architecture (หรือที่เรียกว่า Ports and Adapters)

บทความนี้จะพาคุณไปรู้จักกับการผสานสองแนวคิดนี้อย่างลึกซึ้ง พร้อมตัวอย่างโค้ดจริง และแนวทางปฏิบัติที่ดีที่สุดสำหรับปี 2026

1. ทำความเข้าใจ GraphQL Federation

1.1 Federation คืออะไร?

GraphQL Federation เป็นแนวคิดที่พัฒนาโดย Apollo GraphQL เพื่อแก้ปัญหาการรวม API ของ microservices หลายตัวเข้าด้วยกัน โดยมีหลักการสำคัญคือ:

• Supergraph: กราฟรวมที่ client เห็นเป็น graph เดียว
• Subgraph: แต่ละ microservice ที่มี GraphQL schema ของตัวเอง
• Gateway/Router: ตัวกลางที่ routing query ไปยัง subgraph ที่ถูกต้อง

1.2 ข้อดีของ Federation เมื่อเทียบกับ Schema Stitching

2. Hexagonal Architecture: หัวใจของระบบที่ยั่งยืน

2.1 หลักการพื้นฐาน

Hexagonal Architecture หรือที่ Alistair Cockburn เสนอไว้ในปี 2005 คือการแยก Business Logic ออกจาก Infrastructure โดยสิ้นเชิง โครงสร้างประกอบด้วย 3 ส่วนหลัก:

1. Core Domain: ตรรกะทางธุรกิจบริสุทธิ์ ไม่มี dependencies ภายนอก
2. Ports: Interfaces ที่กำหนดว่า system ต้องการ input/output อะไร
3. Adapters: Implementation ที่เชื่อมต่อกับโลกภายนอก (DB, API, Message Queue)

2.2 ทำไมต้อง Hexagonal สำหรับ GraphQL Federation?

เมื่อเราพัฒนา subgraph แต่ละตัวด้วย Hexagonal Architecture เราจะได้ประโยชน์ดังนี้:

• Testability: สามารถเทส business logic โดยไม่ต้องพึ่ง external services
• Flexibility: เปลี่ยน database หรือ message broker ได้โดยไม่กระทบ core logic
• Maintainability: แต่ละ subgraph เป็นอิสระต่อกัน ลดความซับซ้อน

3. การออกแบบ Subgraph ด้วย Hexagonal Architecture

3.1 โครงสร้างโฟลเดอร์ที่แนะนำ

สำหรับโปรเจกต์ TypeScript (ซึ่งเป็นภาษายอดนิยมในปี 2026) เราจะใช้โครงสร้างดังนี้:

src/
├── domain/                  # Core Business Logic
│   ├── entities/
│   │   └── User.ts
│   ├── ports/
│   │   ├── IUserRepository.ts
│   │   └── IUserService.ts
│   └── use-cases/
│       └── CreateUserUseCase.ts
├── adapters/                # Implementation
│   ├── graphql/
│   │   ├── schema.graphql
│   │   └── resolvers.ts
│   ├── persistence/
│   │   ├── mongo/
│   │   │   └── UserRepository.ts
│   │   └── postgres/
│   │       └── UserRepository.ts
│   └── messaging/
│       └── KafkaUserPublisher.ts
├── config/
│   └── container.ts         # Dependency Injection
├── gateway/                 # Federation specific
│   └── supergraph-config.yaml
└── main.ts

3.2 ตัวอย่าง Code: Core Domain

เริ่มต้นด้วยการสร้าง Entity และ Port (Interface):

// domain/entities/User.ts
export class User {
  constructor(
    public readonly id: string,
    public readonly email: string,
    public readonly name: string,
    public readonly createdAt: Date
  ) {}

  // Business logic method
  public updateName(newName: string): User {
    if (newName.length < 2) {
      throw new Error('Name must be at least 2 characters');
    }
    return new User(this.id, this.email, newName, this.createdAt);
  }
}

// domain/ports/IUserRepository.ts
export interface IUserRepository {
  findById(id: string): Promise<User | null>;
  findByEmail(email: string): Promise<User | null>;
  save(user: User): Promise<void>;
  delete(id: string): Promise<void>;
}

// domain/use-cases/CreateUserUseCase.ts
export class CreateUserUseCase {
  constructor(private readonly userRepo: IUserRepository) {}

  async execute(email: string, name: string): Promise<User> {
    // Validate business rules
    const existingUser = await this.userRepo.findByEmail(email);
    if (existingUser) {
      throw new Error('Email already exists');
    }
    const user = new User(
      crypto.randomUUID(),
      email,
      name,
      new Date()
    );
    await this.userRepo.save(user);
    return user;
  }
}

3.3 ตัวอย่าง Code: Adapters สำหรับ GraphQL Federation

ตอนนี้เราจะสร้าง GraphQL adapter ที่ทำงานร่วมกับ Federation:

// adapters/graphql/schema.graphql
extend type Query {
  user(id: ID!): User
  users: [User!]!
}

type User @key(fields: "id") {
  id: ID!
  email: String!
  name: String!
  createdAt: String!
}

// adapters/graphql/resolvers.ts
import { GraphQLResolverMap } from '@apollo/subgraph/dist/schema-helper';

export const resolvers: GraphQLResolverMap = {
  User: {
    __resolveReference: async (ref, { dataSources }) => {
      return dataSources.userRepo.findById(ref.id);
    },
  },
  Query: {
    user: async (_, { id }, { dataSources }) => {
      return dataSources.userRepo.findById(id);
    },
    users: async (_, __, { dataSources }) => {
      return dataSources.userRepo.findAll();
    },
  },
  Mutation: {
    createUser: async (_, { email, name }, { dataSources }) => {
      const useCase = new CreateUserUseCase(dataSources.userRepo);
      return useCase.execute(email, name);
    },
  },
};

4. การตั้งค่า Gateway และ Supergraph

4.1 Apollo Router Configuration

ในปี 2026 Apollo Router เป็นตัวเลือกหลักสำหรับ gateway เนื่องจาก performance ที่ดีกว่า Apollo Gateway (Node.js) อย่างมาก ตัวอย่างการตั้งค่า:

# supergraph-config.yaml
federation_version: 2
subgraphs:
  users:
    routing_url: http://user-service:4001/graphql
    schema:
      file: ./schemas/users.graphql
  products:
    routing_url: http://product-service:4002/graphql
    schema:
      file: ./schemas/products.graphql
  orders:
    routing_url: http://order-service:4003/graphql
    schema:
      file: ./schemas/orders.graphql

จากนั้นรันคำสั่งเพื่อสร้าง supergraph schema:

rover supergraph compose --config ./supergraph-config.yaml > supergraph.graphql

4.2 การจัดการ Entity Resolution

เมื่อ subgraph ต่างๆ ต้องแชร์ entity เดียวกัน (เช่น User ถูกใช้ทั้งใน users service และ orders service) เราจะใช้ @key และ @extends:

// ใน orders service
extend type User @key(fields: "id") {
  id: ID! @external
  orders: [Order!]!
}

type Order @key(fields: "id") {
  id: ID!
  userId: String!
  total: Float!
  items: [OrderItem!]!
}

5. การจัดการ Cross-Cutting Concerns

5.1 Authentication และ Authorization

ในสถาปัตยกรรม Hexagonal เราควรจัดการ Auth ที่ระดับ adapter ไม่ใช่ domain:

• Gateway level: ตรวจสอบ JWT token ก่อนส่งต่อไปยัง subgraph
• Subgraph level: ใช้ GraphQL directive @auth หรือ middleware

ตัวอย่างการสร้าง custom directive สำหรับ authorization:

// adapters/graphql/directives/auth.ts
import { mapSchema, getDirectives, MapperKind } from '@graphql-tools/utils';
import { ForbiddenError } from 'apollo-server-errors';

export function authDirectiveTransformer(schema) {
  return mapSchema(schema, {
    [MapperKind.OBJECT_FIELD]: (fieldConfig) => {
      const directives = getDirectives(schema, fieldConfig);
      if (directives.auth) {
        const { resolve } = fieldConfig;
        fieldConfig.resolve = async (source, args, context, info) => {
          if (!context.user) {
            throw new ForbiddenError('Unauthorized');
          }
          if (directives.auth.roles && 
              !directives.auth.roles.includes(context.user.role)) {
            throw new ForbiddenError('Insufficient permissions');
          }
          return resolve(source, args, context, info);
        };
      }
      return fieldConfig;
    },
  });
}

5.2 Error Handling ที่เป็นมาตรฐาน

Hexagonal Architecture ช่วยให้เราจัดการ error ได้อย่างเป็นระบบ โดยแยก error ทางธุรกิจ (Domain Error) ออกจาก error ทางเทคนิค (Infrastructure Error):

6. Best Practices สำหรับ Production (2026)

6.1 การทดสอบ (Testing Strategy)

1. Unit Test: ทดสอบ use cases โดย mock repository (ใช้ Jest หรือ Vitest)
2. Integration Test: ทดสอบ adapter จริงกับ test database
3. Contract Test: ใช้ GraphQL Inspector เพื่อตรวจสอบ schema compatibility
4. E2E Test: ทดสอบผ่าน gateway จำลอง user scenario จริง

6.2 การ Deploy และ Monitoring

• Blue-Green Deployment: สำหรับ gateway เพื่อลด downtime
• Apollo Studio: ใช้สำหรับ monitoring performance และ schema checks
• Distributed Tracing: ใช้ OpenTelemetry เพื่อติดตาม request ข้าม subgraph

6.3 การจัดการ Schema Evolution

เมื่อทีมพัฒนาหลายทีมทำงานบน subgraph ต่างกัน การเปลี่ยนแปลง schema ต้องระมัดระวัง:

• ใช้ Schema Registry (Apollo Studio) เพื่อตรวจสอบ breaking changes
• ใช้ @deprecated directive ก่อนลบ field จริง
• ทำ Versioning ที่ระดับ subgraph (ไม่ใช่ gateway)

7. Real-World Use Cases

7.1 กรณีศึกษา: E-Commerce Platform

บริษัทอีคอมเมิร์ซแห่งหนึ่งใช้สถาปัตยกรรมนี้กับทีม 5 ทีม:

• ทีม User: จัดการ authentication, profile, address
• ทีม Product: จัดการ catalog, inventory, pricing
• ทีม Order: จัดการ cart, checkout, payment
• ทีม Recommendation: จัดการ personalized suggestions
• ทีม Search: จัดการ Elasticsearch integration

ผลลัพธ์: ลดเวลาในการพัฒนา feature ใหม่ลง 40% และเพิ่มความเร็วในการตอบสนองของ API 30%

7.2 กรณีศึกษา: Financial Services

ธนาคารแห่งหนึ่งใช้ Hexagonal + Federation เพื่อรวม legacy systems:

• แต่ละ subgraph มี adapter ที่เชื่อมต่อกับ mainframe, core banking, CRM
• Hexagonal ช่วยให้เปลี่ยนจาก SOAP เป็น REST/GraphQL โดยไม่กระทบ business logic
• Federation ทำให้ mobile app สามารถ query ข้อมูลจากหลายระบบในครั้งเดียว

8. ข้อควรระวังและข้อจำกัด

8.1 ความซับซ้อนที่เพิ่มขึ้น

แม้สถาปัตยกรรมนี้จะให้ประโยชน์มากมาย แต่ก็มาพร้อมกับความซับซ้อนที่ต้องจัดการ:

• Learning Curve: ทีมต้องเข้าใจทั้ง Federation และ Hexagonal
• Operational Overhead: ต้องจัดการหลาย services, databases, deployments
• Debugging ยากขึ้น: เมื่อ error เกิดขึ้น ต้อง追踪ข้ามหลาย services

8.2 เมื่อไหร่ที่ไม่ควรใช้

• ทีมขนาดเล็ก (< 5 คน) หรือโปรเจกต์ขนาดเล็ก
• ระบบที่ latency-sensitive มาก (ทุก millisecond มีค่า)
• องค์กรที่ยังไม่มี DevOps culture ที่แข็งแกร่ง

9. เครื่องมือและเทรนด์ปี 2026

9.1 เครื่องมือแนะนำ

• Apollo Router: ตัวเลือกอันดับ 1 สำหรับ gateway (Rust-based)
• WunderGraph: ทางเลือกที่ lightweight สำหรับ startups
• Hive (โดย The Guild): Schema registry ฟรีสำหรับ open source
• GraphQL Yoga: Server ที่รองรับ Federation 2 อย่างดี

9.2 เทรนด์ที่น่าจับตา

• Federation 3: คาดว่าจะมีความสามารถในการจัดการ real-time data และ event-driven federation
• AI-powered Schema Design: เครื่องมือที่ใช้ AI แนะนำ schema evolution
• Edge Federation: การ deploy subgraph ไปยัง edge nodes เพื่อ latency ที่ต่ำลง

10. การเริ่มต้นใช้งานจริง (Step-by-Step)

10.1 ขั้นตอนที่ 1: เริ่มจากเล็กๆ

1. เลือก 1 microservice ที่เป็นอิสระ (เช่น user service) เพื่อเริ่มต้น
2. ออกแบบ Hexagonal Architecture ให้สมบูรณ์
3. เพิ่ม Federation schema และ @key directive
4. ตั้งค่า Apollo Router กับ service เดียวนี้ก่อน

10.2 ขั้นตอนที่ 2: ขยายทีละน้อย

1. เพิ่ม service ที่ 2 (product service) ที่ต้องแชร์ entity กับ service แรก
2. ใช้ @extends เพื่อขยาย type User ใน product service
3. ทดสอบการ query ที่เรียกข้อมูลจากทั้ง 2 services

10.3 ขั้นตอนที่ 3: ทำ Automation

1. CI/CD pipeline ที่ตรวจสอบ schema compatibility ทุก commit
2. Automated contract tests ระหว่าง subgraph
3. Monitoring dashboard สำหรับ federation performance

สรุป

การผสาน GraphQL Federation เข้ากับ Hexagonal Architecture เป็นแนวทางที่ทรงพลังสำหรับการสร้างระบบ microservices ในยุค 2026 โดย Federation ช่วยให้เราสามารถรวม API จากหลายบริการเข้าด้วยกันอย่างมีประสิทธิภาพ ในขณะที่ Hexagonal Architecture ทำให้แต่ละ subgraph มีความยืดหยุ่น ทดสอบง่าย และบำรุงรักษาได้ดี

อย่างไรก็ตาม การนำสถาปัตยกรรมนี้ไปใช้ต้องอาศัยความเข้าใจทั้งสองแนวคิดอย่างลึกซึ้ง รวมถึงการมีวินัยในการออกแบบและพัฒนา เริ่มต้นจากโปรเจกต์เล็กๆ สร้าง foundation ที่แข็งแกร่ง แล้วค่อยๆ ขยายเมื่อทีมและองค์กรพร้อม

ในปี 2026 นี้ หากคุณกำลังวางแผนสร้างหรือปรับปรุงระบบ API สำหรับองค์กร การลงทุนเรียนรู้และ implement GraphQL Federation + Hexagonal Architecture จะเป็นการตัดสินใจที่คุ้มค่าในระยะยาว อย่าลืมติดตามข่าวสารและเครื่องมือใหม่ๆ จาก SiamCafe Blog เพื่ออัปเดตเทรนด์เทคโนโลยีล่าสุดอยู่เสมอ