0831

MFA

• 웹서비스가 제공해야 하는 기능이 점점 많아지며 발생하는 문제들(서버 복잡도, 빌드 시간 증가, CI/CD 어려움 ...)을 해소하기 위해 등장한 아키텍처
• feature(기능) 단위로 나누어 쪼개서 문제를 해결하는 관점
• mfa가 등장하기 전에는 모놀리식 시스템을 사용했음.
  • 모놀리식은 애플리케이션의 모든 기능을 하나의 거대한 코드 베이스와 하나의 빌드/배포 단위로 묶은 구조를 의미함.
  • 그래서 변경사항이 작을 때도 전체 애플리케이션을 다시 빌드하고 배포해야됨. 극심한 손해.
• 근데 micro frontends architecture가 나오면서 여러개의 독립된 애플리케이션 단위(마이크로 단위)로 나눠서 관리할 수 있게됨.
• 관리할 땐 마이크로 단위로 관리하고, 런타임 때 하나로 뭉쳐서 조립하는 방식.
• https://medium.com/@june.programmer/architecture-micro-frontend의-등장-61062e52d44b
• https://lion-king.tistory.com/entry/마이크로-서비스-vs-모놀리식-아키텍처-MicroService-vs-Monolithic-Architecture-간단-소개-및-주관적-의견

BFF

• Backend For Frontend의 약자로, 말 그대로
  프론트엔드를 위한 백엔드 계층을 따로 두는 아키텍처 패턴
• MSA 환경에는 여러개의 마이크로 서비스가 있을거 아님?
• 근데 이걸 프론트엔드에서 그대로 호출하기는 불편함.
  • 왜지? 애초에 백엔드에서 api 설계할 때 제대로 하면 되는거 아닌가?
    라는 생각을 했는데
  • 프론트엔드에서는 한 번에 많은 데이터를 갖고와서 화면을 풍성하게 보여주길 원하잖음? 근데 이걸 백엔드 쪽에서 모든 케이스를 고려해서 설계하면 API가 지나치게 복잡해질거임.
  • 그리고 보안 관점에서도 클라이언트에서 다루는 것 보다 BFF에서 인증/인가 처리 후 가공 된 데이터만 클라이언트 딴에 전달하는게 좋음.
  • 성능적인 측면에서도 여러 API를 각각 호출하는 것 보다, BFF로 여러 서비스 호출을 서버 쪽에서 한 번에 묶어서 Aggregation(집합)하는게 좋음.
• 그래서 프론트엔드 전용 API 게이트웨이 역할을 하는 BFF 레이어를 두는 경우가 있음.
• https://tech.kakaoent.com/front-end/2022/220310-kakaopage-bff/

정말 꼭 필요할까?

1. api gateway(관문)에서 aggregation
   • aws api gateway나 kong과 같은 인프라/플랫폼 차원에서 마이크로 서비스를 묶어서(aggregation) 전달.
   • 프론트에 특화 된 요구사항(데이터 가공)을 다루기엔 부족할 수 있음.
2. graphQL
   • 마이크로 서비스를 GraphQL에 붙여놓고 프론트엔드는 단일 엔드포인트만 호출
   • 쿼리로 불러오니 필요한 데이터만 딱 맞게 받아올 수 있지만, 쿼리 복잡성이 증가되고 캐싱 처리가 어려워질 수 있음.

cf. 왜 graphQL을 사용하면 캐싱 처리가 어려워지는가?
graphQL은 단일 엔드포인트만 존재하기에 url만으로는 캐싱이 불가능함. 그래서 tanstack query같은걸로 캐싱을 해결하는 것.

cf.

• graphQL
  • 데이터를 그래프(Graph) 구조로 모델링해서 Query Language로 표현해서 GraphQL이라고 함.
• Rest는 Represnetational State Transfer의 약자.