• Tistory : GraphQL + SpringBoot

GraphQL?

• GraphQL은 페이스북에서 만든 쿼리 언어입니다.
• GrahpQl은 웹 클라이언트가 데이터를 서버로부터 효율적으로 가져올 수 있도록 되어있습니다.
• REST API의 경우는 다양한 EndPoint가 존재한다면 GraphQL은 하나의 EndPoint를 가집니다.

GraphQL은 기존에 Url을 보면 이해하기 쉽다.

• Rest Api의 경우는 /newPost, /comments, /user 등 다양한 endPoint를 가지지만
• gql(GraphQL)은 /graphql 하나의 endpoint 만으로도 사용이 가능하다는 점이다.

Spring Boot + GraphQL

1) Create Project

• dependencies 추후 추가해도 무관함으로 jpa, web만 추가하면 됨

1.1) build gradle

implementation 'com.graphql-java-kickstart:graphql-spring-boot-starter:11.0.0'
testImplementation 'com.graphql-java-kickstart:graphql-spring-boot-starter-test:11.0.0'

1.2) application.properties(yml)

graphql.servlet.mapping=/graphql
graphql.tools.schema-location-pattern=**/*.graphqls
graphql.servlet.cors-enabled=true
graphql.servlet.max-query-depth=100
graphql.servlet.exception-handlers-enabled=true

2) directory 구조

3) Create Graphqls File

schema {
    query: Query,
    mutation: Mutation,
}

type Mutation {
    registerMember(membersn: Int!, memberid: String!, memberemail: String!, membernumber: String!): Member
    deleteMember(memberid: String!): Boolean
}

type Query{
    findMembers(memberid: String!): Member!
    allFindMembers: [Member]
}

type Member{
    membersn: Int
    memberid: String
    memberemail : String
    membernumber : String
}

• Query : 서버에게 데이터를 요청하여 호출
• Mutation : 서버에게 데이터 수정을 위해 호출
• Query 유형에서 조회, Mutation 유형에서는 생성 및 삭제, 수정 연산에서 사용된다고 보면된다

4) Create Domain/Query/Mutation Class

4.1) domain

@Setter
@Getter
@AllArgsConstructor
@NoArgsConstructor
@Entity(name="member")
public class Member{

    @Id
    @Column(nullable = false)
    private int membersn;

    @Column(nullable = false)    
    private String memberid;

    @Column(nullable = false)
    private String memberemail;

    @Column(nullable = false)
    private String membernumber;
}

4.2) Query

@Service
@RequiredArgsConstructor
public class MemberQuery implements GraphQLQueryResolver{

    private final MemberRepository memberRepository;

    public Member findMembers(String memberId) {

        List<Member> members = memberRepository.findAll();
        Member member = new Member();
        for(Member newMember : members) {
            if(newMember.getMemberid().equals(memberId)) {
                member = memberRepository.findById(newMember.getMembersn())
                        .orElse(null);
            }
        }
        return member;
    }

    public List<Member> allFindMembers(){

        List<Member> member = memberRepository.findAll();

        return member;
    }
}

• graphql의 호출 과정은 graphqls schema file -> resolver -> repository 구조로 볼 수 있다.
• kickstart의 경우 별도의 resolver 구현이 필요 없으나 추후 커스텀을 해야 할 경우 kickstart를 사용이 어렵다.

4.3) Mutation

@Service
@RequiredArgsConstructor
public class MemberMutation implements GraphQLMutationResolver {

    private final MemberRepository memberRepository;

    public Member registerMember(int memberSn, String memberId, String memberEmail, String memberNumber) {

        Member newMember = Member.builder()
                .membersn(memberSn)
                .memberid(memberId)
                .memberemail(memberEmail)
                .membernumber(memberNumber).build();

        return memberRepository.save(newMember);
    }


    public Boolean deleteMember(String memberId) {
        List<Member> memberList = memberRepository.findAll();
        int deleteChk = 0;

        for(Member member : memberList) {
            if(member.getMemberid().equals(memberId)) {
                memberRepository.delete(member);
                deleteChk += 1;
            }
        }

        if(deleteChk > 0) {
            return true;
        } else {
            return false;            
        }
    }

}

5. Result

• 전체 맴버 조회 가능

• 특정 맴버를 조회하는것도 가능

• 맴버 생성 가능

• 맴버 삭제 가능

마무리

• 현재 포스팅의 경우 Graphqls 파일을 단일로 사용하였으나 추후 N개를 사용하기 위해서는 dataFatcher를 직접 구현해줘야 한다.

GitHub Link

• GraphQL

결론을 먼저 말하자면 내가 왜 Tistory에서 Velog로 넘어가려고 하는지를 적어보려고 한다.

담백한 디자인

• 개발자들에게는 마크다운 형식이 익숙하기 때문에 티스토리보다 기록용으로 적합하다고 판단
• 또한 마크다운 형식으로 굳이 디자인에 신경을 쓰지 않아도 된다는 장점이 매력적인 포인트

개발자들의 reference

• 실제 개발을 하면서 나온 정보들을 볼 수 있다
• 티스토리에 비해 개발자들에게 적합한 블로그

티스토리에 비해 벨로그가 적합하다고 판단은 들지만 블로그 작업 시간적인 여유가 생긴다면 github.io로 넘어가려고 한다.

우선 포스팅을 하러 가야겠다..

1. 문제 설명 

2. 문제 예시 

3. 문제 풀이 

내용을 잘 읽어보면 문제를 쉽게 풀 수 있습니다.

먼저 S, D, T는 제곱근을 이용해서 구해주면 됩니다.

스타상(*)과 아차상(#)은 중복이 될 수 있고 효과 중첩이 될 수 있다는 부분만 주의해주면 된다.

*그리고 마지막으로 확인하면 되는 부분은 아차상(#)과 스타상()은 DartResult 맨 뒤에 나올 수 있다는 점 ** 

마지막에 나올 수 있기 때문에 마지막에 종료 표시를 위한 값("K")을 넣어주면 조금 더 쉽게 풀 수 있습니다.

코드는 아래와 같습니다.

import math

def solution(dartResult):
    darts = []
    starsNum = []
    result = [0] * 3
    dartStr = ""
    chks = ""
    rDartResult = ""

    rDartResult = dartResult + "K"

    for i in range(len(rDartResult)):
        if rDartResult[i] == "S" or rDartResult[i] == "D" or rDartResult[i] == "T" or rDartResult[i] == "K":
            darts.append(dartStr + rDartResult[i])
            dartStr = ""
        else:
            dartStr += rDartResult[i]

    for i in range(len(darts)):
        chks = ""
        for j in darts[i]:
            if j == "S":
                result[i] = int(chks)
                result[i] = int(math.pow(result[i], 1))
            elif j == "D":
                result[i] = int(chks)
                result[i] = int(math.pow(result[i], 2))
            elif j == "T":
                result[i] = int(chks)
                result[i] = int(math.pow(result[i], 3))
            elif j == "#" or j == "*":
                if j == "#":
                    result[i-1] *= (-1)
                else:
                    result[i-1] *= 2
                    result[i-2] *= 2
            else:
                chks += j

    return sum(result)

우선 S, D, T, K로 구분을 해준다.

ex) 1S2D*3T -> 1S, 2D, *3T

구분해준 뒤 S, D, T, #, *에 대한 조건들을 부여해주면 됩니다.

4. GitHub Code

Sg-moomin GitHub 다트 게임 코드!

위의 이미지 링크를 클릭하면 코드 확인이 가능합니다.

GitHub에도 동일하게 코드를 올려놨습니다. 

1. 절차지향과 객체지향

1. 절차지향(순차적인 처리)
   • 프로시저 호출의 개념을 바탕으로 하고 있는 프로그래밍이라고 보면 된다.
   • 즉 함수들의 집합으로 구성되어 연속적으로 처리하는 방법을 말한다.
   • 이 방법은 실행속도가 빠르다는 장점이 존재했으나 현재는 객체지향을 주로 사용한다.
   • 그 이유는 유지보수가 어렵다는 단점이 존재하기 때문이다.
     
   2. 객체지향
   • 절차와 달리 객체들의 집합으로 구성되다.
   • 객체들의 집합으로 프로그램이 유연하며 변경이 쉽게 가능하여 최근에도 많이 사용된다.

2. 객체지향 특징

1. 상속

   • 클래스들 사이에서 관계를 가진다고 볼 수 있다.
   • 즉 새로 만든 클래스가 기존의 클래스의 자료와 연산을 이용할 수 있다는 것이다.
   • 새로운 클래스는 자식(서브)클래스, 기존 클래스는 부모(수퍼)클래스라고 부르며 상속을 통해 기존의 클래스를 상속받아 객체를 조직화 가능하다.

2. 다형성

   • 객체의 유형에 따라서 동일한 명칭의 메소드를 다른 역할로 사용 가능하다는 의미이다.
   • 이는 오버라이딩, 오버로딩을 말한다.
   • 다형성을 통해 객체의 관계를 조직화 가능하다.

3. 캡슐화

   • 외부에서 객체 내부의 자료와 메소드에 대한 접근을 하지 못하도록 통제하는 것을 말한다.
   • 이는 객체의 접근은 오직 공개된 자료와 공개된 메소드만 가능하다는 것을 말한다.
   • 이에 따라 private, public으로 나눠 공개여부를 구분 가능하다.

3. 객체지향 장단점

• 장점

  • 재사용성
    • 상속을 통해 기존의 코드 사용하여 표현 가능하며 이는 새로운 프로그램 개발시에 재사용성을 높일 수 있다.
  • 유지보수가 간편
    • 수정 및 기능 추가 시 캡슐화 되어 있어서 주변에 미치는 영향은 적지만 상속을 통해서 기존 코드를 사용가능하기 때문에 유지보수적인 측면에서 효율적이다.
  • 직관적인 코드 분석
    • 객체로 구분되어 직관적으로 객체,매소드별 코드 분석이 쉬움
  • 모델링이 좋음
    • 생각하는 방식대로 개발 가능하기 때문

• 단점

  • 절차지향에 비해 실행속도가 느림

위의 이미지 링크를 클릭하면 Tistory 포스팅을 볼 수 있습니다.

포스팅은 위의 Tistory에도 동일하게 진행했습니다.

1. 문제 설명 

2. 문제 예시 

3. 문제 풀이 

이번 문제는 말 그대로 2번째로 급여가 높은 사용자의 급여를 출력하면 되며

만약에 2번째로 높은 급여가 없는 경우 Null을 출력하면 된다.

위의 경우를 가장 쉽게 생각해보면 가장 Max의 값을 제외한 값이 2번째의 값이다. 

따라서 Max인 값을 제외하고 가장 첫번째의 값을 출력하면 된다. 

# Code 
SELECT max(salary) as SecondHighestSalary  
FROM Employee
where salary not in (select max(salary) from Employee)

위의 설명대로 풀면 위와 같다. 

말처럼 가장 첫번째의 Max값을 구하고 해당 값이 아닌

Max(2번째) 값을 구해주면 된다.

4. 결과

5. GitHub Code

위의 이미지 링크를 클릭하면 코드 확인이 가능합니다.

GitHub에도 동일하게 코드를 올려놨습니다. 

그래서 나는 우선 ssh-key를 github에 등록해줬다.

등록하기 전 내 로컬 .ssh에 key가 존재하는지 확인한다.

우선 나는 id_rsa에 키가 존재하기 때문에 따로 키를 만들어주지 않았다.

만약에 자신의 key가 없다고 한다면 아래와 같이 입력하면 된다.

ssh-keygen -t rsa -C [github 이메일]

위와 같이 입력하게 되면 rsa key가 발급된다.

해당 키를 가지고 이제 아래와 같은 순서대로 진행하면 된다.

1. 우선 자신의 Setting 화면으로 접속
2. SSH amd GPG keys -> New SSH key 클릭

3. Title과 Key를 작성하면 끝
   • Key는 id_rsa.pup 파일에 있는 내용을 추가

위와 같이 진행하면 SSH-Key가 발급된다.

여기서 중요한건 이제부터 Clone을 받을 때 SSH로 받아야 나중에 push시 SSH-Key에 대해서 확인하지 않는다.

1. master|merging 생기는 요인

• 현재 진행하고 있는 프로젝트에서 기존에 있는 파일명과 동일한 파일을 레파지토리(원격 저장소)에 올릴려고 하다가 충돌이 난 상황이다.
• 충돌이 난 경우에 파일 내에서 merge를 하는 방법도 있으나 현재의 경우는 기존에 동일한 파일명이 존재하는데 파일명이 같은 파일을 Push하여 Merge를 하라고 메세지를 알려준다.
• 현재 상황이 되면 master 옆에 Merging이라고 나오며 현재 병합중 상태임으로 다른 브런치로 넘어갈 수 없다.

2. 시도한 방법

• 위의 그림처럼 우선 같은 명을 가진 파일이 충돌난 상황이면 merge를 먼저하는 것이 맞다.
• 그리고 아마도 레파지토리(원격 저장소)의 커밋과 로컬의 커밋이 변경되어서 push를 허용하지 않았던것 같다.

1. 파일을 직접 변경해주는 방법

   

   • 우선 "git diff" 명령어를 이용하여 레파지토리(원격 저장소)와 로컬의 차이를 비교한다.

   • 비교한 뒤 해당 충돌난 부분을 수정해서 다시 커밋해주면 문제를 해결할 수 있다.

2. overwrite update

   • 위의 방식처럼 수정하는 것도 있으나 overwrite update 방법을 진행해봤다.

3. overwrite update?!

• overwrite update는 기존 레파지토리(원격 저장소)에 있는 내용을 내 로컬에 업데이트 한다는 의미이다.
• 즉 레파지토리(원격 저장소)에 존재하는 내용과 현재 내 로컬의 내용에서 충돌났을 때 해결할 수 있는 방법 중 하나이다.

4. git 로컬 파일 업데이트 하기

• 가장 먼저 레파지토리(원격 저장소)에 있는 최신 commit 이력을 가져와야 한다.(최신 파일들로 로컬을 업데이트 할 것이기 때문이다.)

• 그후 레파지토리(원격 저장소)에 있는 파일들을 가져오는 방법으로 진행하면 overwrite update의 과정을 밟을 수 있다.

  

1. git fetch

   • 로컬의 master와 레파지토리(원격 저장소)의 master의 최신 이력을 확인할 수 있고 최신 커밋 이력을 로컬로 가져옵니다.

2. git reset --hard origin/master

   • 현재 HEAD가 가리키는 브랜치를 옮기고 현재 로컬의 디렉토리 상태를 변경해줍니다.

• 위의 단계를 진행하고 나면 merging 표기가 사라지게 된다.
• 즉 overwrite update가 완료되었고 현재 충돌은 해결된 상태이다.
• 마지막으로 충돌났던 동일한 파일명을 변경하 pull과 merge를 이용해서 레파지토리(원격 저장소)와 로컬 master를 통합시켜주면 내가 올릴려는 파일을 문제없이 레파지토리(원격 저장소)(원격 저장소)에 올릴 수 있다.

GraphQL?

• GraphQL은 페이스북에서 만든 쿼리 언어
• 아직 GraphQl API를 Open API로 공개하지는 않았으나 인기가 높은 편이다.

GraphQL?

• (SQL)Stucted Query Language와 마찬가지로 쿼리 언어이다.
• SQL과 GQL의 언어적 구조 차이가 존재한다.
• SQL은 DB 시스템에서 데이터를 가져오는 목적이라면 GQL은 웹 클라이언트가 데이터를 서버로 부터 가져오는 것에 목적을 가진다.
• 문장은 SQL은 백앤드 시스템에서 작성해서 호출한다면 GQL은 클라이언트 시스템에서 작성하여 호출한다.

GQL vs SQL

1. SQL

   • SELECT CUST_NO FROM CUST_MST_TB;

2. GQL

        {
        cust{
            CUST_NO
          }
        }

REST

1. REST

   • Representational State TransFer

   • 자원의 이름을 구분하여 해당 자원의 상태를 주고 받는 것

   • HTTP URL을 통해 자원을 명시,

   • HTTP Method(post, get, put, delete)를 통하여 자원에 대한 CRUD Operation을 적용하는 것을 말한다.

     • 장점

       1. Http 프로토콜의 인프라를 그대로 사용하기 때문에 별도의 인프라를 구축할 필요가 없다.
       2. Http 표준 프로토콜에 따르는 모든 플랫폼에서 사용이 가능
       3. 서버와 클라이언트의 역할을 분리

     • 단점

       1. 사용가능한 메소드가 4개이다.
       2. 표준이 존재하지 않음

2. REST API
   • REST 기반으로 서비스를 구현
   • HTTP 표준을 기반으로 구현하기 때문에 HTTP 지원하는 프로그램 언어로 클라이언트, 서버를 구현 가능하다.

GraphQl 구조

• 쿼리

    {
      cust{
        name
      }
    }

• 응답 데이터

      "data" : {
        "cust" : {
          "name" : "sg-moomin"
        }
      }

  • 느낌표를 이용하면 필수 값을 표현한다.

오퍼레이션 네임 쿼리

• DB에서 프로시저 개념과 유사
• 오퍼레이션 네임 쿼리를 이용하면 한번에 인터넷 네트워크 왕복으로 모든 데이터를 가져올 수 있다.

리졸버(resolver)

• GQL에서는 데이터를 가져오는 구체적인 과정을 직접 구현해야 한다.
• GQL에서 데이터를 가져오는 구체적인 과정을 resolver가 담당한다.
• GQL쿼리에는 각각의 필드마다 함수가 하나씩 존재하는데 해당 함수들을 리졸버라고 한다.

  ex) async (parent, args, context, info) => {
  }

• parent : 부모 리졸버가 리턴한 객체
• args : 쿼리에서 입력으로 넣은 인자
• context : 모든 리졸버에게 전달되며 주로 미들웨어를 통해 입력된 값이 들어 있음
• info : 스키마 정보와 더불어 현재 쿼리의 특정 필드 정보를 가짐

인트로스펙션(resolver)

• 기존 방식(서버-클라이언트)
  • API 명세서를 주고 받는 절차가 필요함(현재 회사 업무와 동일)
  • API 명세서 업데이트가 잘 안되는 오차 및 전달하는 타이밍이 오류 발생하는 경우가 다수임
  • REST 방식의 API 명세서 공유 문제를 해결한 것이 GQl의 인트로스펙션 기능

  • 서버 자체에서 스키마로 실시간으로 정보를 공유할 수 있도록 함

  • 이는 스키마 정보만 알면 연동 규격서가 필요 없어짐

  • 인트로스펙션 쿼리가 따로 존재하지만 GQL 라이브러리에 쿼리용 IDE를 제공함

별칭(Aliases)

• 별칭을 사용하는 경우가 있는데 별칭을 사용하는 경우 필드의 결과의 이름을 원하는 이름으로 바꿀 수 있다.
• hero 필드는 충돌이 났지만 별칭(empireHero, jediHero)을 지정할 수 있다.

Fragments

• GQL을 호출해올 경우 쿼리의 속도는 천차 만별인데 이 때 필드를 한번 이상 반복해야 하는 경우가 생긴다.

• 이 때 Fragments를 이용하여 재사용 가능한 단위를 묶으주면 된다.

  {
    "data": {
      "leftHome": {
        "name": "퇴사",
        "appearsIn": [
          "집",
          "야근",
          "sgMoomin"
        ],
        "friends": [
          {
            "name": "가나 초콜릿"
          },
          {
            "name": "초콜릿 존맛탱"
          },
          {
            "name": "쉬림프 파스타"
          },
          {
            "name": "떡볶이 존맛탱구"
          }
        ]
      },
      "rightHome": {
        "name": "취직",
        "appearsIn": [
          "회사",
          "정시출근",
          "rominPic"
        ],
        "friends": [
          {
            "name": "코딩업무"
          },
          {
            "name": "데이터 보정"
          },
          {
            "name": "할렐루야"
          }
        ]
      }
    }
  }
  

• 위의 필드를 보면 내용이 반복되는 것을 볼 수 있는데 아래와 같이 함축할 수 있다.

  {
  leftHome: hero(episode: sgMoomin) {
    ...comparisonFields
  }
  rightHome: hero(episode: rominPic) {
    ...comparisonFields
  }
  }
  
  fragment comparisonFields on Character {
  name
  appearsIn
  friends {
    name
  }

• 즉 프래그먼트의 개념은 복잡한 애플리케이션 데이터 요구사항을 더 작게 분할하기 위해 자주 사용합니다.

참고자료

• https://graphql.org/
• https://tech.kakao.com/2019/08/01/graphql-basic/