항해 40일차 TIL

YONS 2022. 2. 18. 11:00

1. 더이상 TIL은 아니고 그냥 일기지만

그래도 제목의 통일성을 위해 계속 TIL을 사용하고 있다.

주특기 1주차가 끝났다. 내가 뭔가 성장했나? 다시 뭔가를 만들라고 하면 만들 자신은 없다. 그래도 과제 제출은 했으니까 어찌저찌 따라가고는 있나보다. 오늘부터는 이제 협업인데... 내가 할 수 있을까 생각부터 든다. 이러면 안되는데.

시작부터 겁먹지 말자!!!! 내가 이팀의 에이스가 되겠어!!!! 좋아 마인드셋팅 끝났다 다시 고

2. varchar와 텍스트 차이가 뭐야?

ERD 작성해야하는데, 다른 사람들 한거 참고하다보니까 varchar와 text를 둘 다 사용한게 보였다. 왜 char가 아니고 varchar인지, 또 text는 무슨 차이인지 몰라서 검색.

일단 짚고 넘어갈 것 : 이건 자바에서 사용한다! 자바스크립트는 그냥 string으로 통일. 그래도 찾아본게 아까워서 긁어와서 올렸다.

char만 fixed length type이고, text와 varchar는 variable length data type 입니다.

아래 레퍼런스 글을 바탕으로 정리해보자면, text와 varchar는

max size limit을 정할 수 있는가
- text: 없다, 무조건 65535
- varchar: 있다. 1 ~ 65535

저장된 character 외의 현재 저장하고 있는 string의 사이즈를 저장하는데 1~2 byte를 더 쓴다
- text: 무조건 2 byte
- varchar: x <= 255 then, 1 byte, 256 <= x <= 65535 then, 2 byte

index의 일부로 쓰일 수 있는가
- text: 없다
- varchar: 있다

기타
- text: disk에 저장해서 느림
- varchar: memory에 저장해서 빠름

출처 : https://chuckolet.tistory.com/71

오오... 티스토리는 이렇게 사용해야하는데. 타인에게 도움을 주는 내용을 적고 나처럼 일기는 앵간히 써야하는데..! 어쨌든 일단 그렇다.

어쨌든 나중에 스프링이랑도 협업할 수도 있으니까. 일단 알아둬서 나쁠건 없는 것 같다.

3. 스트레스 처리

짧은 시간 안에 많은 양의 정보를 머릿속에 꽉꽉 눌러담다 보면 머리가 거부하기 시작한다... 그럴 땐 고양이 만지면서 힐링하고 오면 조금 나아진다. 우리집 고양이들이 다들 순한 성격이어서 너무너무 고맙다...

4. 그래서 식별자와 비식별자 차이는?

erd 작성하는 법 공부하고 있는데 식별자 비식별자 얘기가 나왔다. 점선 실선으로 구분해주는것까진 알았는데, 식별자와 비식별자가 뭐하는건지를 몰라서 그게 정확히 무슨 얘긴지 알아듣지 못했다.

대충 부모 엔티티로부터 속성을 받았는데 그게 주식별자면 식별자 관계, 속성은 받았어도 주식별자가 아니면 비식별자 관계.

그럼 이제 주식별자가 뭐하는건지 몰라서 또 찾아봤더니- 간단했다. Primary Identifier, 다른 말로는 Primary Key라고도 부르는거였다. 바로 내가 배운 그 PK!

참고 : https://hoon93.tistory.com/22 (식별자, 비식별자)

https://dataprofessional.tistory.com/96 (주식별자)

5. 리덕스의 재발견

리덕스로 너무 고통받았어서 이번 과제엔 리덕스를 별로 사용하고 싶지가 않았다. 리코일을 쓰더라도 새로운 기능을 써보고 싶어서 쓰는 방향이어야 하는데... 이렇게 회피해서는 안되는데... 어쨌든. 리코일과 리덕스에 대해 찾아보다가 이런 글을 발견했다.

Q. 언제 리덕스가 필요할까요?

리덕스를 사용한 개발 스타일이 너무 마음에 들 때
제 주변에서 리덕스를 사용하는 사람들을 보면 두 집단으로 나뉩니다. 첫번째는 “와! 리덕스 정말 좋아!” 라는 반응을 갖고 있는 사람이고, 두번째는 “리덕스 너무 불편해!” 라는 반응을 갖고 있는 사람들입니다. 제가 느끼기엔, 적당한 상황에서 쓰면 정말 편하고 좋은 도구이고, 불필요한 상황이면 번거롭고 불편할 수도 있습니다. 특히, 처음 공부하는 과정에서 사용해야 하는 이유를 정확히 이해하지 못하고 무조건 사용하는 경우엔 더더욱 불편하게 느껴지겠죠. 모든 상태 업데이트를 액션으로 정의하고, 액션 정보에 기반하여 리듀서에서 상태를 업데이트하는 이 간단명료한 발상 덕분에, 상태를 더욱 쉽게 예측 가능하게 하여 유지보수 측면에 긍정적인 효과가 있죠. 이게 마음에 드는 사람들은 계속 리덕스를 사용하시면 됩니다.
미들웨어
리덕스와 다른 라이브러리들의 특별한 차이점은 미들웨어가 존재한다는 것 입니다. 특정 액션이 디스패치 됐을 때 상태 업데이트외의 다른 작업들을 따로 처리 할 수가 있죠. 보통 API 요청을 할 때 미들웨어를 사용하곤 합니다. 이전에는 API 요청을 위하여 리덕스와 미들웨어를 사용하는 것이 당연시 되긴 했는데, 이제는 SWR 과 react-query 같은 라이브러리가 있기 때문에 단순 API 요청을 위하여 미들웨어를 사용 할 필요는 없습니다. 그렇지만, 비동기 작업에 대한 플로우에 대하여 더 많은 컨트롤을 필요로 할 때 미들웨어는 정말 유용하게 사용 될 수 있습니다. 미들웨어로 편하게 해결 할 수 있는 상황들에 대해서는 이 포스트에서 추후 다뤄보겠습니다.
서버사이드 렌더링
리덕스를 사용하면, API 요청 결과를 사용하여 서버사이드 렌더링을 하는 것이 용이합니다. 이 과정에서 미들웨어가 정말 유용하게 사용되지요. 리덕스가 없어도 충분히 구현 할 수는 있긴 하지만 레퍼런스도 부족하고 번거로운 편입니다. 물론, Next.js 를 사용한다면 조금 다른 얘기이긴 합니다. 이 포스트에서 설명했던 다른 대안 Recoil, Jotai 등의 라이브러리는 아직 서버사이드 렌더링을 처리하기엔 준비가 되어있지 않습니다 (언젠간 정식적으로 지원을 할 것으로 보입니다.)
더 쉬운 테스팅
리덕스를 사용한 앱은 테스트를 하기가 비교적 쉽습니다. 리듀서에서 다양한 상태 업데이트에 대한 로직을 테스트하기도 쉽고, 리덕스와 연동된 컴포넌트를 테스트 할 때 Mocking 할 수도 있고 미들웨어의 작동방식도 Mocking 할 수 있습니다.
컴포넌트가 아닌 곳에서 글로벌 상태를 사용하거나 업데이트를 해야 할 때
WebSocket을 사용한다거나, 리액트 네이티브 브릿지에서 연동을 할 때 getState 또는 dispatch를 바로 호출해서 사용하면 꽤 유용한 상황이 있기도 합니다.
그냥 많이 사용 돼서
많은 개발자가 리덕스를 사용하는 이유중엔.. 이미 유지보수를 하고 있는 프로젝트에서 리덕스를 사용중이기 때문이 확률이 크다고 생각합니다. 분명히, 과거에는 선택지가 별로 없고, MobX가 그나마 유일했었으니까요. 프로젝트에 리덕스가 필수적이라고 느껴지지 않는다고 해서, 아예 걷어내는건 또 큰 공수가 드니 계속 유지하면서 사용하는 케이스도 많을 것이라 생각합니다. 다만, 그러한 경우엔 새로운 기능 또는 리팩토링 하는 기능에 있어선 다른 방식을 시도해보는것도 좋을 것이라 판단합니다.

출처 : https://ridicorp.com/story/how-to-use-redux-in-ridi/ 리덕스, 리코일 전반적인 설명

그.런.데. 리디의 저 글을 읽다보니 리덕스 툴킷이라는 것을 알게 됐다..!!!!

"2020년엔 리덕스 개발팀에서 드디어! 공식적으로 Redux Toolkit 이라는 라이브러리를 릴리즈했습니다. 이 라이브러리가 있다면, 리덕스가 불편하다는 편견을 깰 수 있다고 감히 말씀드릴 수 있습니다. Redux Toolkit을 사용하면 리듀서, 액션타입, 액션 생성함수, 초기상태를 하나의 함수로 편하게 선언 할 수 있습니다. 이 라이브러리를 사용하면 이렇게 리듀서와 액션 생성 함수를 한방에 만들 수가 있답니다. 그리고, Immer가 내장되어있기 때문에, 불변성을 유지하기 위하여 번거로운 코드들을 작성하지 않고 원하는 값을 직접 변경하면 알아서 불변셩 유지되면서 상태가 업데이트 됩니다."

호오...!!! 그리고 타입스크립트도 호오...!!!!! 리덕스야... 내가 그렇게 욕해서 미안하다... 내가 무지했던 것을... 다들 잘 쓰고 있는데는 이유가 있었던 것을... 역시 사람은 배워야한다

6. 그럼 리코일은?

https://recoiljs.org/docs/introduction/motivation 리코일 공식 문서

7. 그리고 r-q와 swr

아니 세상에... 위 리디 문서에서 이런 좋은 내용도 발견했다.

API요청은 이제 react-query, SWR에게 맡기자

저희 팀에서는 API 요청에 관련한 코드들을 리덕스와 미들웨어로 관리해왔었습니다. 웹에서는 프로미스를 기반으로 API 요청 상태를 관리하는 미들웨어를 직접 만들어서 관리하다가 나중엔 redux-saga를 사용했습니다. 리덕스로 요청에 관련된 상태를 관리하려면 요청 시작, 요청 성공, 요청 실패에 대한 3가지 액션들을 준비해야 하고 해당 액션들을 처리하는 로직들도 준비해줘야 하지요.

예시) getEpisode, getEpisodeSuccess, getEpisodeError

모든 요청들에 대하여 위 액션 그리고 리듀서를 준비해주는 작업은 은근히 번거롭습니다. 그래서, 저희는 다양한 유틸 함수를 만들어서 최소한의 코드로 구현을 할 수 있도록 만들었었습니다.

2020년에는 react-query와 SWR 라는 라이브러리들이 릴리즈되었습니다. 두 라이브러리 모두, Hook을 사용하여 API 요청 상태를 관리하고, 또 캐시 관리도 아주 멋지게 해내죠. 위 라이브러리들을 사용하면 기존에 저희가 해오던 방식보다 더욱 효율적이고 편하게 API 상태 및 캐시 관리를 할 수 있었습니다. 저희는 이 라이브러리들이 성숙화 되어가는 것을 지켜보다가 2020년 하반기에 라프텔의 모든 클라이언트 프로젝트에 (Web, TV, React Native) react-query를 도입했고 아주 만족스럽게 사용하고 있습니다

저희는 서버사이드 렌더링 때문에 react-query와 SWR 중 react-query를 선택했습니다. SWR은 Next.js를 만든 Vercel팀에서 만든 것이기에 서버사이드 렌더링을 하는 경우 Next.js 와 함께 사용해야합니다 (적어도 공식 문서에서는 해당 내용만 다룹니다). 반면 라프텔에서는 Next.js를 사용하지 않기 때문에 SWR이 저희에겐 적합하지 않았습니다. 그리고, react-query의 queryCache 기능이 다양한 상황에 유용하게 사용 될 수 있어서 현재 매우 편하게 사용을 하고 있습니다.

위 두 라이브러리는 모두 훌륭한 솔루션들입니다. 여러분의 프로젝트에서 API 요청 하는 작업을 현재 리덕스와 미들웨어를 기반으로 구현을 했더라면, 점진적으로 둘 중 하나에게 해당 작업을 위임을 하는 것도 매우 좋은 선택지라고 생각합니다.

출처 : 위의 리디 문서 (링크는 위에 있으므로 생략)

https://react-query.tanstack.com/overview react-query 줄여서 r-q 공식문서

https://swr.vercel.app/ko swr 공식문서