(최종 프로젝트 진행중)
할 일
- users.module에 위치를 인증할 수 있도록 하는 PATCH api 만들기
- users.address_certified 를 true(=1)로 바꾸는 PATCH api 작성
- ‘동네명’이 같거나, 좌표 사이 거리가 1km 이내라면 ‘동네 인증이 완료되었습니다’ 메세지와 함께 ⇒ 프로트에서 체크 후 PATCH api 호출
- 이 프론트를 어디 페이지에 붙일 것인가? 일단 ‘위치 인증하는 페이지’를 만든다. → 아니다. 그냥 js 함수만 만들어둔다. … → 으아 복잡하다. 그냥 페이지로 가서 버튼을 누르면 동작하게 하자!
- 후보1:
최초 회원가입 시 ‘위치 인증 하러 가시겠습니까?’ 모달과 함께 위치 인증 js 함수를 호출한다.
- 후보2: 아니면 상단바에 위치 미인증 유저일 시 ‘위치인증하기’ 버튼을 보이게 할까? 그럴려면 헤더에 user.address_certified가 들어가야 하는 만큼 모든 페이지가 이 변수를 담아 return 받도록 해야 하는 불편함이 있다. → 그냥 ‘위치 접근 허용을 해주시고 마이페이지 가서 위치 인증 버튼을 눌러주세요!’ 하고 소개하고 끝내야지..! ✔️
- 후보1:
- 이 프론트를 어디 페이지에 붙일 것인가? 일단 ‘위치 인증하는 페이지’를 만든다. → 아니다. 그냥 js 함수만 만들어둔다. … → 으아 복잡하다. 그냥 페이지로 가서 버튼을 누르면 동작하게 하자!
- 마이페이지에 주소 칸 하나 → 도로명, 동네명 두 개로 반영하기 + 동네 인증 여부 칸 추가
- 마이페이지 주소 api 변경하기
- 마이페이지에서 주소를 변경할 수 있게 하려면 여기에도 다음 우편검색 ui를 붙여놔야 한다.
- 주소 변경 후 ‘숮어하기’ 버튼으 ㄹ누르지 ㅇ낳았는데 ‘동네 인증하기’만 되어버릴 수 있는지 체크하기
- ‘주소변경’을 했다면 address_certified도 동시에 false로 세팅해야 한다 ⇒ 그냥 폰 번호만 바꿔도 위치 인증하라고… 일단은. → 아니다 if/else로 ‘주소변경’을 했을 때만 address_certified도 false로 세팅되도록 해 놓음!
- 현재 input 태그에 들어있는 주소와 user DB에 들어있는 주소를 비교해서 다르면 ‘바뀐 주소 정보를 저장한 후에 동네 인증하기를 눌러주세요’라고 제한해야 한다.
- 주소변경 버튼을 누를 때 ‘동네 인증을 다시 해야 합니다. 주소를 변경하시겠습니까?’ 안내문 띄우기.
⇒ 이렇게 세 개만 하면 일단 될 것 같다. 나중에 이 경우에 대해 테스트 코드도 짜 봐야지.
⇒ 이럴려고 보니까 기존의 ‘주소, 이름, 전화번호 몽땅 변경’ API를 주소 따로, 이름과 전화번호 변경 따로로 변환해야 하는 번거로움이 있다.
- 그냥 위치정보 인증할 때 항상 GET /users/mypage로 정보 불러오기를 해서 ‘현재 db에 들어있는 주소정보’와 비교하도록 해야겠다. 동네 인증이 되지 ㅇ낳았습니다라는 결과가 나왔다면, ‘주소를 변경하신 경우 수정하기 버튼을 먼저 누르고 동네인증 버튼을 눌러주세요’라고 안내창 하나 띄워주기.
- 왜 자꾸 ‘그냥 정보 변경시 ‘인증안됨’으로 바뀌지? ⇒ 해결
- 카카오 map api CDN으로 불러올 때 인증키 .env로 빼놓기.
- 회원가입 페이지에 다음 우편 찾기 api 붙여놓기
- 회원가입 dto 바꾸기.
- ‘위치 인증을 안 한 사용자’ 입장에서 쭉 한 번 돌면서 request.list/post/modify/detail 그리고 main과 message 페이지를 확인해봐야겠다.
- ‘로그인을 안 한 사용자’ 입장에서도
- 원천적으로 페이지 접근을 막는 방법?
- ‘비로그인 사용자’에게 막기: 마이페이지, 품앗이 글쓰기 페이지, 품앗이 수정 페이지, 품앗이 상세조회 페이지.
- ‘비로그인 사용자’에게 일부만 다르게 보여주기: 품앗이 목록, 메인.
- ‘로그인 & 위치 미인증 사용자’에게 막기: 품앗이 글쓰기 페이지, .
- 일단 ‘품앗이 상세 조회’페이지를 ‘비로그인’ 사용자에게 막아보자.
1안: res.redirection으로 처리하기. (alert 창을 띄울 수 없음)
2안: interceptors 이용하기. 뭔가 내가 원하는 기능은 아닌 것 같다…
3안: Guards 알아보기? (https://docs.nestjs.com/guards)
나중에:
- geolocation을 mocking 하기:
https://stackoverflow.com/questions/43008925/how-to-mock-navigator-geolocation-in-a-react-jest-test
⇒ 이 setup file 설정을 해봐야 할 듯 하다. 'TypeError: Cannot redefine property: geolocation at Function.defineProperty (<anonymous>)’ 에러 때문에.
Mocking with setupFiles
// __mocks__/setup.js
jest.mock('Geolocation', () => {
return {
getCurrentPosition: jest.fn(),
watchPosition: jest.fn(),
}
});
and then in your package.json
"jest": {
"preset": "react-native",
"setupFiles": [
"./__mocks__/setup.js"
]
}
※ 이하는 스스로 공부하며 적어둔 노트이며 불확실한 내용이 있을 수 있습니다. 학습용으로 적합하지 않음을 유념해주세요. ※
아래는 튜터님과 멘토링 시간에 들은 조언이다. 급히 받아적느라 문맥 없음 주의.
- 서비스 아키텍처를 고를 때 장단점과 사용한 타당한 이유에 대해 설명할 수 있어야 한다.
- 사용 중인 서비스 아키텍처 :
깃헙 액션즈, nest.js, typeORM, S3, HTTPS
- 더해볼 수 있을 것들:
+ Redis(Cache manager) 추가해서 서비스 아키텍처에 넣어보기.
+ Elastic search - 게시판 공통 검색 기능 알아보기
- 서비스 아키텍처는 아니지만 비즈니스 로직 차원에서:
오프셋 → 커서 기반 페이지네이션 : 시간복잡도가 훨씬 줄어든다.
- ‘서비스 아키텍처’와 ‘비즈니스 로직’은 어떻게 관련이 있는가? 뭘 서비스 아키텍처라고 부를 수 있는가?
⇒ 이곳의 글을 읽고 조금 이해가 되었다:
SW 아키텍트는 지휘자이다.SW 아키텍트를 건축을 짓는 아키텍트에 비유도 하지만, 오케스트라를 지휘하는 지휘자로 비유하기도 합니다. 얼마 전에 국내 한 방송국에서 방영된 '베토벤 바이러스' 라는 드라마는 지휘자의 역할을 아주 잘 보여주는 장면들이 많이 있었습니다. 드라마의 지휘자인 마에스트로인 강건우(이하 강마에)는 오합지졸인 실력이 형편없는 오케스트라 단원들을 대상으로 공연을 하게 됩니다. 이 드라마에서 강마에가 보여준 지휘자의 모습이 바로 SW 아키텍트가 보여주어야 할 모습과 흡사합니다. 우선은 지휘자로써 강마에는 최고의 실력을 갖추었습니다. 물론, 그가 최고의 실력을 갖추는 개인적인 노력은 드라마를 통해서 보여지며, 그 또한 최고의 실력가로 지휘를 하게 됩니다. 하지만, 최고의 실력을 갖추었다고 해서 곧 바로 악단을 훌륭하게..https://homo-ware.tistory.com/140
내가 알고 있는 3계층 아키텍처도 SW 아키텍처이다.
지휘자에 따라서 동일한 음악이라 하더라도 연주가 달라지듯이 SW 아키텍트에 따라서 동일한 도메인에 대한 SW 아키텍처는 아키텍트가 가지고 있는 사상과 생각을 반영하여 독특한 색깔을 나타낼 수 있어야 합니다. 3계층 아키텍처이지만, 논리적으로 3계층에 위치하는 레이어가 아키텍트마다 달라질 수 있으며, 동일한 MVC 패턴이라 하더라도 컨트롤러에서 구현하는 비즈니스 로직의 기준이 달라질 수 있습니다.
- 3계층 아키텍처와 MVC 패턴이 뭐가 다른가?
- Presentation layer = VIEW
- Business layer = CONTROLLER
- Data Access layer = MODEL
이렇게 보는 사람도 있고 VIEW와 CONTROLLER가 모두 Presentation 계층에 속한다고 보는 시각도 있다. 혹은 그 둘이 완전히 다른 개념이라고 설파하는 글도 있다. 사실 MVC 패턴은 아무리 자료를 읽어봐도 모바일에서 주로 사용되는 개념인 것 같다는 점 외에는 아직은 모르겠다.
(참고: https://daryeou.tistory.com/310)
(참고: https://blog.devgenius.io/three-tier-architecture-vs-mvc-architecture-1ed0d195e427)
Uploaded by N2T