GraphQL아주 조금만 살펴보기 - Node.js

오늘은 갑자기 컨디션도 좀 안좋아서 평소에 제대로 좀 보고 싶었던 GraphQL관련 세미나를 들었다. Gatsby같은 경우에는 내부에서 데이터 끌어오는게 다 GraphQL이고, AWS에서 AppSync를 써도 GraphQL엔드포인트를 제공해주는거라 경험은 계속했는데 제대로 스키마가 무었인지 resolve는 어떻게하는지 서버에서 뭘처리해주길래 나는 그냥 프론트에서 db쿼리 날리듯 날리면 되는건지 보기로 했다. 

 

 

공부 자료

https://frontendmasters.com/courses/server-graphql-nodejs/

📡 Learn to create GraphQL APIs on the server in Node.js with Apollo Server with Scott Moss.

여기서 세미나를 봤다. 

 

 

알게 된 내용 간략하게 정리

- GraphQL은 GraphQL schema language라고 데이터를 정의하는 언어를 제공한다. 뭔가 계속 데이터베이스랑 연관지어서 생각하면 편할 것 같다. API를 위한 데이터베이스 스키마 같은 느낌? 데이터베이스도 스키마가 있고, 이것에 따라서 데이터를 업데이트하고 삭제를 하고 읽는다. GraphQL도 내부적으로 데이터를 처리하기 위해서 자기들도 펼쳐놓고 보는 지도같은게 있는것 같다. 

 

- 이 스키마 내에는 아래같은 내용들이 들어간다. 

const { gql } = require("apollo-server");

/**
 * Type Definitions for our Schema using the SDL.
 */
const typeDefs = gql`
  type User {
    id: ID
    username: String
  }

  type Pet {
    id: ID
    createdAt: String
    name: String
    type: String
    img: String
  }

  input PetInput {
    id: String
    name: String
    type: String
  }

  input newPetInput {
    name: String!
    type: String!
  }

  type Query {
    user: [User]!
    pets(input: PetInput): [Pet]!
    pet(input: PetInput): Pet
  }

  type Mutation {
    newPet(input: newPetInput!): Pet!
  }
`;

module.exports = typeDefs;

• Type: TypeScript처럼 데이터의 형태를 정의할때는 Type을 쓴다. enum, interface, unions같은 것들도 Type정의와 관련되서 기능이 제공되고 있다. 
•  Query: 서버에서 DB에 쿼리를 날리듯이, 클라이언트에서 서버로 GraphQL 쿼리를 날리는데, 이때 어떤 데이터가 어떤 input을 가지고(반드시 있어야하는 것은아님) 쿼리를 할 수 있는지를 정의한다. 
• Mutation: 서버에서 DB에 데이터 넣고 지우고 업데이트 하는것처럼 클라이언트에서도 서버에다가 뭘좀 바꿔달라고 요청할떄 Mutation으로 형태를 정의하는데, 이 안에는 어떤 데이터가 처리 될 수 있는지를 정의한다. 

 

 

- resolver란

이렇게 스키마만 띡 만들어놓는다고 뭐가 되는건 아니고, 이렇게 데이터가 오고갈텐데, 실제로 뭘어쩔건지는 resolve를 해주어야한다. "settle or find a solution to (a problem, dispute, or contentious matter)." Resolve뜻처럼 우리가 어떤 데이터에 대해서 솔루션을 직접 정의해줘야한다. 

/**
 * Here are your Resolvers for your Schema. They must match
 * the type definitions in your scheama
 */

module.exports = {
  Query: {
    pets(_, { input }, { models }) {
      return models.Pet.findMany(input);
    },
    pet(_, { input }, { models }) {
      return models.Pet.findOne(input);
    },
  },
  Mutation: {
    newPet(_, { input }, { models }) {
      return models.Pet.create(input);
    },
  },
  Pet: {
    img(pet) {
      console.log(pet);
      return pet.type === "DOG"
        ? "https://placedog.net/300/300"
        : "http://placekitten.com/300/300";
    },
  },
  // User: {},
};

• Query: Schema에서는 Query가 어떤 데이터를 처리하는지만 정의하고, 실제로 Pets나 Pet에 대한 요청이 오면 뭘 반환하는지를 정의하진 않았다. 여기서 Query를 날릴때 Pets를 요청하면 어떤 데이터를 어떻게 반환할지는 전적으로 우리의 몫이 된다. 
• Mutation: Field도 똑같다. Mutation이 날아오면 위의 예시의 경우 newPet으로 요청이 오면 어떻게 데이터를 처리해서 mutate를 할지를 정의하는 것이다. 
• Type에 대해서: 내가 정의한 스키마의 Pet을 보면 img는 있는데, 이에 대해서 뭔가 결과를 돌려줘야할때, 데이터에 따라서 다르게 보여야할때도 있다. 여기서는 pet의 Type에 따라서 어떤 Img를 보여줄지 정해지는데, 여기서 데이터의 형태같은 것을 원하는대로 바꾸어서 반환가능하다. Query나 Mutation을 하고나서 결과가 반환될때 여길 거쳐서 나간다(있으면!)

 

 

- playground 적응하기

Playground만 잘봐도 docs가 정말 잘 제공되기때문에 어떤 데이터를 만질때 어떤 인자를 넘겨줘야하는지를 파악하기 쉽도록 되어있다. 

 

- GraphQL은 어떻게 쓰이게 될까?

 이 세미나를 진행하신 Scott Moss님께서는 GraphQL을 회사의 서비스들 제일 앞에 두고, 서버 내부에서는 user정보는 Strapi, 어떤건 그냥 Rest API로 처리하는 등 중간에 낄수있다는 얘기도 해주셨다. 앞으로 이 기술이 얼마나 더 많이 도입이 될지는 잘 모르겠지만, 확실히 Django Restframework같은 것을 썼을때 내도록 API 엔드포인트 만들어가면서 프론트 만들때 개인적으로 너무 정신 없었는데, 이렇게 뭐 할때마다 엔드포인트 안추가해도 되고, 타입도 딱 정해져있으니 잘만 사용하면 적은수의 사람으로 덜힘들게 개발할 수 있지 않을까 싶기도하다. 하지만 그만큼 공부하고 해야해서 어려울수도있지만! 그래도 앞으로 개인적인 프로젝트를 할때 Rest 서버를 직접 구성하는것보다는 GraphQL서버를 이용하게 될것 같다.