nestjs with graphql - ch2 (Federation)

🔥 MSA 구조를 graphql 로 만들어보자 🔥

그전에 생각해보자...
grapqhl 은 엔드포인트가 하나인데, MSA 를 어떻게 구현해야 하지...? 뭔가 msa 로 할 수 있을 것 같으면서도... 이게 restapi 처럼 msa 를 구성 가능할까...? 여러가지 생각이 든다. 음...각 app 별로 tcp 서버를 열어야 하나? tcp 통신이 필요한가? 어차피 엔드포인트 하나인데..?
한번 해보자.

1. 각 도메인에 따른 app 을 만든다
   nest g app gateway, nest g app account, nest g app chat

2. 생성한 앱은 rest 기반으로 만들기 때문에 graphql 을 위한 resolver 생성이 필요하다.
   nest g resource
   

   gateway 를 제외한 다른 app 들을 각자 선택해서 resolver 를 생성하면 기본 구조(resolver, service, dto, entity...) 및 로직(CRUD)을 만들어준다.
   

3. 이제 gateway 에서 각 앱들을 하나로 연결을 시켜줘야 한다.

   여기서 중요한 개념이 있다.

Federation

Federation(직역하면 연방)의 의미는 graphql 서버를 각 microservice 로 주입을 해준다라는 의미이다.

요청한 쿼리를 하나의 리졸버에서 모두 해결하는 것이 아닌, 각 subgraph 에서 스키마를 처리해서 처리된 schema 를 superGraph 에서 취합해서 프론트로 던져준다.

Federation 을 구현하기 위해서는 하나의 gateway 와 한개 이상의 microservice(federated microservice) 가 필요하다.
이때 gateway 를 supergraph 라고 하고, 각각의 service 들을 subgraph 라고 이해하면 편하다.

federated microservice(subgraph) 는 각각의 schema 를 가지고 있고, gateway(supergraph) 는 그 schema 들을 한 곳으로 모을 수 있다.

🔥 물론 하나의 resolver 에서 모든 로직을 처리할 수는 있지만, 그렇게 하면 여러 테이블에 join 을 걸어야 하고 그렇게 되면 graphql 을 사용하고도 overFetching 을 할 수 밖에 없다.
그렇기 때문에 원하는 값만 조회하기 위해 각 entity를 담당하는 resolver 에서 각각 처리하고 superGraph 에서 해당 entity 들을 모아서 반환하는 것이다.

그러면 각각의 subgraph 를 어떻게 한번에 모으는지 아래 코드를 통해 확인해보자.

// gateway.module.ts
import { Module } from '@nestjs/common';
import { GatewayService } from './gateway.service';
import { GraphQLModule } from '@nestjs/graphql';
import { ApolloGatewayDriver, ApolloGatewayDriverConfig } from '@nestjs/apollo';
import { IntrospectAndCompose } from '@apollo/gateway';
@Module({
  imports: [
    GraphQLModule.forRoot<ApolloGatewayDriverConfig>({
      driver: ApolloGatewayDriver,
      gateway: {
        supergraphSdl: new IntrospectAndCompose({
          // 각각의 subGraph 를 하나로 연결 시켜준다.
          subgraphs: [
            {
              name: 'account',
              url: 'http://localhost:3001/graphql',
            },
            {
              name: 'talk',
              url: 'http://localhost:3002/graphql',
            },
          ],
        }),
      },
    }),
  ],
  providers: [GatewayService],
})
export class GatewayModule {}

코드는 간단하다. ApolloGatewayDriver, IntrospectAndCompose class 를 이용해서 각각의 subgrapqh 를 통합해줄 수 있다.

각각의 federated microservice 의 schema 중 @ObjectType 간의 relation 을 활용하면 하나의 query 에서 데이터를 가져오는 것이 가능하다. 그러기 위해서는 directive 지시어 가 필요하다.

Directive

graphql 에서는 동일한 이름의 @ObjectType 이 존재 하면 안된다

하지만 여러 앱에서 동일한 모델을 쓰고 싶을 수 있다. 예를 들어, 계정 페이지에서 고객의 정보를 보여줄 수도 있고, 채팅방에서 고객 정보를 보여줄 수도 있다. 채팅방에서는 채팅 정보와 고객의 정보를 같이 보여줘야 하는 경우가 생긴다.
MSA 구조에 따라서 각 앱에서 각 모델을 교차해서 종속시키는건 옳지 않은 방법이기 때문에, 각 앱에서 각 모델을 둘다 선언을 해준다.

// chat > chat.model.ts
import { Directive, Field, ID, ObjectType } from '@nestjs/graphql';
@ObjectType()
@Directive('@key(fields: "id")')
export class AccountModel {
  @Field(() => ID)
  id: string;
}



// account > account.model.ts
import { Directive, Field, ID, ObjectType } from '@nestjs/graphql';
@ObjectType()
@Directive('@key(fields: "id")')
// 동일 이름의 objectType 이 있으면 안된다
// -> 동일한 objectType 이 있다면 반드시 @Directive('@key(fields: "id")') 로 obejct 의 pk 를 설정해줘야 함
export class AccountModel {
  @Field(() => ID)
  id: string;

  @Field(() => String)
  name: string;
}

이렇게 될 경우 schema 에 같은 이름의 모델이 생겨버리기 떄문에 graphql 철학에 위배된다. 이때, @Directive('@key(fields: "id")') 로 문제를 풀어준다.
저 데코레이터는 중복을 허용해준다는 의미를 포함하고 있다. 또한, 안에 있는 @Key 는 모델에도 테이블처럼 PK 를 지정해주는 것이다.
저 PK로 정한 id 가 같은 모델이 있으면 두개는 같은것으로 판단해서 하나로 묶어준다.
결국

@ObjectType()
export class AccountModel {
  @Field(() => ID)
  id: string;

  @Field(() => String)
  name: string;
}

// schema.gql
type AccountModel {
  id: ID!
  name: String!
}

다음과 같은 하나의 모델이 되는 것이다.

ResolveField

처음에 이거 떄문에 애를 썩었다.
아무리 구글링해서 나오는 설명을 봐도 이해가 안되고, 대신에 이거를 쓰면 dataLoader 뭐시기 뭐시기... 그래서 유튜브 영상 및 지인들을 통해서 알아냈다.

ResolveField... 일단 Field 다. resolve... 해결하다?

의역하면 필드를 하나 열어주는 것이다.
즉 ResolveField 가 속해있는 리졸버에서 반환하는 모델에 필드를 하나 더 추가하는 행위다.

// chat.resolver.ts
import {
  Resolver,
  Query,
  Args,
  Int,
  ResolveField,
  Parent,
} from '@nestjs/graphql';
import { ChatService } from './chat.service';
import { AccountModel, ChatModel } from './entities';

@Resolver(() => ChatModel)
// 이 resolver 는 chatModel 을 뽑아내기 위한 리졸버이다
export class ChatResolver {
  constructor(private readonly chatService: ChatService) {}

  @Query(() => ChatModel)
  async getChatInfo(
    @Args('roomId', { type: () => Int }) roomId: number,
  ): Promise<ChatModel> {
    return {
      chatId: roomId,
    };
  }

  @ResolveField(() => AccountModel)
  user(@Parent() chat: ChatModel) {
    return { __typename: 'UserEntity', id: chat.chatId };
  }
}



// chat.model.ts
@ObjectType()
export class ChatModel {
  @Field(() => Number)
  chatId: number;
}

위 리졸버는 ChatModel을 반환하는 리졸버이다. @ResolveField 를 통해서 ChatModel 에 user 라는 필드를 추가적으로 반환하겠다라는 뜻이다.

근데 User 는 AccountModel 이다. AccountModel 은 Chat 앱이 아니라, Account 앱에 종속되어있다. 어떻게 가져오지?
이때 @Directive 가 쓰인다!!!

@Query() getChatInfo 쿼리는 ChatModel 을 반환한다.
그러면 @Parent() 가 ChatModel 인 user @ResolveField() 가 이를 캐치한다. user @ResolveField() 가 { __typename: 'UserEntity', id: chat.chatId } 를 반환하는데, 이를 누구한테 반환하는가..?

✅ 앞서 말했듯이 graphql 에서는 동일한 ObjectType이 있을 수 없다.
chat app 에 종속되어 있는 Account Model 와
Account app 에 종속되어 있는 Account Model 이
@Directive key 로 연결되어 있기 때문에,
AccountModel 을 종속하고 있는 Account app 에서 이를 수신한다.

만약에 또다른 app 에서도 Account Model 을 사용하고 있다면? 어느쪽에서 수신할까?
이런 고민은 잘못됐다.
애초에 Account Model 은 Account app 에서 다루는것이 옳은 방법이다. (관심사의 분리가 적용된다)
그렇기 때문에 애초에 또 다른 app 에서는 @ResolveReference() 이 아니라, @ResolveField() user 를 사용하는 것이 맞다.
즉, Account Model 은 Account app 에서만 로직을 풀어가자!

// account.resolver.ts
/**
   *
   * @description chat resolver 에서 처리하지 못하는 쿼리를 여기서 처리함 (find account)
   * resolverField 를 여기서 수신해서 처리한다.
   */
  @ResolveReference()
  resolveReference(reference: {
    __typename: string;
    id: string;
  }): AccountModel {
    return {
      id: reference.id,
      name: `${reference.id} + name`,
    };
  }

---

이렇게 ResolveField -> ResolveReference -> ResolveField -> ResolveReference -> ... 계속 하면 가장 마지막에 수신하는 리졸버를 수만가지 요청을 처리해야 하는 경우가 생긴다.
이를 N+1 문제 라고 하는데, 다음에 다뤄보자.

---

Ref

https://blog.doctor-cha.com/integrating-graphql-services-with-graphql-federation
https://www.apollographql.com/docs/federation/

https://unsplash.com/ko/%EC%82%AC%EC%A7%84/%ED%8C%8C%EB%9E%80%EC%83%89-%ED%8E%98%EC%9D%B8%ED%8A%B8%EA%B0%80-%EC%B9%A0%ED%95%B4%EC%A7%84-%EC%82%AC%EB%9E%8C-%EB%B0%9C-EIyAz8blaAk