프리온보딩 프론트엔드 2회차

퇴근하게 해주는 방법 중 하나! 비즈니스 로직 제압하기

"프론트에서 해드릴게요" 또는 " 프론트에서 해주세요"

작업을 하다보면 마감 시간, 업무량 등 다양한 사유로 인해 프론트에서 처리할 업무가 아닌 경우에도 프론트가 맡아서 하는 경우가 있다. 예를 들어 페이지네이션, 검색 로직 등이 있다.

 

해당 작업은 프론트에서 하면 문제가 발생하는가? 그렇다!

 

발생할 문제들을 보면

• 함수가 더 많아져 관리할 부분 증가
• 단순한 역할의 함수가 보다 더 많은 역할을 담아 코드의 낭독화
• 로직의 중복 작성
  예를 들어, 프론트에서 검색 로직을 작성하는 경우 앱에서도 작성해야 한다.
• 핵심 비즈니스 로직이 노출될 보안 상의 위험
  웹의 소스 코드는 누구나 볼 수 있고 난독화되어도 GPT와 같은 기술의 발전으로 충분히 읽을 수 있다.

 

비즈니스 로직이란?

일반 로직과 달리 요구사항에 특정 상황 또는 조건이 있는 경우를 말한다. 예를 들어 가격 할인 로직, 사용자 인증, 재고 관리 등에 사용되는 로직을 말할 수 있다.

 

프론트에서 비즈니스 로직과 헷갈리는 것은 UI 로직이다. 버튼 클릭, 페이지 스크롤, 폼 제출 등과 같은 UI 기능을 구현하는 코드는 비즈니스 로직과는 다르기 때문에 구분할 수 있어야 좋다. 뭐가 좋은가? UI 기능과 비즈니스 로직의 분리 / 핵심 비즈니스 로직 같은 경우 백엔드 API 단으로 격리하기 위해서라고 한다.

 

하지만 비즈니스 로직과 일반 로직을 물과 기름처럼 완벽히 분리하는 것은 어려운 일이다.

 

비즈니스 로직 격리하기

1. 추출과 추상화 구분하기
   추출은 물리적 분리를 의미하고, 추상화는 일반화 형태의 개념화를 의미한다.
2. 캡슐화
   객체의 속성과 행위를 하나로 묶어 실제 구현 내용 일부를 내부에 감추어 은닉한다.
3. 추상화 벽과 어댑터
   추상화 수준이 다르면 보기 어려운 코드가 되기에 가능하면 맞추는 것이 좋다. 하지만 추상화 수준을 맞추다 보면 코드의 depth가 깊어질 수 있기 때문에 적절한 판단이 중요하다.
   어댑터 패턴을 사용해 원하는 기능만 반환시켜 넘겨주어 사용하는 입장에서는 차이를 느끼지 못하도록 격리함으로써 변경에 대처하기 쉬워진다.

 

기타

클린아키텍처-육각형 아키텍처, BFF(BackEnd For FrontEnd), toss-useOverlay, Intersection Observer, Compound Component Pattern, <Card.Title>(합성 컴포넌트, Object.assign을 활용), 배포전략-블루/그린

프론트가 가지는 운영지식의 중요성(인프라, 도커, 배포 등) : 프론트가 UI 만들고 그에 맞는 로직만 짜면 끝이 아니라 배포나 테스트, 인프라에도 관심을 가지고 지식을 가지고 있어야 현업에서 버틸 수 있다.

Ruby 서버의 장점 : 서버에 장애가 발생한 경우에도 로그(?)를 볼 수 있다. 이는 인터프리터 언어이기 때문에 가능하다.

높은 응집도, 낮은 결합도

https://patterns-dev-kr.github.io/ : 디자인 패턴 및 성능 패턴에 대한 최신 정보 제공

학습: 23.12.09

느낀점: 저번 강의와 다르게 오늘은 강의 들을 때 이런 거구나 했던 것들이 시간이 지나 정리를 하려고 하자 모르겠는데? 가 많아 복습이 많이 필요할 것 같은 강의였다.