인프런 커뮤니티 질문&답변
작성한 질문수
화면과 관련한 정보 처리 질문입니다
해결된 질문
작성
·
26
1
안녕하세요..!
네이티브 앱 환경에서 서버 개발을 하다보니, 여기 강의에서나오는 리뷰 수가 어떻게 보일지 같은 문제를 서버에서 컨트롤 하자는 얘기가 자주 나와 질문 드립니다.
예를들어, 15000건의 리뷰수를 100+ 였다가, 15k 같은식으로 변경 되는걸 서버에서 string으로 내려달라는 것이죠. 현재는 원본데이터를 도메인에서 처리하고, 보여질 데이터를 dto 단에서 처리하는 식인데요..
매번 화면에 표현되는걸 실험이라고 계속 바꿔대는데, 조금 불편한 느낌이 생기더라구요. 이런 경우는 보통 어떻게 처리하는게 좋을까요? 화면을 제어하는 필드가 많아질 수록 더 관리가 안되는거 같아요. 특히 os 별 다르게 처리한다던가..
답변 1
1
안녕하세요 반가운 비오님! 요즘은 즐겁게 개발 하고 계신가 모르겠네요! 😄
이게 안타깝지만 네이티브 앱 서비스의 숙명이긴한데요, 앱의 경우는 로직을 변경할 수가 없기 때문에 이런 니즈가 생기게 되고 이 부분은 현실적으로 타당하다고 봅니다.
(웹뷰를 쓴다면 앱 쪽에서 자체 실험이 가능하니 괜찮겠지만..........)
특히 네이티브 앱은 장기적으로 최악의 경우 코딩 된 로직을 바꿀 수 없기 때문에 서버 입장에서도 나중에 API 하위호환성 문제가 생길 수 있습니다 😢
그래서 네이티브 서비스의 경우는 이렇게 진행하는게 맞다고 보여집니다
그럼 알겠는데... 서버에서는 어떻게 해야하는가? 이런 경우라면 특히나 Presentation Layer를 적극 활용해야합니다
구현 영역은 최대한 순수하고 데이터를 그대로 보여주도록 만들고 API 응답 영역에서 요구사항에 맞는 커스텀을 맞춰주는 전략을 해야합니다.
(그래야 최대한 내부는 안 바뀌고 응답 스펙만 바뀌어서 대응이 가능하니까요..!)
아마 이미 질문을 보니 이미 이런 전략으로 하고 계실 것 같은데요, 최대한 API 응답 레이어를 격리하는 것을 하시는게 가장 현실적인 전략일 것 같습니다 😢
그냥 API 응답 레이어는 서버의 소유가 아니라 앱을 위한 번역 계층이라고 이해하는게 좋다고 생각합니다
모쪼록 완강까지 잘 부탁드리고 완강 후의 수강평도 기대하겠습니다!
감사합니다!
핳.. 역시.. 너무 이것저것 조건이 많아질때는
아예 presentation layer 전용으로 서비스 하나 만들어서 화면영으로 별도 처리하기도 하는데,
너무 화면 종속적인 api가 되버리는게 문제가 되더라구요..
어쨋든 화면에 대한 것과 도메인을 잘 격리하는 편이 좋겠네요!