2주차 필수 과제

[codingheim]

필수과제

• 전체 공통

  • 프레임워크와 라이브러리의 차이점

  • 프레임워크란?

    • 프레임워크는 애플리케이션을 개발을 하는데 기본적으로 필요한 구조와 구성을 갖추고 있어 개발자가 기능을 구현하는데에 집중할 수 있도록 도와준다.
    • 프레임워크만으로 프로그램이 동작하는 것이 아니라 뼈대를 제공하고 그 위에 개발자가 코드를 올려 동작하게 도와준다.
    • 객체지향 개발을 하는데 있어 시스템을 일관성있게 관리할 수 있도록 도와준다.
    • “설계는 개발자가 구현은 프레임워크가!” 한 마디로 표현할 수 있을 것 같다.

  • 프레임워크의 장점

    • 가이드를 제공함으로써 프로그램을 체계적으로 관리할 수 있다.
    • 기본적인 설계와 라이브러리를 제공하여 개발 속도를 향상시킨다.
    • 코드의 재사용성이 높고 확장성이 좋다.

  • 프레임워크의 단점

    • 프레임워크에 따른 별도의 학습을 필요로 한다.
    • 자유롭고 유연하게 개발이 불가능하다.
    • 프로젝트의 용량이 증가한다.

  • 라이브러리?

    • 개발을 하기 위해 필요한 것들을 미리 구현해놓은 도구를 말한다.
    • 재사용이 가능한 기능을 미리 구현해놓고 필요한 곳에서 호출하여 사용할 수 있는 집합체이다.

  • 라이브러리의 장점

    • 코드를 재사용하기 쉽다.
    • 코드의 내용을 숨겨 기술 유출을 방지할 수 있다.
    • 이미 구현되어 있는 기능들을 가져다 쓸 수 있어 개발 시간을 단축할 수 있다.
    • 컴파일 시간을 단축할 수 있다. ( 라이브러리는 미리 컴파일되어 있어 링킹만 하면 바로 사용 가능하다)

  • 코드를 구현할때 예외처리를 위해 무엇을 했나요?

  예외처리는 사실 상 복사 붙혀넣어 활용하여 자신있게 알고 있다고는 못하겠어서일단은 사용해보고 어떤 방법이 있는 지 찾아보았습니다.

  • 예외처리를 위한 방법모색 (구글링)
    • 기존에 알고 있던 try catch문을 사용하는 방법
    • @ExceptionHandler 를 사용하여 컨트롤러 내에서 발생하는 예외를 처리하는 방법
      • 컨트롤러가 늘어나는 경우 중복코드가 발생(유지보수가 힘들어짐)
    • 전역에서 예외 처리를 하기 위해 @ControllerAdvice 또는 @RestControllerAdvice를 쓴다.
      • 이 어노테이션은 [[AOP(Aspect Oriented Programming)]의 방식이고, Application 전역에 발생하는 모든 컨트롤러의 예외를 한 곳에서 관리할 수 있게 해준다.

• 백엔드 공통

  • Restful이란?

    • REST는 Representational State Transfer 의 약자이다.
    • Restful 을 말하기 전에 규칙을 REST의 규칙을 알아야할 것 같다.
      • Uniform Interface
      • Client-Server
      • Stateless
      • Cacheable
      • Layered System
      • Self-Descriptiveness
    • REST의 6가지 규칙을 잘 지켜서 설계된 API를 RESTful API라고 한다.이해하기 쉽고 사용하기 쉬운 REST API를 만드는 것을 목적으로 성능이 중요하다면 꼭 RESTful하게 구현할 필요는 없다.

  • 왜 Restful하게 짜야하나요?

    1. 애플리케이션 분리 및 통합
    2. 최근의 서버 프로그램은 다양한 브라우저와 안드로이드폰, 아이폰과 같은 모바일 디바이스에서도 통신을 할 수 있어야 한다.
    3. 이러한 멀티 플랫폼에 대한 지원을 위해 서비스 자원에 대한 아키텍처를 세우고 이용하는 방법을 모색한 결과, REST에 대한 관심을 가지게 되었다.
    4. 다양한 클라이언트의 등장

  • Restful의 장/단점

    • 장점

      1. 별도의 인프라 구축 필요x

      • HTTP를 사용하기 때문에 별도의 인프라를 구축할 필요가 없습니다.

      2. 클라이언트와 서버의 분리

      • 클라이언트와 서버는 REST API를 통해 정보를 주고 받기 때문에 둘 간의 역할이 명확하게 분리됩니다.

      3. 플랫폼에 독립적

      • HTTP를 사용 가능한 환경이라면 플랫폼에 상관없이 사용 가능합니다.

      4. 쉬운 사용

      • 메세지가 자체적으로 무엇을 의미하는지 표현하고 있기 때문에 사용이 쉽습니다.

    • 단점

      1. 표준이 존재하지 않음

      • 명확한 표준이 존재하지 않습니다. 따라서 REST의 특징을 따르지 않으면서 REST API로 설계되는 이상한 API가 탄생할 수 있으며 관리가 어렵습니다.

      2. HTTP Method의 한계

      • HTTP Method를 사용하기 때문에 CRUD라는 단순한 행위의 Method만 지원합니다.

      3. RDBMS와 맞지 않음

      • REST에서는 리소스를 JSON, XML등의 형태로 표현하는데 이는 RDBMS와는 맞지 않는 형태입니다. 그래서 NoSQL쪽이 더 선호되는 추세입니다.

  • Restful의 대안은?

    • 대표적으로 GraphQL이 있다고 한다.

    • GraphQL는 Graph Query Language로 facebook에서 개발한 쿼리 언어입니다.

    • GraphQL은 기존의 REST API의 단점들을 보안하기 위해 나온 통신 규약으로 REST API와 많이 비교됩니다.

    • REST API의 한계

      • REST API는 간단한 서비스에는 문제가 없지만 서비스와 복잡해질수록 Over-Fetching 과 Under-Fetching 문제가 발생할 수 있습니다.

        또한 여러 환경에 맞춰 API를 제공해야하는 것도 쉽지 않은 일입니다.

        따라서 각 환경에 맞추다보니 비슷한 역할을 하지만 Endpoint가 다른 API가 많이 개발됩니다.

      • Over-Fetching

        • Over-Fetching은 클라이언트의 요구사항보다 더 많은 데이터를 반환하는 경우를 말합니다.

          예를 들어 생각해봅시다.

          서버 개발자는 User의 여러 정보를 반환하는 API를 만들었습니다.

          클라이언트는 User의 name 필드만 필요해도 API를 호출해야하고 불필요한 데이터가 많이 넘어오게 됩니다.

      • Under-Fetching

        • Under-Fetching은 클라이언트에서 원하는 데이터들을 위해 여러 API를 호출하는 것을 말합니다.

    • GraphQL을 통한 해결

    • GraphQL은 이러한 단점들을 모두 해결하였습니다. 하나의 Endpoint를 생성하고 클라이언트에게 필요한 데이터를 직접 쿼리를 통해 호출하게끔 하는 방식

    • 마찬가지로 Under-Fetching
       도 하나의 query에 여러 데이터를 호출하여 해결할 수 있다고 함.

      • 장점

        하나의 Endpoint

        위에서도 언급했듯이 GraphQL은 하나의 Endpoint를 갖습니다.

        클라이언트 입장에서도 한 군데로만 요청을 보내면 되고 여러 API를 신경쓰지 않아도 됩니다.

      • 단점

        캐싱

        하나의 Endpoint를 사용하기 때문에 HTTP에 제공하는 캐싱 전략을 그대로 사용하는 것이 불가능합니다.

        따라서 GraphQL만의 캐싱 방법이 필요합니다.

        파일 업로드

        GraphQL은 아직 파일 업로드에 대해서 구체적인 구현 방법이 정의되어 있지 않습니다.

        따라서 개발자 스스로 해결해야합니다.

        그렇기 때문에 업로드만을 위한 분리된 API를 개발하기도 합니다.

  • Restful하게 짜기 위해 무엇을 고려했나요?

    • URL Rules
      1. 마지막에 ' / ' 를 포함하지 않는다.
      2. _ 대신 - 를 사용한다.
      3. 소문자를 사용한다.
      4. 동사(행위)는 URL에 포함하지 않는다.
      5. 컨트롤 자원을 의미하는 URL 예외적으로 동사를 허용한다.
      6. 컬렉션, 스토어 이름으로 복수 명사를 사용해야 한다.
      7. URI에 행위에 대한 동사 표현이 들어가면 안된다.
      8. 확장자가 들어가지 않는다.(ex. jpg) - URI 는 고유한 리소스를 나타내야함
    • HTTP Headers
      1. Content-Location
      2. Content-Type
      3. Retry-After
      4. Link
    • Use HTTP methods
      1. GET, POST, PUT, DELETE 4가지는 반드시 제공한다.
      2. OPTIONS, HEAD, PATCH를 사용하여 완성도 높은 API를 만든다.
      3. PATCH
          : PUT대신 PATCH method를 사용한다. 자원의 일부를 수정할 때는 PATCH가 목적에 맞는 method 다.
    • Use HTTP status
      1. 의미에 맞는 HTTP status를 리턴한다.
      2. HTTP status만으로 상태 에러를 나타낸다.

• Spring

  • Entity 설계를 위해 무엇을 하였나요? 연관관계에 근거하여 설명해주세요.

    • 테이블 설계

    • 1:N 관계에서는 N 쪽이 무조건 외래키가 존재한다.

    • 일대다, 다대일 양방향 관계에서는 연관관계의 주인을 정해야하는데, 외래키가 있는 쪽을 연관관계의 주인으로 정하는 것이 좋다.

      • Ex. 주문과 회원일 경우 주문쪽이 연관관계의 주인
      • 연관관계의 주인쪽에 값을 세팅해야지만 값이 변경된다.
      • 연관관계의 주인을 FK로 정해야하는데 그 이유는, 연관관계를 맺고 있는 두 테이블(회원과 주문)의 수정작업이 있을 때, FK(주문 테이블쪽의 회원ID)를 수정해야지만 유지보수 측면에서 우수하다. 즉, 주문 테이블의 회원번호가 변경되었으니 회원의 회원번호도 변경된다라는 것을 자연스럽게 인식할 수 있다.
      • 회원과 주문사이의 연관관계가 맺어있을 경우 연관관계의 주인은 주문의 회원번호가 되고, 회원의 주문관련컬럼은 단순히 매핑만 되는 것으로 회원쪽 Entity에 매핑 여부를 기입한다.

      public class User{
        //user 1 : good N | 이쪽 goodList는 단순히 good에게 매핑만 된다. goodList가 변경되어도 Order의 FK는 변경되지 않는다.
        @OneToMany(mappedBy = "member")  
          private List<Good> goodList = new ArrayList<>();
      }
      
      public class Good{
        //Good N : User1 | 해당 값의 변경이 일어날 시 user의 id값도 변경이 일어난다. 
        @ManyToOne  
        @JoinColumn(name = "user_id") //FK
        private User user;
      }

    • 일대일 관계인 경우 FK는 보통 access가 많은 쪽으로 정하면 된다.

      • 그렇다면 연관관계의 주인은 FK가 있는 곳으로 잡으면 된다.
      • Ex. 주문과 배달의 경우 주문쪽이 access가 많고 해당에 FK를 줄 것이므로 연관관계의 주인은 주문이 된다.

      내용이 너무 깊어서 어려웠던 한 주 였다..

-Level2과제

• CORS 해결하기
• CORS란 무엇이며, 어떤 상황에서 일어나는지 / 어떻게 해결하는지 알아보고, 프로젝트에 적용하기
• N+1 문제와 해결법
• 레이지 로딩, 이거 로딩의 원리