GraphQL API 왜 쓰는지 알아보기

GraphQL API란 무엇일까?

흔히 프런트는 화면에 뿌려줄 데이터를 서버로부터 받게 됩니다. 이때 RESTful API를 통해 데이터를 받게 됩니다. RESTful 함이란 uri에 동작이 명시되어 API를 요청할 때 결과를 예측가능하게 하여 원활한 협업을 위한 하나의 규칙입니다. REST API는 요청 당 하나의 스키마로부터 데이터를 응답받게 됩니다. 

최근 앱은 하나의 화면이 여러 스키마들의 데이터로 구성되어 있기 때문에 비즈니스 로직에서 여러 스키마에게 REST API를 요청해야 합니다. 하지만 스키마의 모든 데이터가 화면을 구성하는 것이 아니기 때문에 화면에 구성될 데이터만 응답해줘야 했습니다.

이러한 배경에서 한번의 요청에서 필요한 데이터만 전달해 주는 GraphQL이 나오게 되었습니다. (GraphQL 찍먹 하기)

GraphQL | A query language for your API

REST API v GraphQL

REST API는 명시된 uri에 따라 비즈니스 로직을 동작시킨다면 GraphQL은 도메인주소/graphql 주소로 POST 방식으로 원하는 함수를 실행시킵니다. 그렇기 때문에 우리는 스키마 데이터 형태를 만들어야 하고 어떠한 동작을 할지 정의해 주는 작업이 필요합니다.

 

GraphQL 사용해 보기

우선 resources/graphql에서 스키마.graphqls 폴더를 만듭니다.

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

type Query{
    getMember(id : ID!) : Member
    getMembers: [Member]
}

type Mutation{
    alter(id:ID!, name : String!) : Member
    save(name : String!):Member
}

위와 같이 type Member에서는 스키마 형태를 만들 것이고 Query, Mutation에서 동작 이름과 어떤 데이터를 받을 것인지 정합니다.

Query는 흔히 데이터 응답 메서드이고 Mutation은 추가와 수정과 같은 동작을 합니다.

 

Member 엔티티 참고.

@Entity
@AllArgsConstructor
@NoArgsConstructor

@Builder
public class Member {
    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String name;

}

 

 

 

비즈니스 로직이 없어서 Controller 단에서 처리했습니다.

@Controller
@RequiredArgsConstructor
public class MemberController {
    private final MemberRepository memberRepository;

    @QueryMapping
    public Member getMember(@Argument Long id) {
        return memberRepository.findById(id).get();
    }

    @QueryMapping
    public List<Member> getMembers() {
        return memberRepository.findAll();
    }

    @MutationMapping
    public Member alter(@Argument Long id, @Argument String name) {
        return memberRepository.save(
                Member.builder()
                        .id(id)
                        .name(name)
                        .build()
        );
    }

    @MutationMapping
    public Member save(@Argument String name){
        return memberRepository.save(
                Member.builder()
                        .name(name)
                        .build()
        );
    }
}

 

위 코드의 4가지 함수가 어떤 동작을 하는지 예상 가능해야 합니다.

• getMember : id를 입력받아 member 하나를 리턴
• getMembers : 입력 없이 모든 member 리턴
• alter : id를 입력받아 해당 member name 수정
• save : member 추가

로컬환경에서 테스트할 시 

http://localhost:8080/graphiql

 접속하면 GraphQL을 테스트해볼 수 있습니다.

getMember 요청 방법 및 결과

 

 

getMembers 요청 방법 및 결과

 

 

alter 요청 방법 및 결과

 

 

save 요청 방법 및 결과

 

GraphQL의 장점

REST API에서는 여러 개의 uri를 로딩하는 반면 GraphQL은 하나의 요청에 가능하게 합니다. 앱 환경에서 빠르게 동작할 것이고 느린 모바일 네트워크 환경에서도 빠르게 작동할 것입니다.

 

마지막으로

REST와 GraphQL의 장점은 분명하다고 느꼈습니다. 정해져 있는 응답만 보내도 되는 환경에서는 REST 방식이 어울릴 것이고 여러 스키마의 데이터가 하나의 화면에 담기거나 화면 구성이 자주 수정되거나 빠르게 변화하는 환경에서는 GraphQL 방식도 괜찮은 것 같습니다. 여기서 마무리하고 관련 주변 지식을 천천히 쌓아가며 나중에 다시 돌아보려 합니다.