# Today I Learned (TIL)
03 / 09 Today I Learned (TIL)
오늘은 Docker에 대해 배웠다 Docker 내 컴퓨터 안에 컴퓨터 1대를 더 설치하자 옛날에는 컴퓨터 안에 가상머신(ex: vmware)을 설치하여 전부 같은 운영체제를 쓰게 한다 단점으로 컴퓨터 안에 컴퓨터를 설치하다 보니 느렸음 해결책으로 나온게 Docker 운영체제의 핵심 기능(커널)은 공유하는 가상머신 맥이랑,리눅스는 기능을 공유하는데 크게 문제 없지만 윈도우랑은 너무 달라서 힘듬 그래서 WSL이란것을 설치하여 사용 Docker에 필요한 프로그램들을 다 넣어두고 해당 Doker만 넘겨주면 그걸 설치할줄만 알면 자동으로 회사의 개발환경에 맞춰서 자동으로 설치되기 때문에 효율적 Docker를 다루는 방법을 배웠다!
03 / 08 Today I Learned (TIL)
와이어샤크: 실시간 패킷 교환 과정을 확인하는 도구 중 하나 이걸 사용하여 보면 https통신은 데이터가 암호화 되어 있지만 http는 암호화 되어 있지 않고 그냥 보인다 3-way-handshake-연결 프론트엔드 컴퓨터에서 백엔드 컴퓨터로 요청을 보내는 것을 ‘SYN’ 백엔드 컴퓨터에서 프론트엔드 컴퓨터로 요청에대한 응답을 ‘SYN + ACK’ 다시 프론트엔드 컴퓨터에서 백엔드 컴퓨터로 ‘ACK’를 돌려줌 4-way-handshake -연결해제 일정시간동안 아무활동이 없다면 자동으로 연결을 해제하는데 그때 ‘FIN’을 돌려주게 되고 그게 4-way-handshake이다
03 / 07 Today I Learned (TIL)
배포란 여태 우릭가 만들었던 홈페이지를 세상에 공개하는것을 의미한다 배포를 이해하기 전에 클라우드 서비스를 알아보자 클라우드 서비스란 간단하게 원격으로 컴퓨터를 대여해서 해당 컴퓨터에 접속할 권한을 주는것 크게 AWS, GCP, AZure가 있다 1단계 배포 우리의 웹파일을 html파일로 변환시켜서 스토리지(무제한 용량을 제공하는 온라인 스토리지 서비스)에 올려두면 해당 html을 다운 받을수 있는 다운로드 주소를 얻을수 있다 그걸 DNS에 내가 구매한 도메인으로 접속한 사람들은 html 다운로드 주소로 접속하게 설정을 한다 이렇게 하면 사용자가 내가 구매한 도메인으로 접속 -> DNS가 html다운로드 주소로 가게 만들어서 html을 다운받음 -> 해당 html을 웹브라우저가 읽어서 화면에 뜸 위와 같은 순서로 이루어 지게 된다 이 방식은 정적 라우팅만 가능하며 보통 회사홈페이지, 소개홈페이지 같은 것들에 사용된다 2단계 배포 그러면
03 / 06 Today I Learned (TIL)
오늘은 테스트 코드 작성 하는 방법을 배웠다 테스트코드는 내가 만든 기능들이 정상적으로 작동하는지 테스트를 해주는 코드이다 이걸 굳이 코드로 작성 하지 않고 그냥 직접 테스트를 해보면 되지 라는 생각을 할수 있지만 그건 좋지 않다 만약 나의 서비스의 기능이 30개 정도 있다고 하자 추후 업데이트로 인하여 새로운 서비스 기능을 15개를 만들어서 적용을 시키려고 한다 근데 여기서 이 15개가 기존의 있던 30개와의 어떠한 충돌을 일으킬지 모르기 때문에 직접 테스트를 해봐야 하는데 이게 처음은 기능이 몇개 없어서 직접 테스트를 하는게 편할지 몰라도 기능이 점점 많아지면 똑같은 테스트를 또 하고, 또 하게 된다 그러다 보면 놓치는 일이 발생 하기도 하기 때문에 차라리 그 테스트를 코드로 만들어서 돌리는 편이 더 효율적이기 때문에 테스트 코드는 중요하다 테스트 코드는 jest와 cypresss가 있다 jest는 기능테스트 cypresss는 유저 입장에서 테스트를 진행하
03 / 02 Today I Learned (TIL)
옵티미스틱UI 중요한곳에 사용하면 안됨 덜 중요하면서 실패해도 문제가 안되고, 성공확률 99%인 것들에 사용하자 optimisticResponse을 사용하면 입력된 값으로 응답을 받았다고 생각을 하고 data에 적용시킨다 그후에 진짜 데이터가 들어왔을때 값이 다르면 바꾸고 같으면 바꾸지 않는다 scraping(스크래핑) 사이트의 한 페이지의 모든 데이터를 받아 오는것 crawling(크롤링) 스크래핑을 여러번 진행하는것 Open Graph 디스코드,카카오톡 같은 곳에서 특정 웹사이트 링크를 올리면 해당 사이트의 사진과 정보가 나오는것을 알수있다 이것을 Open Graph 라고 한다 위와 같이 작성하면 미리보기 기능이 구현된 곳은 주소를 올리면 사진과 정보가 뜬다 그럼 이번에는 우리가 그 미리보기 기능을 구현해 보자 하지만 여기서 axios요청시 CORS를 막아둔곳도 존재하기 때문에 그럴 경우에는 다른 방법으로 받아와야함 (ex: 백엔드서버이용)
02 / 28 Today I Learned (TIL)
기존 이미지 업로드 문재점 미리보기가 너무 느림: 클라우드 서비스에 저장한후 다운로드 url을 받고 그걸 띄우다 보니 느림 이미지 찌꺼기가 남음: 이미지를 클라우드서비스에 저장후 게시글 등록 안하고 그냥 나가버리면 해당 클라우드에는 계속 다운로드 url이 남아있음 해결방법 이미지를 올리면 브라우저에 임시url을 만들어서 미리보기에 띄우기 브라우저에 임시로 해둔거기 때문에 찌꺼기도 등록안하면 자동으로 사라짐 위와 같이 2가지 방법이 존재한다 createObjectURL방식은 최근에 나온 방식으로 내 브라우저에서는 URL에 접근이 가능하지만 다른 브라우저에서는 접근이 불가능하다 FileReader 방식은 진짜 URL을 생성 다른 브라우저에서도 접근이 가능하다 Promise.all api요청을 연속으로 진행해야 할때가 있다 그럴때 하나 하나 하면 시간이 너무 오래걸리기 때문에 한번에 전부 요청하여 모든 결과가 올때까지 기다린후 다음 코드를 진행한다 Laz
02 / 27 Today I Learned (TIL)
메모이제이션(Memoization): 리렌더링이 많아질수록 성능이 저하되기 때문에 리렌더링이 필요 없는 것들은 리렌더링을 막을때 사용 (useCallback(),useMemo(),memo()) useCallback(),useMemo() 불필요한 값들이 지속적으로 다시 만들어지지 않도록 유지시켜주는 hooks useEffect처럼 사용하면 된다 단, 이전에 불러왔던 값을 유지시키기 때문에 useCallback사용시 setState는 setState(state + 1)이 아닌 setState((prev)=>prev + 1)을 해야한다 컴포넌트를 import 해서 사용할때 부모가 리렌더링 되면 해당 컴포넌트도 같이 리렌더링 된다 이것또한 memo()를 이용하여 리렌더링 안되게 막을수 있다 useMemo,useCallback,memo 들은 값이 변경이된걸 props 같은걸로 값을 넘겨주게 되면 memo를 사용했어도 리렌더 된다 그러면 모든곳에서 사용하면 될까 라고 생각
02 / 24 Today I Learned (TIL)
observable(옵저버블) 이란 연속적인 비동기 작업을 도와주는 도구이다 a ,b 라는 버튼이 있다 각각의 버튼을 누르면 데이터를 요청하여 받고 그걸 화면에 뿌리는 코드가 작성되어 있다 여기서 a버튼은 데이터가 많아서 받아오는데 오래 걸리고 b버튼은 반대로 데이터가 적어 빠르게 받아온다고 하자 b버튼을 눌려야 하는데 실수로 a버튼을 누르고 바로 다시 b버튼을 눌렸다 그러면 b의 결과가 화면에 띄워지고 조금 있으면 a의 결과로 화면이 변경된다 이러한 상황을 막을려면 a버튼의 데이터를 요청후 b버튼 데이터를 요청했을때 a버튼 데이터를 취소시키고 b를 요청해야한다 하지만 이런경우는 promise로 처리 하는게 어렵기 때문에 observable을 사용하게 된다
02 / 23 Today I Learned (TIL)
오늘은 RefreshToken에 관해 배웠다 RefreshToken: AccessToken의 만료 기한이 지나면 새로운 AccessToken을 받아와야 하는데 이러한 과정에 사용되는 토큰이다 AccessToken은 보통 (1시간) RefreshToken은 (2주) 정도 이지만 회사마다 다르다 api를 요청했을때 AccessToken이 만료이면 자동으로 RefreshToken을 사용하여 새로운 AccessToken을 받아오게 하고 해당 api요청을 자연스럽게 닥시 요청하게 한다 이러한 인증을 silent Authentication라고 부른다 * 쿠키의 secure / httpOnly 옵션 httpOnly : 해당 속성을 달면 자바스크립트로 접근이 불가능해진다 통신으로만 사용가능 secure: 이건 https 통신시에만 쿠키를 사용 가능 마이크로 서비스 아키텍쳐(MSA) 서버를 용도에 따라 나눈것 크게 2가지로 나눈다 AuthService (인증 서비스관련) Reso
02 / 22 Today I Learned (TIL)
태스크큐에는 마이크로큐와 매크로큐가 있다 마이크로큐: await, Promise같은 것들이 담김 매크로큐: setTimeout,setInterval 같은 것들이 담김 매크로큐보다 마이크로큐가 우선순위가 높아 마이크로큐가 비워질때까지 매크로큐는 진행하지 않는다 위 코드에서 catch문이 정상작동 하지를 않는다 그 이유는 axios는 Promise 즉 aixos.get은 마이크로큐로 사라지게 되고 그럼 try는 비어버리게 된다 즉 try-catch문이 끝나게 되는것 그 후에 마이크로큐에 잇는 axios를 읽을때 에러를 발생하기때문에 try-catch문이 정상작동 하지를 않는것이다 그럼 해결방법은 무엇일까?? 위와 같이 axios 앞에 await를 해서 try-catch문도 같이 마이크로큐로 보내버림으로써 해결이 가능하다
02 / 21 Today I Learned (TIL)
포트원을 사용하여 결제를 구현해 보았다 결재의 큰 순서는 브라우저에서 결제요청 포트원의 Rest-API를 이용해 결제 요청 결제 성공시 해당 결제의 imp_uid 및 다른 데이터를 받음 성공한 데이터를 백엔드 서버로 mutation db에 업데이트 웹훅노티피케이션 무통장 입금 같은 웹페이지가 아닌 다른곳에서 결제가 진행될시 특정 이벤트가 발생했을 때 타 서비스나 응용 프로그램으로 알림(Notification)을 보내는 기능으로 우리의 백엔드 서버로 해당 성공 데이터를 보내줄수 있다 위와 같은 순서로 진행된다 모바일 결제시에는 페이지가 이동되어 버리기 때문에 mredirecturl이라는 결제창 종료후 돌아올 url을 입력해야 한다 하지만 해당 방법으로 이동시 결제 성공 데이터가 날아가기 때문에 웹훅노티피케이션을 이용하여 백엔드로 전달해야 한다
02 / 20 Today I Learned (TIL)
웹에디터 react-quill의 사용법과 주의할점을 배웠다 quill사용시 아무것도 입력하지 않으면 기본값으로 들어가기 때문에 해당 값으로 분기처리를 해주고 데이터를 보내자 이런 웹에디터 사용후 불러올때에는 보통 dangerouslySetInnerHTML을 사용하게 된다 그리고 크로스 사이트 스크립트 (XSS)공격의 대상이 된다 예를들면 값을 보낼떄 스크립트 태그같은걸로 코드를 작성후 패치시 해당 태그가 dangerouslySetInnerHTML을 통해 실행 되게 되면서 나의 정보가 해킹 당할수 있다 혹은 이미지의 onerror를 이용해서도 해킹을 당할수도 있다 1차적으로 react-quill은 "" 꺽쇄를 <, >로 변환해 주기도 하지만 추가적인 보안을 위해 Dompurify같은 라이브러리를 사용해주자
02 / 14 Today I Learned (TIL)
로컬스토리지를 이용하여 로그인 권한분기를 배웠다 로컬스토리지에 로그인 토큰을 저장을 시킨후에 해당 토큰을 사용하려 하면 not defind라는 에러가 발행한다 이 이유는 next.js렌더링 방식을 알아야 한다 next.js는 주소창에 주소를 입력하고 엔터를 입력시 프론트엔드 컴퓨터(yarn dev) 에서 한번 미리 해당 페이지를 그려본다그걸 프리 렌더링(pre rendering)이라고 한다 빠르게 그림만이라도 먼저 보여주기 위해 프리렌더링을 통해 만든 html파일만을 일단 브라우저로 보낸다 그 후 js파일들을 보낸다 그럼 프론트엔드 컴퓨터에서 해당 js파일은 보내주면 자바스크립트에 있는 내용을 바탕으로 처음 받은 html과 차이를 비교후 html을 다시 그린다 이러한 작업을 hydration이라고함 즉 로컬스토리지 등록 및 조회는 브라우저에 저장 및 조회하는데 프론트엔드컴퓨터에서 프리렌더링을 진행시에는 해당 데이터가 없기 때문에 오류를 발생하게
02 / 13 Today I Learned (TIL)
오늘은 로그인의 역사에 대해 배웠다! 첫번째 로그인 요청시 백엔드 컴퓨터에서 데이터를 받고, 데이터베이스에 회원가입한 유저가 맞는지 찾는다. 그 후 맞다면 로그인 여부 및 유저 정보ID를 백엔드의 메모리 세션에 저장 후 브라우저 쿠키에 정보ID를 저장한다 조회 요청시 쿠키를 함께 벡엔드로 보내 해당 ID의 로그인 여부로 데이터 조회를한다 두번쨰 첫번째 방식을 사용중 사용자가 많아짐에 따라 백엔드 컴퓨터의 메모리가 부족 하여 컴퓨터 대수를 늘리고 정보ID 및 로그인 여부를 데이터베이스에 저장하여 백엔드 컴퓨터의 부하를 분산했다 세번쨰 이렇게하니 데이터베이스에 병목현상이 생김 그래서 데이터베이스도 늘리고 데이터를 쪼개서 저장했다 그리고 데이터베이스는 DISK에 저장하기 때문에 느려서 해당 정보ID 및 로그인여부는 데이터베이스의 Redis라는 메모리에 저장 네번쨰 로그인 정보를 굳이 서버나 DB에 저장해야 할까? 라는 생각에 백컴퓨터에서 로그인
02 / 10 Today I Learned (TIL)
rest-api의 오버페칭, 언더페칭 오버페칭: 필요없는 모든 데이터를 전부 받아오는 과정 언더페칭: 여러종류의 api를 한개씩 여러번 받아오는 것 GraphQl은 사실 rest-api의 post 방식에서 data를 넣을 수 있음을 이용해 만들어낸 방식 이로인해 언더페칭과 오버페칭문제를 모두 해결 글로벌 스테이트 props-drilling(props로 하위 컴포넌트한테 전달하는 방식)을 하지 않고 전역상태관리(global state)로 바로 필요한 값을 넘기는 방식 사용 툴로는 Redux-tool-kiy + RTKQuery, ReactQuery + recoil, ApolloClient + recoil 등이 존재 하며 ApolloClient + recoil 툴을 사용하는 방법을 배웠다 위와 같이 사용하며 Atom(countState)의 변화가 있으면 해당 Atom(countState)를 참조하고 있는 모든 컴포넌트에 리렌더링이 일어난다
02 / 09 Today I Learned (TIL)
오늘은 데이터 검색에 대해 배웠다 데이터 검색의 기본적인 방식 해당 검색어를 가지고 데이터베이스의 데이터를 전체를 확인하여 찾은 데이터들을 반환 데이터가 많을시 느리고 비효율적 역인덱스 방식 특정 키워드로 전부 쪼개서 서로 일차하는 키워드가 있는 데이터들의 특정ID값을 해당 키워드에 저장한후 검색어랑 키워드를 비교하여 데이터를 반환 이러한 방식으로 데이터를 쪼개주는 도구를 Elastic Search 라고함 Disk에 저장하는 방식으로 컴퓨터가 꺼져도 저장이 유지되고 안전하다는 특징이 있지만, 비교적 속도는 조금 떨어짐 메모리 저장 방식 메모리에 저장하는 방식으로 컴퓨터를 꺼버리면 사라진다는 단점이 존재하지만 속도는 빠름 메모리저장기반 방식으로는 Redis 존재한다 Lodash의 라이브러리의 Debounce를 사용하여 검색어 입력시 input의 onChange를 특정 시간 동안 아무런 일이 일어나지 않았을때에만 동작하도록 구현 이
02 / 06 Today I Learned (TIL)
보통 우리가 이미지, 동영상등 사이즈가 큰 파일들을 저장할때에는 다른 데이터베이스에 저장을 한다 그럼 이미지용 서버를 하나 더 파던가 아니면 클라우드 서비스를 제공해주는 곳에서 저장소(storage)를 빌려서 저장해야 한다 해당 저장소에 저장하면 이미지를 다운로드 할 수 있는 주소를 주고 그 주소를 우리의 데이터베이스에 저장하는 것이다 이미지는 문자가 아닌데 어떻게 주고 받는 것일까?? 이미지를 저장시에는 이미지의 각각의 모든 픽셀의 RGB값을 저장하여 그걸 주고 받는것 (동영상도 동일) HTML에서 이미지를 저장시에는 사용하여 저장한다 해당 태그의 css를 부여하려면 2가지 방법이 존재한다 label 태그와, useRef를 이용하는 방법이다 label태그를 이용하기 위와 같이 input의 id와 label의 for,htmlFor을 일치시키면 해당 label을 클릭할시 input file이 작동되기 때문에 input을
02 / 03 Today I Learned (TIL)
오늘은 어제 데이처베이스와 연결한 백엔드서버를 24시간 계속해서 켜두기 위해 ApolloServer를 설치하여 셋팅후 간단한 CRUD API를 만들어 보았다 실무에서는 데이터를 삭제시 돌이킬수 없기 때문에 추후 상황을 대비하여 실제로 데이터를 삭제 하지는 않는다 이러한 방식을 SoftDelete라고 한다 Firebase BAAS 서비스를 사용하여 백엔드 없이 데이터를 서버에 등록시켜보았다