# 최종 발표

## Q&A

**A팀 질문 확인하기!!!**
1. **graphql을 선택한 이유**
- (소희) subscrition 작업 타입을 제공해주기 때문에 따로 pubsub을 구현하지 않고, 실시간 서비스를 구현하는데 편리하게 사용할 수 있었다. 원하는 필드를 요청에 포함하면 해당 필드만 응답으로 와서 간편했다.
- (수원) 덧붙이자면, 소희님이 말씀해주신 점 덕분에 요청마다 response를 가공하는 작업이 줄었다는 점도 체감할 수 있는 장점중의 하나였습니다.

2. **동기화 = 동시성 문제를 어떻게 해결했는지**
- 일단 요청을 수락하면 상태를 한 번 확인하는 전처리가 포함되어있습니다. 하지만 이것으로 동시성 문제를 완벽하게 커버할 수는 없을 것이라고, redis를 사용해서 해결할 수 있었지만 이 프로젝트에서 오버스펙이었고, 우선순위에 밀리는 이슈였기 때문에 고려하지 않았다.
- (소희) 상태를 한번 확인하는 전처리를 구체적으로 설명 드리자면,요청을 수락했을 때, 해당 요청을 삭제하는데 이때 삭제할 내역이 없다면 이미 수락된 요청이라고 판단한다

3. 기사가 실시간으로 움직여서 뭔가 까다로울 것 같은데 매칭을 어떻게 구현하셨나요?
- 10초에 한번 요청을 보냅니다.
- (수원) 만약 1분동안 단 한번만 요청을 보내고 대기한다고 가정했을때, 사용경험적으로 아쉬운점이 몇가지 있었다
- 반경 모든 드라이버가 거절하면 유저는 마냥 1분을 기다려야 하거나,
- 1분이 지나지 않았더라도, 모든 드라이버가 거절 했을 때 바로 요청 취소가 되도록 처리하게되면
- 1분 사이에 반경 내로 진입하는 택시에게는 요청이 가지 않는다라는 점 때문에
- 10초에 한번 요청을 보내서 1분 안에 반경 내로 진입하거나, 업무를 시작한 택시에게도 요청이 가도록 했다.

4. 업무 분배는 무슨 기준으로 했나?
- 매주 스프린트 회의 때 백로그를 펼쳐놓고 우선순위가 높은 기능을 우선 이슈로 정리 해서,그 중에 본인이 하고 싶은 업무가 있으면 선점하고, 업무 비율을 맞춰 균등 분배했습니다. 백엔드 / 프론트엔드 담당을 따로 정하지는 않았음

5. 프로젝트 진행하면서 가장 어려웠거나, 오래걸렸던 기능은?
- (고민 많이 했던 질문이니까, 대답 적당히 잘 해주시면 됩니다!) 매칭논의 관련

1. GraphQL을 사용하면서 느낀점
2. GraphQL을 배우면서 다른 어려운 점은 없었2나요?
3. Apollo의 캐시는 어느부분에서 사용하셨나요?
- 사용안하셨다면 Apollo를 적용한 이유가 있나요?
4. 디렉티브 문법이 갖는 장점은 뭐가있나요?
5. 드라이버 화면에서 지도가 표시되지 않는 이유가 있나요?
6. 프론트엔드 구조 설명좀 해주세요
8. 2초마다 위치를 update 하면 사용자(기사)가 많아지면 부하가 커지지 않나요?

## 데모 시나리오
1. 여러 유저가 보내는 매칭을 한 드라이버가 받을때
- 2유저 1드라이버
- (요청 한번 거절, 다음 요청 받기?)
2. 1분 뒤 유저가 기사를 찾지 못할 때
- 1.에서 거절당한 유저가 1분 지나면 어떻게 되는지 이어서 보여주세요
3. 요청을 보냈는데 출발지 2km 반경으로 뒤늦게 들어온 드라이버
4. 히스토리, 로그아웃

:두꺼운_확인_표시:팀별 Q&A 줌 링크: https://zoom.us/j/95656545608?pwd=SFZ0Vlk0UDQydkYyMFBCbzBpcUhBdz09
:두꺼운_확인_표시:노션 소개페이지 링크: https://www.notion.so/09-B-9e48ac42754c4515b66dfa10b749eb22
:heavy_check_mark:GitHub 링크: https://github.com/boostcamp-2020/Project09-B-Uber-Clone
:두꺼운_확인_표시:GitHub Wiki 링크: https://github.com/boostcamp-2020/Project09-B-Uber-Clone/wiki
:두꺼운_확인_표시:시연 영상 링크: https://youtu.be/q61XLqrnyTI
:heavy_check_mark:배포 링크: https://hoyoung.me