“/assests/images/“ + itemId +”.png” 이렇게 이미지경로를 얻을 수가 있는데
백에서 처리한 다음에 ItemDto에 imagePath 이런식으로 포함시키는 거랑, 프론트에 함수 정의해서 쓰는 것 중에 어떤게 바람직한 방법이야? 이런걸 판단하는 기준이 있어?
- dc official App
댓글 16
단건이면 이미지링크 클라이언트에서 땡겨쓰고
다건이이면 zip파일 내려줄 수도 있으니 서버에서 처리해야 할 수도 있는데
파일이나 이미지 송수신 API 인터페이스 정의를 한다고 했을때 서버가 자연스러운듯 - dc App
꼴댕이(dwell3443)2025-01-21 21:53
답글
아 파일 송수신 하려는건 아니고 웹페이지에 상품 이미지 보이게 하는 상황인데, 그래도 판단 기준은 같을까? - dc App
익명(116.126)2025-01-21 21:59
답글
짧은 식견이지만 현 상황에서 이미지처리를 클라이언트에서 하되 dto에 path는 넘겨두는게 좋을것같아요 확장성을 염두해 둬야하니까요
단건이라도 초고화질이라던가 하는 이유로 성능문제가 있다고 하면 이미지처리도 해야하고 등등.. - dc App
꼴댕이(dwell3443)2025-01-21 22:05
이해를 못했는데 다시 설명가능함?? - dc App
익명(58.141)2025-01-21 22:38
답글
네이버 쇼핑처럼 상품 이미지 주루룩 뜨는걸 구현하고 싶음. 상품 이미지 경로는 상품id에다가 간단한 처리를 하는 방식으로 얻을 수 있음. 그럼 이때 상품id에서 이미지 경로를 얻는 처리를 프론트에서 할지 백엔드에서 할지가 고민이야 - dc App
익명(116.126)2025-01-21 22:48
답글
상품 객체에 이미지 경로가 따로 있는게 아닌거야? - dc App
익명(58.141)2025-01-21 23:48
GET /item/{itemId}/image 하나 뚫는건?
익명(59.27)2025-01-21 22:53
해당 댓글은 삭제되었습니다.
해당 댓글은 삭제되었습니다.2026-08-04 18:55
답글
맞음!! json에 id, imagePath 다 포함시키는게 일반적인가 보넹 - dc App
익명(116.126)2025-01-21 23:28
전에 다니던 회사는 경로를 다 백엔드에서 json으로 감싸서 넘겨줬음. 근데 님 말처럼 프론트에서 아이디만 가지고 구현하는 것도 가능은 할 거 같은데. 굳이 이걸 프론트에서 할 이유가 있나 싶은뎅
한물(183.102)2025-01-21 23:29
딱히 정해진건 없음
간단한 사이트 같은 경우에는 itemId 만으로 특정 이미지를 찾을 수 있겠지만, 복잡해지면 백엔드에서 미리 객체에 이미지 경로까지 넣어보내줘야되
그냥 님 편한대로 하는거고, 상황에 따라 선택하는거임
익명(118.176)2025-01-21 23:34
답글
예를 들어 지금은 사과에 id: 1을 부여하고, 바나나에 id: 2를 부여해서 프론트에서 그냥 /assets/images/1.png를 요청할수도 있겠지만, 사과가 매진된 상황에서 다른 이미지를 보여주고 싶다면 /assets/images/1-soldout.png 이런식, 혹은 /assets/images/soldout/1.png 이런식으로 요청해야될수도 있음
이러한 상황에서 매진, 베스트셀러, 추천, 기한임박 같은 상품에 대한 여러 상황마다 다른 이미지를 쓰는 경우에는 프론트에서 처리하기도 어렵고, 사과에 대해 여러 이미지가 있는 상황이면 1-1.png, 1-2.png 이런식으로 몇개인지를 확인해서 가져와야됨
그런의미에서 복잡해지면 백엔드에서 그냥 모든 이미지 경로를 객체에 포함해서 주게된다고 말한거임
익명(118.176)2025-01-21 23:39
절대 프론트에서 경로를 만들지마
익명(dokkaebi2)2025-01-21 23:36
당장 드는 생각 중에 하나는, 이미지를 저장하는 주체, 혹은 이미지의 경로를 파악하고 있을 주체가 백엔드일텐데, 그럼 백엔드가 주소를 만들어서 넘겨주는 게 훨씬 자연스러워 보임.
보안은 잘 모르지만, 보안 관리하는 것도 백엔드에서 해당 로직 관리해서 주소를 넘겨줄지, 토큰을 같이 줄지 결정하는 것도 맞아보이고.
엄청 간단한 프로젝트면 프론트에서 경로 만드는 방식도 쓸 수는 있을텐데...그냥 뭔가 아닌거 같음. 삽고수가 알려주면 좋겟네.
단건이면 이미지링크 클라이언트에서 땡겨쓰고 다건이이면 zip파일 내려줄 수도 있으니 서버에서 처리해야 할 수도 있는데 파일이나 이미지 송수신 API 인터페이스 정의를 한다고 했을때 서버가 자연스러운듯 - dc App
아 파일 송수신 하려는건 아니고 웹페이지에 상품 이미지 보이게 하는 상황인데, 그래도 판단 기준은 같을까? - dc App
짧은 식견이지만 현 상황에서 이미지처리를 클라이언트에서 하되 dto에 path는 넘겨두는게 좋을것같아요 확장성을 염두해 둬야하니까요 단건이라도 초고화질이라던가 하는 이유로 성능문제가 있다고 하면 이미지처리도 해야하고 등등.. - dc App
이해를 못했는데 다시 설명가능함?? - dc App
네이버 쇼핑처럼 상품 이미지 주루룩 뜨는걸 구현하고 싶음. 상품 이미지 경로는 상품id에다가 간단한 처리를 하는 방식으로 얻을 수 있음. 그럼 이때 상품id에서 이미지 경로를 얻는 처리를 프론트에서 할지 백엔드에서 할지가 고민이야 - dc App
상품 객체에 이미지 경로가 따로 있는게 아닌거야? - dc App
GET /item/{itemId}/image 하나 뚫는건?
해당 댓글은 삭제되었습니다.
맞음!! json에 id, imagePath 다 포함시키는게 일반적인가 보넹 - dc App
전에 다니던 회사는 경로를 다 백엔드에서 json으로 감싸서 넘겨줬음. 근데 님 말처럼 프론트에서 아이디만 가지고 구현하는 것도 가능은 할 거 같은데. 굳이 이걸 프론트에서 할 이유가 있나 싶은뎅
딱히 정해진건 없음 간단한 사이트 같은 경우에는 itemId 만으로 특정 이미지를 찾을 수 있겠지만, 복잡해지면 백엔드에서 미리 객체에 이미지 경로까지 넣어보내줘야되 그냥 님 편한대로 하는거고, 상황에 따라 선택하는거임
예를 들어 지금은 사과에 id: 1을 부여하고, 바나나에 id: 2를 부여해서 프론트에서 그냥 /assets/images/1.png를 요청할수도 있겠지만, 사과가 매진된 상황에서 다른 이미지를 보여주고 싶다면 /assets/images/1-soldout.png 이런식, 혹은 /assets/images/soldout/1.png 이런식으로 요청해야될수도 있음 이러한 상황에서 매진, 베스트셀러, 추천, 기한임박 같은 상품에 대한 여러 상황마다 다른 이미지를 쓰는 경우에는 프론트에서 처리하기도 어렵고, 사과에 대해 여러 이미지가 있는 상황이면 1-1.png, 1-2.png 이런식으로 몇개인지를 확인해서 가져와야됨 그런의미에서 복잡해지면 백엔드에서 그냥 모든 이미지 경로를 객체에 포함해서 주게된다고 말한거임
절대 프론트에서 경로를 만들지마
당장 드는 생각 중에 하나는, 이미지를 저장하는 주체, 혹은 이미지의 경로를 파악하고 있을 주체가 백엔드일텐데, 그럼 백엔드가 주소를 만들어서 넘겨주는 게 훨씬 자연스러워 보임. 보안은 잘 모르지만, 보안 관리하는 것도 백엔드에서 해당 로직 관리해서 주소를 넘겨줄지, 토큰을 같이 줄지 결정하는 것도 맞아보이고. 엄청 간단한 프로젝트면 프론트에서 경로 만드는 방식도 쓸 수는 있을텐데...그냥 뭔가 아닌거 같음. 삽고수가 알려주면 좋겟네.
백엔드가 API 리스폰스에 image_url 같은거 포함해서 넘겨줌
그냥 단순한 템플릿인데 어디서 하든 상관없지않나 보통은 백엔드에서 하겠지만