저는 is_host 필드와 calendar 존재 여부를 둘 다 검증해야 한다 고 판단했습니다. 왜 두 가지를 모두 사용해야 할까요? 우선 두 요소는 서로 다른 의미 를 가지고 있다고 생각합니다. is_host : 이 사용자가 호스트 자격 이 있는가? (역할) calendar 존재 : 이 호스트가 실제로 운영 중 인가? (상태) 현실로 비유하자면, is_host는 사업자등록증을 가지고 있는 상태이고, calendar가 있다는 건 실제로 가게를 오픈한 상태라고 볼 수 있습니다. 사업자등록증은 있지만 아직 가게를 열지 않은 사람도 있을 수 있잖아요? 그래서 둘 중 하나만 체크하면 문제가 생긴다고 봅니다. 만약 calendar 존재 여부만 체크한다면? calendar만 보고 판단하면 권한 체계가 무너질 수 있습니다. 예를 들어 일반 사용자가 억지로 캘린더를 생성하면 호스트로 둔갑할 수 있는 보안 문제가 생기죠. 또 호스트가 일시적으로 캘린더를 삭제했다가 다시 만들 때마다 권한 관리가 복잡해집니다. 만약 is_host만 체크한다면? 반대로 is_host만 체크하면, 캘린더가 없는데도 예약 관련 API를 호출할 수 있게 되어서 500 에러가 발생할 수 있습니다. "호스트인데 캘린더는 없는" 이상한 상태를 어떻게 처리해야 할지도 애매해지고요. 두 가지를 순차적으로 검증하는 게 좋습니다 저는 이렇게 단계적으로 확인하는 게 맞다고 봅니다: 먼저 is_host로 호스트 자격이 있는지 확인 그 다음 calendar 존재로 실제 운영 가능한지 확인 이렇게 하면 사용자에게도 명확한 피드백을 줄 수 있어요. "호스트 권한이 없습니다" vs "캘린더를 먼저 생성해주세요" 처럼 무엇을 해야 하는지 정확히 알려줄 수 있죠. 미래 확장성도 고려했습니다 나중에 서비스가 커지면 호스트 상태를 더 세분화할 수도 있을 것 같아요: 준비 중 호스트 (is_host=true, 캘린더 없음) → 대시보드 접근만 가능 운영 중 호스트 (is_host=true, 캘린더 있음) → 모든 기능 사용 가능 휴면 호스트 (is_host=true, 캘린더 비활성화) → 기존 예약 조회만 가능 이런 식으로 관리하려면 역할과 리소스를 분리해서 체크하는 게 필수라고 생각합니다. 성능 걱정은 없을까요? is_host는 User 모델의 필드라서 추가 DB 쿼리가 필요 없고, calendar 조회도 어차피 해야 하는 작업이라 성능에 큰 영향은 없다고 봅니다.
안녕하세요. 과제를 잘 못 이해한건가 싶기도 하지만 아래와 같은 조건하에 구현을 해 봤습니다. 수업 과정에서 Front-end는 고정인 상황이기 때문에 기존 API는 변경이 없다는 가정하에 변경 해 봤습니다. 시간대1개와 요일n개의 설정이 하나의 row로 묶여있는 상태로는 요일별 시간대 변동에 대응하기 까다로운 것 같아 요일별 개별 row로 저장하도록 일부 수정 하였습니다. API endpoint 모델 변경을 피하기 위해서 내부적으로 여러개의 요일별 row로 나누어 저장하도록 했습니다. 고민중에 작가님께서 올려 놓으신 레퍼런스 코드를 봤는데, 책에서 언급하신 것 처럼 postgres 경우와 sqlite 경우로 코드가 분기 되는 것을 보았고, 지금은 교육 과정이기 때문이라고 생각 하지만 배포 코드와 개발 환경 코드가 다른것은 여러모로 좋지 않은 것 같아 현재는 sqlite 기준으로 개별 DB구현에서만 지원하는 것은 배제하는 방향으로 구현 했습니다. 1과 같이 변경 함으로써, 기 등록된 정보의 수정에서는 개별 날짜 별 시간대 설정 면에서 자유도가 생겼다고 생각 됩니다. 타임슬롯의 변경과 삭제에 관해서는 내부적으로는 time-slot으로 관리하지만, 외부공개 id는 아니므로, 키 로서 start-time, end-time, weekday (API형태로서는 리스트)조합으로 정의 해서 동작 하도록 구현했습니다. 특히 삭제의 경우는 부득이 delete method의 경우는 payload가 포함되는것이 받아들여지지 않는 경우도 있는것을 고려해서, 새 등록 값 두가지(new_start_time과, new_end_time) 값이 모두 제공되고 같은 경우를 특정하여 삭제 동작으로 정의하여 동작하도록 구현했습니다. class TimeSlotUpdateByGroupIn(SQLModel): start_time: time end_time: time weekdays: Weekdays new_start_time: time | None = None new_end_time: time | None = None new_weekdays: Weekdays | None = None @model_validator(mode="after") def check_update_fields(self): update_fields = { "new_start_time": self.new_start_time, "new_end_time": self.new_end_time, "new_weekdays": self.new_weekdays, } if not any(value is not None for value in update_fields.values()): raise ValueError("최소 하나의 수정 필드는 반드시 제공되어야 합니다.") return self @router.post("/time-slots", status_code=status.HTTP_201_CREATED, response_model=TimeSlotOut) async def create_time_slot( user: CurrentUserDep, session: DbSessionDep, payload: TimeSlotCreateIn, ) -> TimeSlotOut: if not user.is_host: raise GuestPermissionError() weekdays = sorted(set(payload.weekdays)) # dup. check with already exist one stmt = select(TimeSlot).where( and_( TimeSlot.calendar_id == user.calendar.id, TimeSlot.weekday.in_(weekdays), TimeSlot.start_time < payload.end_time, TimeSlot.end_time > payload.start_time, ) ) result = await session.execute(stmt) existing_time_slot = result.scalars().first() if existing_time_slot: raise TimeSlotOverlapError() time_slots = [ TimeSlot( calendar_id=user.calendar.id, start_time=payload.start_time, end_time=payload.end_time, weekday=weekday, ) for weekday in weekdays ] session.add_all(time_slots) await session.commit() if not time_slots: raise TimeSlotOverlapError() return TimeSlotOut( start_time=time_slots[0].start_time, end_time=time_slots[0].end_time, weekdays=weekdays, created_at=time_slots[0].created_at, updated_at=time_slots[0].updated_at, ) @router.get( "/time-slots/{host_username}", status_code=status.HTTP_200_OK, response_model=list[TimeSlotOut], ) async def get_host_timeslots( host_username: str, session: DbSessionDep, ) -> list[TimeSlotOut]: stmt = ( select(User) .where(User.username == host_username) .where(User.is_host.is_(true())) ) result = await session.execute(stmt) host = result.scalar_one_or_none() if host is None or host.calendar is None: raise HostNotFoundError() stmt = select(TimeSlot).where(TimeSlot.calendar_id == host.calendar.id) result = await session.execute(stmt) time_slots = result.scalars().all() grouped: dict[tuple[time, time], TimeSlotOut] = {} for time_slot in time_slots: key = (time_slot.start_time, time_slot.end_time) if key not in grouped: grouped[key] = TimeSlotOut( start_time=time_slot.start_time, end_time=time_slot.end_time, weekdays=[time_slot.weekday], created_at=time_slot.created_at, updated_at=time_slot.updated_at, ) continue grouped[key].weekdays.append(time_slot.weekday) if time_slot.created_at < grouped[key].created_at: grouped[key].created_at = time_slot.created_at if time_slot.updated_at > grouped[key].updated_at: grouped[key].updated_at = time_slot.updated_at if not grouped: raise TimeSlotNotFoundError() for time_slot in grouped.values(): time_slot.weekdays = sorted(set(time_slot.weekdays)) return list(grouped.values()) @router.patch( "/time-slots", status_code=status.HTTP_200_OK, response_model=TimeSlotOut | None, ) async def update_time_slot( user: CurrentUserDep, session: DbSessionDep, payload: TimeSlotUpdateByGroupIn, ) -> TimeSlotOut | None: if not user.is_host: raise GuestPermissionError() current_weekdays = sorted(set(payload.weekdays)) stmt = select(TimeSlot).where( and_( TimeSlot.calendar_id == user.calendar.id, TimeSlot.start_time == payload.start_time, TimeSlot.end_time == payload.end_time, ) ) result = await session.execute(stmt) current_slots = result.scalars().all() if not current_slots: raise TimeSlotNotFoundError() existing_weekdays = sorted({slot.weekday for slot in current_slots}) if existing_weekdays != current_weekdays: raise TimeSlotNotFoundError() delete_only = ( payload.new_start_time is not None and payload.new_end_time is not None and payload.new_start_time == payload.new_end_time ) if delete_only: current_ids = [slot.id for slot in current_slots] await session.execute(delete(TimeSlot).where(TimeSlot.id.in_(current_ids))) await session.commit() return None new_start_time = payload.new_start_time or payload.start_time new_end_time = payload.new_end_time or payload.end_time new_weekdays = sorted(set(payload.new_weekdays or payload.weekdays)) if new_start_time >= new_end_time: raise HTTPException( status_code=status.HTTP_422_UNPROCESSABLE_CONTENT, detail="시작 시간은 종료 시간보다 빨라야 합니다.", ) current_ids = [slot.id for slot in current_slots] stmt = select(TimeSlot).where( and_( TimeSlot.calendar_id == user.calendar.id, TimeSlot.weekday.in_(new_weekdays), TimeSlot.start_time < new_end_time, TimeSlot.end_time > new_start_time, TimeSlot.id.not_in(current_ids), ) ) result = await session.execute(stmt) existing_time_slot = result.scalars().first() if existing_time_slot: raise TimeSlotOverlapError() await session.execute(delete(TimeSlot).where(TimeSlot.id.in_(current_ids))) new_time_slots = [ TimeSlot( calendar_id=user.calendar.id, start_time=new_start_time, end_time=new_end_time, weekday=weekday, ) for weekday in new_weekdays ] session.add_all(new_time_slots) await session.commit() return TimeSlotOut( start_time=new_start_time, end_time=new_end_time, weekdays=new_weekdays, created_at=new_time_slots[0].created_at, updated_at=new_time_slots[0].updated_at, )
- is_host를 기준으로 호스트 사용자와 게스트 사용자를 구분하는 것은, 가입 당시부터 본인의 역할을 선택하여 구분 짓는 경우에 효과적인 것으로 판단됩니다. 가입 시점부터 역할(게스트/호스트)을 구분 지어서 관리하고자 하는 경우에 적절한 구조라고 생각되며, 호스트의 자격조건이 있거나, 검증이 필요한 서비스라면 이렇게 관리하는 방법이 적절해 보입니다. - 반면, 호스트/게스트의 타입을 캘린더의 존재 여부(또는 갯수)로 정의한다고 하면, 모든 가입자가 가입시에 동일한 자격을 갖는 가입자로서 가입처리가 되고, 추가 단계로서 캘린더를 생성 함으로 써, 호스트와 게스트의 역할을 자유롭게 넘나드는 자유도가 생기는 구조가 될 것 같습니다. - 지금은 커피챗을 목적으로 일정을 조율하는 목적을 갖는 시스템이므로, is_host를 사용하지 않는 결정을 하겠습니다. 전자상거래 시스템같은 판매자와/소비자 처럼 엄격한 구분과 자격을 검증해야 하는 시스템으로 여겨지지는 않기때문입니다. is_host 필드가 없어지는 경우에, 사용자의 상태(또는 역할)을 구분하기 위해서 매번 캘린더의 존재 여부를 확인해야 하지만 앞서 언급한 호스트와 게스트의 역할 변경에 열려있는 점이 중요하게 생각되기 때문입니다. 하지만 모든 가입자가 게스트로 시작하는 만큼 커피챗 호스트를 어떻게 유치할 것인가는 고민이 되는 부분입니다.
책에서는 128p if TYPE_CHECKING: from appserver.apps.calendar.models import Calendar 이렇게 appserver 부터 시작하니다 130페이지 하단에 보면 https://gilbut.co/c/25069573YP 커밋 참조하라고 되어있는데요 깃헙에서는 if TYPE_CHECKING: from apps.calendar.models import Calendar 여기는 apps부터 시작합니다. 초보에게는 이런거 하나하나가 어렵네요 어떤게 맞는 건지 궁금합니다.
질문이 조금 많아서 죄송합니다. 다음 테스트 코드에서 commit()과 flush()의 위치가 이상해보였습니다. async def test_user_detail_for_real_user(client: TestClient, db_session: AsyncSession): user = User( username="test", password="test", email="test@example.com", display_name="test", is_host=True, ) db_session.add(user) await db_session.commit() await db_session.flush() commit()은 DB에 반영된 트랜잭션의 변경사항을 영속적으로 만들고 트랜잭션을 종료하는 코드로 이해하고 있고, flush()는 트랜잭션의 변경사항을 실제 DB에 SQL 구문을 통해 반영하는 것으로 알고 있습니다. 그래서 이 둘의 순서가 변경된 것이 아닌지 혹은 다른 의도가 있는 것인지 궁금합니다.
default_deps에서 기본 값으로 Depends 함수가 반환하는 객체가 할당되는 것까지는 이해했는데, 해당 동작이 왜 의도하지 않은 동작 인 건지가 이해되지 않습니다. 오히려 아래 쪽이 기본값이 적용되니 더 편리해 보이기만해서 Annotated를 권장하는 이유가 와닿지 않더라구여. 이에 대해서 조금 더 구체적으로 알고 싶습니다. DbSeDep = Annotated[AsyncSession, Depends(use_session)] async def annotated_deps(session: DbSeDep): pass annotated_deps() async def default_deps(session: AsyncSession = Depends(use_session)): pass default_deps()
5.4.3 Alembic 설정하기 부분에서 다음 문장이 잘 이해되지 않습니다. "우리는 그동안 appserver 디렉터리 안을 시작점(root)으로 해왔습니다. 그래서 프로젝트 내 다른 패키지에 접근하는 경로도 from appserver.apps.account 나 from appserver.apps.calendar 또는 from appserver.db import DSN 처럼 접근했었죠." appserver 디렉터리 안이 시작점이 아니고 release-your-project-with-fastapi가 시작점(루트)이 되어야 하는 것 아닌가요? fastapi-dev를 실행한 것이 appserver 디렉터리가 위치한 곳이니 루트는 현재 위치한 폴더(release-your-project-with-fastapi)이지 appserver가 아니지 않나? 라는 의문이 들었습니다.
안녕하세요 :) 좋은 강의와 책 잘 보며 열심히 따라가고 있습니다! 이번 강의 중 언급하셨던 사용자에 대한 저만의 정의를 생각해봤습니다. 시스템, 서비스 혹은 제품을 이용하게 될 주체이자, 프로젝트 진행 시 직/간접적인 경험 등을 우선적으로 고려할 대상. 라고 생각합니다. 추가 질문으로 기획 시에 발생하는 아이디어나 문서 정리, 다이어그램 등 ERD, User flow 차트처럼 (1) 기록으로 남겨야 하는 것들은 어떤 게 있으며 , (2) 어느 툴을 사용하는 게 유용할까요? 손으로 쓰는 것이 편해서 종이에 펜으로 그리면서 설계한 적이 많았습니다. 그 뒤에 Figma나 스프레드 시트로 표현했구요. 하지만, 추후 프로젝트 README.md 에 넣을 것도 고려하면 설계 혹은 기획부터 차근차근 리소스를 쌓아가는 게 어떤 가 싶어서 여쭙습니다! 무언갈 그려야 한다면 Figma를 사용하긴 하지만, 파워포인트 수준으로 밖에 활용하지 못하고 있는 것 같습니다. 전반적인 실험이나 개발 기록은 Notion(GitHub과 별개)을 활용하는 편 입니다. JIRA를 협업 및 이슈 추적에 Confluence는 Docs 관리로 써보고는 싶었지만, 현업에서 배우는 게 아닌 개인이나 4-5인 팀에서 제대로 활용하기가 어렵더군요.. (1) 설계 시 기록으로 남겨야 하는 것들은 어떤 게 있을까요? (2) 어느 툴을 사용하는 게 유용할까요? 감사합니다.
16강 '외부 연동을 다루는 방법'의 04:15에 보면, service.port 패키지로 이동한 UserRepository가 infrastructure에 있는 UserEntity에 의존하고 있는 상태입니다. 아마 후속 강의에서 UserEntity에 대한 의존도 해소될 것으로 예상되지만, 여기에서도 언급은 해주시면 더 좋을 것 같습니다.
안녕하세요 좋은 강의 잘 들었습니다~! 강의를 모두 듣고 제공해주신 프로젝트를 쭉 확인하고 궁금한 점이 생겨서 문의를 남겨봅니다 저는 실무에서 도메인 모델과 엔티티 모델을 구분하지 않고 도메인 모델에 JPA관련 어노테이션을 모두 허용한 상태로 개발해왔습니다 물론 구분해서 개발해본적도 있었지만 컬럼 변경 등 다양한 변경사항에 대응할 때마다 도메인 모델과 엔티티모델을 둘 다 확인하고 변경해야하는 번거러움?이 생겼던거 같아서 클래스가 좀 지저분해지더라도 도메인 모델 하나로 개발하고 테스트 코드를 작성해왔었습니다 이번 강의에서 사용된 프로젝트의 경우 모듈과 패키지가 나눠져있어서 도메인 모델과 엔티티 모델이 분리되어있는듯 보이지만 제가 사용했던 구조와는 다른점이 있었습니다..! 도메인 모델은 강의에서 말씀하신 개념 과 격벽 그리고 행동에 대해 적절하게 표현하기위한 객체이지만 핵심 비즈니스 로직을 모두 포함하고 있는게 아니라 대부분 조회된 데이터를 개념에 맞게 변경하는 DTO? 역할을 하는것 같고 상태변경에 대한 로직은 엔티티에 구현하고 service 레이어에서 호출하는 방식으로 보여집니다 그렇지만 처음 보는 코드가 잘 읽힐정도로 충분히 설득력있는 구조라고 생각이 듭니다.. 다만 테스트 코드가 있어야만 그 설득력이 완벽해질것 같다는 생각이 들었습니다 그래서 해당 프로젝트 구조를 더 이해하고 학습하기위해 테스트 코드를 작성해보려고 합니다 만약 저라면 ~Entity에 작성되어있는 상태변경에 대한 테스트 코드와 ~Service, ~Handler, ~Manager 등에 작성된 로직에 대한 테스크 코드를 작성할 것 같은데 강사님은 이러한 구조에서 테스트 코드를 어디까지 작성하시는지 또는 어떻게 접근하시는지 궁금합니다~!
테스트 시나리오 유효하지 않은 경우는 언제 도출하나요? 테스트 시나리오를 작성하기 전에 모든 경우의 수를 고려해서 작성해야할지 고민입니다. 제가 개발하는 도메인을 명확하게 잘 모르면 이걸 도출해내기가 쉽지도 않고 시간이 너무 소요되더라구요. 어느정도 limit 시간을 잡으시고 점진적으로 못찾은 부분을 도출하시는지 의견이 궁금합니다.
학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요! 먼저 유사한 질문이 있었는지 검색해 보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. 안녕하세요. 좋은 강의 재밌게 수강하고 있습니다! 강의를 들으면서 의식적으로 테스트 코드를 작성하기 위해 노력하고 있습니다. 학습하다 보니 테스트 코드에 대한 부분을 정량적인 지표로 활용할 수 있는 커버리지라는 지표가 있다는 것을 알게 되었는데요. 제가 개발하는 부분은 도메인이 복잡한 프로젝트는 아니다 보니, 주로 Service Layer와 Presentation Layer 위주로 작성하게 되더라구요. queryDSL이나 native query를 이용해 복잡한 쿼리를 작성하게 되면, 가끔 Persistence Layer까지 작성하게 되는 것 같습니다. 그러다 보니, 도메인 패키지가 아닌 Config 등 global 패키지에 존재하는 코드나 Persistence Layer의 테스트 코드가 커버리지가 낮고, Persistence Layer의 커버리지도 낮아서 그런지 보통 프로젝트의 라인 커버리지가 60% 전후를 기록하고 있는 것 같습니다. 우빈님께서는 커버리지를 어떤 식으로 활용하시는지 궁금합니다! 커버리지 자체를 신경쓰기 보다는 말씀해주신 대로 미래를 위해 의미가 있는 테스트 코드를 작성하고 싶은데, 커버리지도 활용하는 방법이 있는지? 그리고 주로 어떤 레이어 위주로 테스트 코드를 작성하시는지 궁금합니다! 읽어주셔서 감사합니다.
학습 관련 질문을 남겨주세요. 어떤 부분이 고민인지, 무엇이 문제인지 상세히 작성하면 더 좋아요! 먼저 유사한 질문이 있었는지 검색해 보세요. 서로 예의를 지키며 존중하는 문화를 만들어가요. BDD 설명하시면서 개발자가 아닌 사람이 봐도 이해할 수 있을 정도의 추상화 수준을 권장한다고 하셨는데요 작성한 테스트를 따로 문서화 하기도 하시는지 궁금합니다!
