JIN_CODER

페이지 네이션이란 책 페이지처럼 데이터를 묶음으로 분리하는 과정이다. 모든 데이터를 한 번에 가져오는 게 아니라 필요한 개수를 지정하고 특정한 정렬 기준에 따라 상황에 맞춰 조건을 맞춰서 데이터를 분할해서 가져오는 것이다. 대표적인 방법 오프셋 기반 페이지 네이션 : DB의 offset 쿼리를 사용하여 '페이지' 단위로 구분하여 요청/응답하게 구현 커서 기반 페이지 네이션 : 클라이언트가 가져간 마지막 row의 순서상 다음 row들을 n개 요청/응답하게 구현 오프셋 기반 페이지 네이션 가장 일반적인 방법(난이도가 쉽고, 편리한 방법) 데이터를 가져올 때 LIMIT을 사용해서 필요한 만큼만 가져오고 다음에는 offset을 사용해서 가져온 만큼을 건너뛰고 필요한 만큼씩 가져오는 방법 ex) 100개의 데이터..

이번 주는 미니 프로젝트의 마무리와 클론 코딩을 시작했다. 협업을 제대로 진행 한 첫 주여서 많이 걱정했다. 미니 프로젝트 때의 팀원들은 너무 소통이 잘돼서 정말 서로 응원해주고 의견 공유가 잘돼서 계속 배려해주는 모습들이 좋았다. 덕분에 분위기는 너무 좋았고, 주제를 정해서 프로젝트를 진행하면서도 백앤드에서는 지금까지 주특기 주차 때 해왔던 기능들을 기반으로 했기 때문에 큰 문제도 없어서 정말 빨리 끝났다. 그 후엔 아무래도 프론트 불들이 서버의 운영이 어떻게 되는지 잘 알지 못하셔서 프론트 분들과 같이 응답은 어떻게 보내주는지 요청은 어떤 식으로 하면 되는지에 대해서 많이 얘기했다. 그래서 그런지 빠르게 API 통신이 이루어져 빠르게 연결이 되었다. 그렇게 미니 프로젝트가 순조롭게 진행되어서 혼자 서..

클론 코딩 2일 차 미니 프로젝트와 기능이 별 다를 게 없어서 그런지 어제 바로 모델을 생성하고, 절반 정도 기능 구현을 했다. 오늘은 수정 및 삭제, 그리고 좋아요 등록 기능을 만들었다. 전체 게시글 안에 좋아요 표시와 댓글 평점의 평균값을 넣어 보내드리려고 했지만 이 부분이 생각처럼 잘되진 않았다. 각 게시글 안에 불리언 타입으로 주지는 못하고, 해당 사용자가 좋아요 누른 게시글의 키값을 따로 배열로 만들어 줄 수 있었다. 하루 종일 댓글의 평균값을 구하려고 했는데 결국 못했다. 콜백 지옥에 다시 한번 빠졌다. 그땐 2중이었는데 이번에 3중이라 어렵다.. 결국 마지노선으로 각 게시물의 달린 댓글의 값을 모두 가져올 수는 있었는데 거기서 가각 다 더해서 총합으로 나누지는 못하였다.. 프론트 분들 죄송해..

1. express를 이용해 서버를 배포하고, 인스턴스 환경에 접속한다. 2. 포트 포워딩(80 => 3000) sudo iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 -j REDIRECT --to-port 3000 3. pm2 설치 npm install -g pm2 4. 인증서 설치 준비 app.js가 설치된 디렉터리로 이동(같은 위치) // 인증서 설치 sudo apt-get install letsencrypt 4.2 인증서를 받을 폴더 생성 // 폴더 생성 mkdir public mkdir -p .well-known/acme-challenge 5. app.js 수정 // 코드 추가 app.use(express.static('public')); 6..

클론 코딩이 시작되었다. 미니 프로젝트로 협업을 처음 시작해서 1주일이 진짜 빨리 지나갔는데 또다시 협업을 통해서 만드는 거라니.. ㅋ 어렵다 어려워 팀원들과 또다시 친해져야 하고, 주제도 정해야 하고 하... 아침에 일어나서 출석부를 보니 모두 새로운 사람들과 만나게 되었다. 어떻게 또 친해지지.. 그중 한 분은 미니 프로젝트 때 자기주장이 조금 강하셔서 얘기가 나오던 사람이었다. 아.. 이분과는 어떻게 진행이 될까 했다. 발제가 끝나고 팀원들이 전부 모여서 간단한 소개를 하고, 잠시 주제를 찾아보고 다시 모여서 무엇을 클론 코딩할지 얘기를 했다. 그중 나온 게 홍루이젠의 홈페이지(프랜차이즈 가게 소개), 링크드(OTT 구독 파티 구하는 사이트), 에어비앤비(숙소 예약) 이 나오고 어떤 걸 정해야 적당..

프로젝트를 하면서 인스턴스에 접속을 할 수 없는 에러를 만났다. 배포 직전에 https를 구현하기 위해 이것저것 자료를 찾아보고 적용하면서 여러 패키지들을 설치하는 과정에서 설정을 건드린 것이 문제인 것 같은데 아직까지도 왜 인스턴스에 접속할 수 없었는지에 대한 이유는 찾지 못했다. 우분투 환경에 yum을 설치하고, 설정을 수정하고, git을 설치하고 정신 차려보니 터미널에서 ssh로 연결하는 과정에서 이러한 에러와 마주쳤다.(예시 이미지임) 내 인스턴스 환경에 연결이 거절되었다? 포트가 문제인가 보안규칙도 보고 했지만, 원인을 몰랐다. 뭐가 문제지.. 하면서 오류를 검색해도 원인을 찾지 못해서 인스턴스 중지(일시정지)를 했다가 다시 시작해서 연결을 시도했다. 그러고 나니 이제는 이런 에러로 바뀌었다. ..

으... 미니 프로젝트가 끝났다... 정말 항해 시작하고 가장 빨리 지나간 주였다. 너무 바쁘고, 생각할게 많아서? 백앤드인 나는 주특기 숙달 느낌이 많이 들었지만, 그래도 해야 할 일은 많았고, 처음 써보는 기능들도 구현하다 보니 시간은 정말 빨리 지나갔다. 그리고 프로트 분들이 많이 힘드셨을 것 같다. 처음 써보는 기술들과 실력적으로도 많이 뛰어난 편은 아니셔서 고생이 많으셨다. 약간 구글링을 하면서 이게 왜 되지?라는 느낌보다는 하나하나 다 찍어보면서 되나 안 되나? 식으로 하셔서 오래 걸렸던 것 같다. 하지만, 열정만큼은 정말 너무 뛰어나셨다. 성격도 너무 좋으신 분들 이어서 나도 의지가 많이 되었고, 자극도 많이 되었다. 오늘은 마지막 프로젝트 제출을 하기 때문에 뷰를 완성하고, 머지해서 서버에..

프론트와 협업을 하면서 백앤드는 익스프레스로 http 환경의 서버를 띄우고 프론트는 버셀?이라는 것을 사용해서 서버를 띄우면 https의 환경이 만들어진다. 하지만, 두 서버가 api 통신을 할 경우 http 환경이 달라서 통신을 할 수가 없다. 그렇기 때문에 프론트에서 S3로 http환경을 구축하여 통신하거나 서버에서 https 환경을 만들어 통신해야 한다. 백앤드가 배포를 중점으로 하진 않지만, 그래도 프론트보다 배포에 조금 더 관여를 하고 있기 때문에 서버에서 https 환경을 구축하는 게 맞다고 생각한다. 또한 http와 https의 보안 차이도 크기 때문에 보안을 강화해서 통신을 하는 것이 좋을 것 같다. http란 기본적으로 클라이언트와 서버 사이에서 데이터를 주고받는 통신 프로토콜이다. 주고..

오늘은 디비에 비밀번호를 저장할 때 사용하는 암호화 작업을 공부하고 적용시켜봤다. 아무래도 비밀번호 같은 매우 중요한 정보들은 그대로 저장하면 안 된다. 관리자도 그 정보를 직접적으로 보아서는 안되고, 혹여나 DB서버가 해커에게 탈취를 당하더라도 암호화를 시켜 2차 피해를 막을 수 있다. 그렇기 때문에 중요한 정보들은 암호화를 통해 항상 저장해야 한다고 익히 들었는데 항상 시간이 부족해서 제대로 공부할 시간이 없어 적용 못했는데 이번에 개인 공부시간이 조금 생겨 bcrypt를 통해서 암호화를 적용시켰다. node에서 기본적으로 제공하는 모듈이 있지만, bcrypt가 보안성도 더 높고, 사용도 쉬워서 이 모듈을 설치하여 적용해서 비밀번호를 저장했다. 이렇게 저장한 암호는 단방향 해쉬 함수로 암호화했기 때문..

백앤드 서버 개발자라면 중요한 정보(비밀번호 등)를 DB에 저장할 때 입력받은 값 그대로 저장해서는 안된다. 만약 db서버가 탈취당하게 된다면, 사용자들의 정보나 중요한 내용들이 해커 손에 들어가기 때문이다. 서버의 보안이 뚫리지 않는 것이 가장 이상적인 상황이지만, 보안은 언제든 뚫릴 수 있고, 항상 강화를 해야 한다. 이때 비밀번호를 암호화하여 저장을 했다면, 탈취당하더라도, 사용자들의 정보를 조금이라도 지킬 수 있기 때문에 보험처럼 항상 암호화를 실시하여 저장을 해주어야 한다. 또한, 관리자가 사용자의 개인정보를 저장을 하지만, 비밀번호 같은 더 중요한 내용을 그대로 보거나, 저장하면 안 되기 때문에, 암화화를 하는 이유도 있다. 단방향 / 양방향 암호화 - 단방향 암호화 암호화는 할 수 있어도, ..