[ 시리즈물 ] 클라이언트단에서의 API 요청 응답 과정에서 일어나는 일들에 대한 고민

블로그 먼지털어서 글 쓰기 시작.. ㅎ..

 

시리즈 목차 ( 주의 : 다 연재 안 될 수도 있음 )

0.  시작하며  ( 현재 글 )
1. 응답클래스 영역에 대한 고민
2. 요청 클래스

 

0. 서문 

( 매일이 하는 것도 없이 바쁜지라 SNS 글 썼던 내용 다듬어서 일단블로그로 정리합니다. )

안녕하세요. 아시는 분은 알겠지만, 개발경력 1.5년정도 이후로 화면코드를 많이 다루게 되어서

프론트엔드 개발자라고 할 수가 있긴한데, 그렇다고 전문 프론트엔드는 아니었지만 조금씩 깊이를 더해가려고 하는

주식 좋아하는 한량 개발자입니다...

 

그래도 본업이 현재 개발이니까 뒤처지는 개발자는 되기 싫어서 이것저것 강의를 보다보니,

실력 향상에는 글 쓰기라고 최근에 다시 강의를 봐서.. 신년이기도하고,  그동안 혼자 개발한 기간도 길기도해서 글을 써보고자 합니다.

서버도 그렇겠지만 제가 화면단을 다루는 사람으로써, 피하고 싶은 상황은 파편화입니다.

 

 

1. 파편화를 추억하다 

 

 

화면을 그리는 영역에는 어떤 컴포넌트 재사용과 그 컴포넌트에서 약간 변화를 주는 형태가 많이 나타나기 때문에..
N 개의 컴포넌트를 만들일이 많이 생기게 되는데,

화면 컴포넌트 예시

(화면 컴포넌트 예시) 

이러한 컴포넌트에서 어떤 디자인 요구사항변경이라던가 비즈니스 요구사항변화같은 변화의 순간에
N 개를 매번 작업하는 순간을 저는 파편화된 작업이라고 생각합니다.

이런 파편화된 작업은 서버 기준으로 보자면 기본 타입인 string 이 알고보니 객체의 책임이라던가, 

화면으로 생각해보자면, 컴포넌트화되어있지 않고 중복되어서 분산되어져있는 화면 컴포넌트.

 

제 옛날 첫 회사의 추억을 생각해보면,  게시판 형태의 여러 도메인들이 여러개가 있었는데, 이 도메인들별로 공통화될 수 있는 부분을 찾아내고, 우선 공통과 변화를 분리해야하는 일이 선행되어야 했었을텐데,

각각의 대여섯명의 나이가 비슷한 개발자들이 서로 비슷한 로직을 개발하면서, 누군가가 먼저 하면 네이트온 채팅으로 코드 전파(?)가 이루어지고 붙여넣기하고 서로 감사 하면서 퇴근했던 기억..이랄까요 (먼산)

 

 

그러다가 비즈니스 요건이 변화하는 순간..음.. N 개의 고민이 시작되곤 하던 추억입니다.

=================================

 

 

이런 같은 컴포넌트에 대한 N 개의 수정을 피하기 위해..
화면단에서는 리액트 컴포넌트라던가, CSS 클래스를 상위레벨부터 설계하고 뭐 그런 작업을 하지 싶습니다.

 

 

2. 클라이언트에서 네트워크 요청에 대한 N 개와 잡다한 고민들

물론 이런 파편화는 API 처리에서도 많이 나타날 수가 있다고 생각합니다.

 

api example 치면 나오는 해외블로그

 

 

위의 요청으로 api 를 하나하나 그려나가면서 

API 요청이 비즈니스로직상 여기저기 100개 정도 썼다고 했을 때..

어느순간 api 에 우리는 어떤 언어정보나 버전정보를 추가해서 보내기로 하는 등의 수정사항이 발생하면..

100개의 수정을 할 수는 없으므로 중앙화된 API 요청에 대한 고민을 개발자들을 각자 하기도 합니다. 

 

API 에서 발생하는 일들의 각 요구사항에 대한 글을 구글링을 해보면 여기저기 파편화되어서(...)

찾아볼 수 있긴하지만, 뭐랄까.. 경험이 조~~금 있는 개발자로써 API 요청시 일어날 수 있는 일들과 각 영역에서 벌어날 수 있는 비즈니스 요건, 코딩의 풀이등에 대하여 전체적으로 이야기를 해보면 좋겠다는 생각이 들었습니다.

 

앞서도 적었지만, API 부분에서 중앙화를 처리하는 부분에서 요청과 응답을 처리하면서 신경써야할 부분이 많으므로

화면단의 API 요청은 꽤 비싼 작업이라고 생각합니다.

 

 

2. 1 API 잡다한 고민들의 열거

몇가지 나열해보자면

이중클릭방지,

타임아웃처리,

단일서버만을 주로 하는 클라이언트인 경우 url 서버처리,

인증처리,

인증처리실패할 경우 로그인 페이지로 Redirection,

다국어인 경우 다국어정보 추가,

 

로딩애니메이션 처리 ( 스피너는 버튼과 화면단, 더보기 요청인 경우 다른 영역에 스피너 포함 + 스켈레톤으로 보여주는 형태) : https://medium.com/myrealtrip-product/%EC%83%81%ED%99%A9%EC%97%90-%EB%A7%9E%EB%8A%94-%EB%A1%9C%EB%94%A9-%EC%95%A0%EB%8B%88%EB%A9%94%EC%9D%B4%EC%85%98-%EC%A0%81%EC%9A%A9%ED%95%98%EA%B8%B0-2018af51c197

상황에 맞는 로딩 애니메이션 적용하기

API 요청 중 실패한 경우 4xx, 5xx 번대의 에러 화면 구성 메시지 표현의 방안 고민.
여기서 다시 API 요청을 GET 요청과 POST 요청으로 나누어서 POST 요청의 경우 필드에도 나타내는 방법의 고민
서버 에러메시지를 화면에 보여주는 형태, 폼필드 하단 형태, 토스트 형태의 상황별 발생
폼밸리데이션 서버실패인 경우 화면단의 폼 에러 렌더링

로딩,데이터,에러의 상태표현,
실패한 API 의 경우 재시도가능처리,
액세스토큰 만료된 경우 재갱신처리,

여러 병렬api 요청인 경우 윗 개념 + 묶음 처리,

에러 로그 수집,

서버응답받고 타입스크립트쓰면 JSON -> 인스턴스화까지? 등등..

 

여러가지 상황을 종합적으로 고려를 해야 된다고 생각합니다. 

 

 

Validation 쪽을 조금 살펴보면.. 

 

생각해볼 수 있는 내용들이 에러 메시지 구성에 대한 내용이긴한데.  윗 RFC 링크는 원문 스펙을 참고는 해야되니 그냥 적어둬봤고, 치즈윤님의 링크가 전 와닿았습니다.

 

https://www.rfc-editor.org/rfc/rfc7807

RFC 7807: Problem Details for HTTP APIs

 

 

 

https://cheese10yun.github.io/spring-guide-exception/#error-response-json-1

Spring Guide - Exception 전략 - Yun Blog | 기술 블로그

전 참고로 치즈윤님이 적어주신 형태를 좋아하기도하고 

"errors": [
    {
      "field": "name.last",
      "value": "",
      "reason": "must not be empty"
    },
    {
      "field": "name.first",
      "value": "",
      "reason": "must not be empty"
    }
]

 위의 RFC 스펙 제안 글에 있는 형태 좋아하긴합니다^0^

"invalid-params": [ {
                         "name": "age",
                         "reason": "must be a positive integer"
                       },
                       {
                         "name": "color",
                         "reason": "must be 'green', 'red' or 'blue'"}
                     ]
   }
]

 

이런 여러가지의 신경써야될 부분을 API 템플릿으로 만들어서

헌터헌터 네테로 회장의정권지르기처럼 기를 모아서 중앙화/템플릿 처리해서
만가지의 초식을 다시 한가지의 주먹으로 단순화시켜서 API 요청을 보내는 것을 이상향으로 한달까요?

 

https://www.youtube.com/watch?v=pwiP6vfOtSM 

이상향은 이상향이고, ( 디자인 못 받고 상황 애매하면 좀 표현 덜하기도 합니다만...쿨럭..)

 

한글로 이미 정의를 하는 순간에 코드구성이 좀 나오니까,

영역을 나눠 적자면 상위의 공통 네트워크 요청, 읽기요청, 쓰기요청이 있고,

위에서 말한 행동들을 여러 영역에서 같이 도와가면서 협력해가며 API 요청을 풀어보는 모델을 누구나 간직하고 있지 싶습니다.

 

어린이가 학교 안가고 혼자 크면 바보된다고 하는 이야기. 정글북에서의 늑대 소년의 덜 문명화된 이야기를 가끔 떠올리면서 많은 시간을 화면단을 거의 혼자 개발하면서 살아오긴했는데 ( )

최근에는 같이 화면 일하는 동료 분들이 생겨서 이런저런 개념을 설명하다보니..

몇 개 관련된 글을 보긴했긴 하지만, 다른 회사분들은 어떤 방식으로 이런 일들을 처리하시나 궁금해서

저의 생각도 정리해볼 겸 이곳에 중얼중얼거려보네요

마무리.

위와 같은 개념의 나열을 난 심법이라고 표현하고, 실제 구현을 초식이라고...하는데 옆동네 초식이 조금 궁금하달까요

다음 편은 어쩌다 적게된 응답클래스쪽에서 일어날 수 있는 일등을 적어보고자 합니다.