A. 프론트 엔드 담당자를 정한것은 좋지만 팀원 모두가 다룰 수 있어야 합니다. 해당 팀 구조상 프론트 엔드 이해도가 분산될 필요가 있습니다. 담당자는 이해도에 비해서 프론트엔드에 너무 많은 시간이 소요되어 백엔드 학습 목적에 방해가 될 수 있습니다. 생각보다 프론트엔드 부분과 해결하는 것을 이해하기 위해서는 해당 과정을 직접 해봐야 합니다. 현재 기초 상태를 유지하고, 앞으로 추가될 기능별로 추가되는 페이지들을 분담해서 해결해보세요. 따라서 해당 프로젝트 이외에도 팀원 모두 개인적으로 도움이 될 것이며, 프로젝트 전체 퀄리티를 빠르게, 시간 내에 안정적으로 높일 수 있습니다.

A. 프론트 - 최대한 단순하게 구성하는 생각을 해야합니다. ERD -> Flow Chart -> 사용자행동, 사업자행동 처럼 이용자 흐름을 파악하고 어떤 서비스를 하는지 파악하고 핵심적인 부분만 구현해보세요.

Q. DB 설계의 오류나 잘못 이해한 부분을 살펴봐주세요. ERD참고

A. 몇가지 오류가 있습니다.

•

메뉴에 주문갯수에 대한 엔티티가 없습니다.

•

카페에 사업자회원과의 관계가 없습니다.

•

메뉴에 주문번호가 왜있는가? 오히려 관계가 반대로 되어야합니다. 

•

회원이 ROLE에 따라 나뉜것과을 재구성할 방안이 필요합니다.

◦

일반유저는 항상 사업자번호부분이  null인것이 나중에 문제가 발생 할 수 있습니다.

◦

User는 그냥 User전용 테이블로 사용하고

◦

카페테이블에 사장정보를 넣는방식으로 구분하는 것을 추천합니다.

•

TimeStamped -> 실제 쓰이는 테이블에 삽입하는것이 맞습니다. 별도로 테이블로 생성하는건 DB에서 표현되지않습니다. →모든 테이블은 관계가 있어야 한다는 점에서 생각해보면 해당 테이블은 관계가없는것이 이상하지요?

Q. 메뉴에 파일 업로드 부분이 있습니다. 어떻게 처리할까요?

A. 파일업로드에 대한것 AWS S3 를 찾아보세요.

Q. 챌린지 부분을 어떻게 우선순위를 둬야 할지, 어떤것을 할 수 있을지 실제 범위를 모르겠습니다.

A. 시간적 한계가 있습니다. 실무에서 가장 필요로하는, 신입에게 우대사항으로 나타나는 것을 진행하세요. 오히려 이런 부분은 실전에서 신입에게 우선시 되는 기본기 영역의 챌린지 과제로 보여집니다.

•

테스트코드 최우선순위로 작업. -> 신입 TDD 경험의 우대가 많습니다.

◦

TDD란 Test Driven Development의 약자로 '테스트 주도 개발'이라고 한다. 반복 테스트를 이용한 소프트웨어 방법론으로 작은 단위의 테스트 케이스를 작성하고 이를 통과하는 코드를 추가하는 단계를 반복하여 구현한다.

•

2순위 Jmeter 성능테스트 위 테스트 코드와 함께 병행되면 좋습니다. 여기까지 우선 목표를 설정해보세요.

이 정도만 해도 이번 프로젝트 기간에 부족할수도 있습니다. 범위를 이정도로 목표를 삼아보세요.

알림기능, 웹소켓, CI/CD 파이프라인은 실제로 실무에서 신입에게 쥐어질 가능성이 낮습니다. 우선순위 뒤로, 나중에 실전때 하시는것으로 목표를 바꿔보실 필요가 있습니다.

Q. 인증 방식에서 쿠키로 토큰 저장하기vs헤더에 토큰 보내기

쿠키는 저장되어야 한다는 점에서 문제가 있습니다. 헤더는 요청에 포함시켜 항상 수동으로 담아보내야되는 문제가 있습니다.

어떤 것이 좋다, 나쁘다로 단순히 결정되는 문제가 아닙니다.

쿠키 쓴다면 httponly 를 써야 기본적인 보호가 될겁니다. 하지만,

협업단계에서도 프론트에선 -> httponly 쿠키를 못읽을수있습니다. 이것에 대한 방안도 필요합니다.

두개를 동시에 사용한다던지, 프로젝트 방향에 따라 설계되어야 합니다.

Q. 리프레시 토큰에 대해서 이해도가 부족합니다. 제가 이해한 정도는 이정도입니다. 리프토큰->자주변경(갱신)될가능성->주기적비워주기가 필요하다. 디비공간에두는이유 vs 클라에넘기는이유 노출되는 상황, 커버할수있는 가능성에 따라 다르게 설계해야한다?

A. 리프레시 토큰은 보안적인 측면에서 매우 중요한 역할을 하며, Access Token의 갱신과 사용자 인증을 관리하는 데 사용됩니다. 이를 통해 보다 안전한 인증 및 권한 부여 프로세스를 구현할 수 있습니다. Access Token과의 관계: 리프레시 토큰은 Access Token과 관련이 있습니다. Access Token은 일반적으로 짧은 수명을 가지며, 서버 리소스에 대한 권한을 나타냅니다. 하지만 이러한 짧은 수명 때문에, Access Token이 만료되면 클라이언트는 다시 로그인하거나 권한 부여 프로세스를 다시 거쳐야 합니다. 리프레시 토큰은 Access Token의 만료 후, 클라이언트가 새로운 Access Token을 얻을 수 있는 도구입니다. 클라이언트는 리프레시 토큰을 사용하여 서버로 요청을 보내고, 서버는 새로운 Access Token을 발급합니다. 이를 통해 사용자가 로그인 상태를 유지하면서도 보안을 유지할 수 있습니다. 주기적 비워주기: 리프레시 토큰은 Access Token과 달리 일반적으로 긴 수명을 가집니다. 이는 리프레시 토큰이 보안적으로 중요한 정보를 포함하고 있기 때문입니다. 그러므로 리프레시 토큰은 주기적으로 비워져야 하며, 이를 통해 보안을 강화할 수 있습니다. 저장 장소: 리프레시 토큰은 일반적으로 안전한 서버 측 저장 공간에 저장됩니다. 이는 클라이언트 측 저장 공간에 저장하는 것보다 보안성이 높기 때문입니다. 또한, 리프레시 토큰은 클라이언트에 직접 노출되지 않아야 합니다. 리프레시 토큰(Refresh Token)은 일반적으로 클라이언트 측에서 저장하지 않고 서버 측에서 안전하게 관리됩니다. 이는 보안 및 안전성 이유로 권장되는 방법입니다. 클라이언트 측에서 저장하거나 직접 관리하지 않는 것이 중요합니다. 노출 상황: 리프레시 토큰은 클라이언트에서 노출되면 안 되며, 반드시 안전한 방식으로 저장 및 전달되어야 합니다. 그렇지 않으면 악의적인 공격자가 토큰을 획득하여 사용자의 계정에 대한 액세스를 얻을 수 있습니다.

Q. 리프레시 토큰 그럼 서버에서 DB에 저장하는 방법은 별도의 DB를 구성하나요? 엔티티랑 연결된 곳에 테이블을 만드나요?

A. 데이터베이스를 사용하는 경우, 엔티티와 연결된 곳에 테이블을 생성하거나 별도의 데이터베이스 스키마를 구성하는 것이 일반적인 방법입니다. 그러나 엔티티와 직접 연결되지 않아도 되며, 별도의 저장소를 구성하여 관리할 수 있습니다. 이렇게 함으로써 보안 및 관리 측면에서 더 나은 통제를 할 수 있습니다. 데이터베이스 테이블: 별도의 데이터베이스 테이블을 생성하여 리프레시 토큰을 저장하는 방법입니다. 이 테이블은 사용자 ID 또는 세션 ID와 연결하여 리프레시 토큰을 저장합니다. 각 사용자 또는 세션마다 별도의 레코드를 생성합니다.

쿠키 또는 세션: 리프레시 토큰을 서버 측에서 세션 또는 쿠키에 저장할 수 있습니다. 이 방법은 일부 웹 애플리케이션에서 사용될 수 있지만, 다른 방법보다는 덜 안전할 수 있습니다.

Redis 또는 Memcached: In-Memory 데이터베이스인 Redis 또는 Memcached를 사용하여 리프레시 토큰을 저장하는 방법입니다. 이러한 데이터베이스는 메모리에 데이터를 저장하므로 빠른 응답 시간을 제공합니다.