전체 글 654

Project 3: sprint 1주차-2일 차 - MVP 선정: 1차

프 - 백 함께 1차, 2차 목표를 선정함 1주차엔 기획 + 개발 2주차 중간까지 1차 MVP, 3주차 중간까지 2 차 MVP, [페이지] 1. 메인 페이지 2. 목록 리스트 3. 상세 페이지 4. (추가) 검색 5. 마이페이지 - user 6. 장바구니 7. 주문/결제 8. 회원가입 9. 로그인 10. 판매자 마이페이지 - admin (필수) 1차 MVP(필수: 1차 목표) / (선택) 2차 MVP 0. (필수) AWS 1. (필수) 메인 페이지 : (필수) 제품 목록 불러오는 것 / (선택)위치 기반 + 제품 목록 불러오는 것 2. (필수) 목록 리스트 - 필터링, 페이지네이션, 정렬 3. 상세 페이지 4. (추가) 검색 5. 마이페이지 - user 6. 장바구니 7. 주문/결제 8. (필수) 회원가..

카테고리 없음 2023.10.10

Project 3: sprint 1주- 2일 차: 프- 백 ERD modeling

메인 페이지 > 상단 header (고정) / GNB (+ 판매자 전환 페이지) 영역 이름 : header GNB: 옆으로 할 수 있고, 상단에 할 수도 있고 > big banner : 3개*1줄 / 프리미엄 vip 광고 (market_id 로 데이터 받고, 클릭 시, market_list 페이지 연결) > band: title + 더보기 버튼 + 판매자 전환 버튼 (이중장치) / 5개*8줄 or 5*10줄 - 밴드: 한 밴드에 이미지 5개씩, 옆으로 3번 넘긴다 (약? 총 15개) -> 백엔드가 준 전체 목록 데이터로 프론트가 알아서 잘라서 넣는 거 (밴드 카테고리 title : 마켓 카테고리, 상품 카테고리 // data table는 백엔드가 정해서 주면 됨) 프로모션 : rating 으로 하면 됨 ..

Project 3: sprint 1주-1일차- erd modeling - 관계도

테이블과 키 값은 완료 후, 화살표를 이제 seller - user 1:1 seller - product 1:다 (1명의 셀러가 여러 상품 가능) product - product category 카테고리 하나에 여러 product 들어갈 수 cart - product 1:다 --> 한줄 한줄을 cart로 보는 것 --> (1:1로 하려면, product_cart로 테이블 또 들어가야 함) cart - user 1:다 -> 한 유저가 여러개의 cart 가진다 유저- 구독 1:1 유저 - 리뷰 1:다 (한 유저가 여러 개의 리뷰) likes 0> like 있고 없고 order = 주문 내역서 order detail = 주문 안에 있는 여러 상품들 product 테이블이 다 sellers가 일 seller_i..

post update, delete **

delete app.delete("/deletepost" , async (req, res) => { try{ const token = req.headers.authorization; if(!token){ const error = new Error ("TOKEN_ERROR 게시물 삭제 권한이 없습니다"); error.statusCode = 400; error.code = "TOKEN_ERROR" throw error; } const {id} = jwt.verify(token, process.env.TYPEORM_JWT); const postId = req.params const existingUser = await myDataSource.query(` SELECT id, email, password FRO..

Project 3: sprint 1주- 2일차- standing meeting 및 erd modeling

기능 구현 먼저, api문서 통신 위주 3주안에 못해도 우선순위 바로 erd 회의 https://dbdiagram.io/d/2team-6524aa73ffbf5169f05b838c dbdiagram.io - Database Relationship Diagrams Design Tool dbdiagram.io Erd 테이블은 데이터 기반으로 -> 마이페이지: 위치는 현 위치로 하기로 구독 날짜를 알아야 하니까 user 구독, 셀러 구독 테이블을 따로 빼야함 주문 테이블- >결제 이후에 들어가는 주문내역 결제 테이블 ->버튼 누르면 결제되었다 알람/ 외부 결제 모듈(추가사항) (수령하면, 셀러에게 돈 주는 거는 빼기 간단하게. ) 검색, 필터링 -> 조건문 select like, select where 할인가 ..

Project3: sprint 1주-1일차 - user flow

프+ 백 모여서 user flow를 그림 [구매자 프로세스] 메인페이지를 로그인 페이지로 하는 -> 인덱스 첫 페이지는 로그인 페이지로. 로그인하고 나서, 메인 페이지로 가는 거로. 백 - 프 통일 [회원가입] 유저 입장에서 이메일 vs 아이디 어떤 거로 가입하는 게 좋은지? -> 이메일 로 - 이메일 중복 검사 - 휴대폰 중복 검사 - 패스워드 조건 검사 - (선택) 아이디 자동 저장 기능 [로그인] - 아이디, 비밀번호 유효성 검사/ 중복확인 백: 데이터베이스 검증 까지 하고 프: @, 특수문자 검증 alert 띄우는 거 [메인 페이지] 자기 속한 지역에 해당하는 광고, 배너 불러오기로 - 광고 배너 - 카테고리별 슬라이딩 되는 밴드로 (프론트가 ui가 편해짐- 공수형으로 하면, 배너 하나를 하면 T..

Project 3: sprint 1주-1일차 - PET 분석

회원 ) 어떠한 고객이 우리 서비스의 회원층이 될 수 있을까? 어떤 상품 판매하느냐에 따라 다른데, 일단은, 내가 만든 사람을 쉽게 판매하고 싶은 사람, 집 근처에서 구매하고 싶은 사람 거점 등록으로 본인 영업장/ 가게를 홍보하고 싶은 사람 지역경제에 사람 많은 사람 방문자, 주소지가 반경 5km 이내인 사람. 현재로 하면 지역경제랑 의미가 멀어지니, 거주지로 하기로 회원가입 시 주소지로 하고, 쿠팡/ 배민처럼 회원가입 시 주소지, 현재 위치 주소로 따로 ex. 금융적인 지식이 부족한 국민 / 미래 가족 금융에 고민이 있는 사람/ 공동으로 자산 관리를 하고싶은 사람/ 자녀의 용돈을 관리하고 싶은 분 2. 보다 많은 고객들을 어떻게 더 유입시킬 수 있을까? 판매자 입장에선 다른 곳에 유통하는거보단 비싸야하..

Project3: sprint 1주 -1일차- Business Modeling

Product 분석 대규모 이커머스 지역경제 상권 둔화 마켓컬리 비슷한 느낌 근데 "우리 지역" 반경 5km안에서만 가능하게 - 지역 특산품이 아닌데, 지역 경제 활성화 근데 지역별로 유명한 상품이 있는 곳인데, 꼭 내 지역 반경 안에서만 사야 하는게 근데 기대효과에 -> 지역 커뮤니티 강화 사용자 판매자에게 도움이 돼야 하는데 어떤 비즈니스적 이익이 있을까? 크몽 + 당근마켓 "제품 및 서비스"니까 네일아트. 공방, 5km 당근마켓과의 차별점? 1. - 네일아트 1회권 - 수강권 - 헬스클럽 양도 (지역경제) -> 동네 사람만 가능하니 - 셀러이자 유저일 수 셀러에게도 유저 어드민 주고 유저에 1대 다 관계로 (한 아이디에 여러 계정 가능한 -> 넷플릭스 1대에 4계정 있는거처럼) 2. 중고 양도 제외..

Project 3: 정한 시나리오로 혼자 해보는 기능 분석

나중에 백엔드 기획에서 메인페이지엔 뭐가 있을 거고, 주문/ 결제 페이지엔 뭐가 있을건지 생각해야 함 사용자 user - 사용자 회원가입 - 사용자 정보 수정, 변경, 삭제 ( 이름, 연락처, 지역 필수값) 판매자 product - 제품/서비스 등록, 수정 create, upate (post) - product option: 카테고리, 색상, 설명, 가격, 재고quantity, 사진 image 입력 위치 기반 서비스 - 구글 맵 api -> 현재 위치 식별, '판매자와 제품/서비스'의 위치 매핑 - 사용자 : 특정 지역 내에서만 거래 가능하도록 error handling --> 공식문서 참고 searching 검색 --> 메인 페이지? - 사용자: 지도- 주변 '판매자와 제품/서비스' 검색 - 필터링, ..

Project 3: sprint 1-1일차 - planning meeting

1. 백엔드 프론트 미리 일정 조율을 위해 하기로 했다. - api 문서 전달를 빠르게 전달 - 소스 코드 freezing 기간 (계속 변경) 현업에서는 첫 주 백엔드가 달리고, 두번째 주 프론트가 달리는 그림이다. -> 1주: 첫 백엔드가 달리는 동안 프론트가 노는 게 아니고, 먼저 디자인 (색깔, 규격)을 한다. 데이터는 뭐가 들어올지 모르더라도 -> 2주: 프론트가 백엔드 / 로직을 짜기 시작함. 그래서 백엔드가 기획 통해 함수명, api 정해서 문서로 빨리 주기로 했다. 2. 나중에 백엔드 기획에서 메인페이지엔 뭐가 있을 거고, 주문/ 결제 페이지엔 뭐가 있을건지 생각해야 함 Project 3: 정한 시나리오로 혼자 해보는 기능 분석 나중에 백엔드 기획에서 메인페이지엔 뭐가 있을 거고, 주문/ 결..