회고록

사실 1일차가 아니긴하다.. 벌써한 5일차쯤 되는거같다. 물론 1,2차 회의때 정해진내용도 은근히 있었다. 그덕에 타입스크립트를 공부하자던가여러 의견이 오고갔고,mysql+mongodb의 데이터베이스를 다루며express.js 기반의 서버를 운영한다.react.js와

기본은 기능별로 마일스톤(이정표)를 만들고, 거기에 세분화된 기능을 이슈로 만들어서하나씩 처리하는것이다.직관적이고, 많은양의 업무도 소분해서 하다보니 부담이 적고, 정신적 스트레스가 거의 없는거같다. 얼만큼 진행했지가 엄청 눈에 보이고진행도도 이후 깃 프로젝트로 칸반보

패스워드 리스가 뭐지 ?이른바 비밀번호없는 로그인방식을 말하는데요즘 트렌드가 점점 올라가고있다.대표적으로는 AuthO 라는 플랫폼에서 제공하는 서비스만 끌어다써도OAuth연결, passwordless인증이 다 해결되는것으로 알고있다.허나. 이번 프로젝트에서는 노드메일러

제일먼저 메일인증으로 passwordless를 꼭 하려고했다.무엇보다 내가사용해서 제일 편했던 서비스이다.그러므로 토큰이용이 높았고서버에 부담이 좀 커지긴한거같다.elb가 어떻게 처리해줄지는 아직 잘모르겠지만.확실한건 아직 서버가 무겁다, 그리고 typescript여서

오늘은 1\. 칸반보드 get,post요청 처리에따른 db저장 로직을 작성했다.문제점은 map을 쓰려고보니 typescript에서 조금 조건적인게 보여서일단 for문을 썻는데, 무조건 map,reduce,filter가 정답일까 라는생각이 들긴했다.사실 알고리즘 문제풀때

몽구스를 이용해서 체크리스트 부분만 뜯어내서JSON.stringify 해서몽고디비에 넣고 , 빼고를 할수있다.그래서칸반보드의 데이터를 get요청하고나 post요청하면불러오고,삭제하고를 할수있다.우리는 데이터를 한번에 그리고, 한번에 저장하므로업데이트라고 불리울만한 메서

mongoose를 이용해서 시퀄라이저를 이용한 board테이블을 각각 조회해오면서 ,댓글의 데이터를 mongoose에 요청해서 받아온다.재귀적인 로직은 전에 giftBox라는 문제를 풀적에 썻던로직을 비슷하게 사용했고mongoose에서 &&과 같은 연산자옵션을 주고싶엇

진짜https 찾아본다고 엄청 고생했다..nginx greenlock?cert-bot그리고뭐let's encrypt 이거sslelb 등등.. 하 진짜 엄청 뭔가 찾아봣는데다 실패좌절하던중그나마 삽질하면서aws 서비스 자체와 좀 친해진감이있다.이래놓고 갑자기 지불해야한다

쿠키때문에 한참을 고생했다.결론이 나왔다.http에서는 cors로 쿠키를 날릴수없다.https에서 다시테스트할것.이제중간에 에러 하나 해결하는데와mysql에서id하나 잘못 연결했다가 죽을뻔했다.일단tasks의 테이블에 checkList가 null이 되긴하지만.get요청

sequelize-typescript 라는게 있엇다.마찬가지로 ES7의 decorator에 대한 지식을 요구했다.당시 2주의 시간밖에없던 나는일단 덜컥 겁이나서 sequelize+typescript를 강제시해서 사용했다.덕분에 마이그레이션하는데 시간도많이쏟았고 (자체

M:N 관계를 구성해놓은게 있는데TypeORM으로문제는joinTable 기능을 사용해서테이블이 하나가 생겨난다.나는 이게 직관적이라서좋다고생각했고이름을 join 으로했다. (이게 컬럼명일줄 몰랐다..)테이블이름이stacks_join_recruits 이렇게 나오니 보기좋

사용하다보니까Stack이라는친구를 우리는 FK로 여러테이블에서 인용하고있다.근데 stack이라는친구를하드코딩으로 하나하나 추가하자니 은근히 중복된 데이터도많고어디서부터 어디까지 넣어야할지도모르겟고front,back만 나누자니database , devOps같은것도 따로

개발단계에서더미데이터의 중요성을 은근히 느꼇다.막연한 값을 막 때려박자니나중에 프론트에서 꺼내서 쓸때, 모양새도 안나오고, 직관적이지않다.또한stringify해서 넣는 경우데이터형식을 오인할 가능성이있으므로항상 의미있는 값으로 넣어줘야겠다라는 생각이들었는데개발자,테스터

2주차때 겪은 https, cookie 이슈를 다시 도전백엔드형님깨 얻은 조언으로 서버라는것에 대해서 다시 생각해보게됬고,서버의구조 아키텍처구성 등등 남에게 설명할때 구체적인 구조가없으니충고를구하기도 힘들었다는게 느껴졌다.내가아는 내용을 남에게 조리있게 설명하지못했다.

socket.io에대해서 이해했다. 많은부분을 이해한거같지만. 인프라 범위에서의 소켓통신을 이해하기 어려웠다.socket.io 의 기본적인 지식이 어려원다redis를 왜쓰는가 ? pub/sub이 좋다, 데이터 안정성이 조금 떨어질수도있다. 그래서 언제 데이터가 날라도

Mysql -> MongoDB : TypeORM -> Mongoose: AWS RDS -> MongoDB Atlas소켓통신 그리고 스케쥴러의 적절한 조합이 필요할수 있다.이미지 저장방식 개선서버에 저장하는 비효율적인 방법 개선 -> S3스토리지 사용 권장 : S3 SD