# bff

ohkh7797

기존에 MSA아키텍쳐의 경우 정말 많은 기업에서 활용하기에 알아본적이 있지만 BFF는 처음 들어보기에 이번 기회에 새로이 공부하고자 한다. MSA(MicroService Architecture) MSA의 가장 큰 특징은 독립적으로 배포가 가능한 작은 서비스의 모음이다. Why? Monolithic Architecture처럼 모든 구성요소가 통합되어 있다면 한부분의 오류가 모든 부분에 영향을 줄 수 있고, Scale out, 책임, 배포시간 등 여러 부분에서 한계를 보인다. 이를 해결하기 위해 MSA를 사용한다. MSA특징? 오직 노출된 API를 통해서 사용가능하다. 실질적인 세부사항은 추상화한다. 하나의 MicroService는 하나의 비즈니스 범위에 맞춰서

rachaen

BFF를 말하기 전에 MSA에 대해 간단하게 집고가자. MSA란? Micro Service Architecture로 큰 Monolithic 어플리케이션을 마이크로하게 나눈 독립적인 서비스를 연결한 구조를 말한다. MSA의 목적 서비스의 독립성과 확장성을 통한 효율적인 소프트웨어 개발 및 유지 보수 MSA 장단점 장점 배포: 각 서비스를 개별적으로 업데이트하고 확장할 수 있음. 확장성: 독립적으로 확장 가능. 자세하게 말하면 특정 서비스에 대한 요청이 증가하면 해당 서비스만 확장하여 처리 가능 유연성: 독립적인 실행환경에서 작동하므로 서비스별로 최적화된 기술을 사용하기 좋음 시스템의 가용성과 안정성 향상: 에러가 해당 서비스 내에서 제한. 하나의 서비스에 문제가 생기더라도 다른 서비스는 계속 정상적으로 작동. 단점 데이터 일관성 유지: 서비스마다 독립된 데이터베이스를 가지므로 전체 시스템에 서 데이터 일관성을 유지하기 힘듬 서비스

rachaen

[Next.js] BFF 패턴에서 토큰 처리하고 axios 요청보내기에서 쿠키로 저장했던 토큰을 로그아웃 시 지우는 로직을 구현하였습니다. logout endpoint에 대한 요청을 처리하는 함수입니다. Set-Cookie헤더를 설정하여 token이라는 이름의 쿠키를 빈 값으로 설정하고 Max-Age를 0으로 설정하여 쿠키를 즉시 만료시켜 제거합니다.

rachaen

BFF 패턴으로 개발을 하려던 중에 multipart/form-data 형식으로 요청을 보내야 했었다. 우선 클라이언트에서 보낸 파일을 pages/api에 구현된 BFF에서 처리를 해야했다. 클라이언트에서 보낸 데이터 처리하기 Multer에서 Fromidable로의 전환 클라이언트에서 보내는 데이터를 처리하기 위해 처음에는 Multer로 열심히 시도를 해보았다. 하지만 왜 안되는 거지? 그것은 바로 Multer은 Express 미들웨어이기 때문... 아무생각 없이 사용한 나 자신 반성.. 내가 사용하고 있는 건 Next.js로 Express를 사용하지 않는다. next-connect 라이브러리를 사용하면 multer를 사용할 수 있다고 하지만 Express에 종속적이지 않은 Formidable을 사용하기로 생각했다. node.js에서는 formData를 처리할 수 없다?! FormData 객체는 웹 브라우저 환경에서 HTML 폼 데이터를 쉽게 처리하기

rachaen

Next.js에서 소셜 로그인 후 토큰을 저장하는 것에 대한 문제가 발생하였다. 토큰을 BFF에서 사용해야했기 때문에 로컬 스토리지에 저장하여 사용할 수 없는 상황이었다. 그래서 클라이언트에서 받은 토큰을 BFF 서버에서 쿠키로 설정하는 방식을 택하였습니다. 프로젝트에서 pages/api 디렉토리를 사용하여 BFF를 구현하였습니다. 과정 소셜 로그인 후 redirection 처리 소셜 로그인이 성공하면, spring 서버는 클라이언트에게 토큰과 함께 리다이렉션 URL을 보냅니다. 이 URL에서 토큰을 추출하고, 이를 BFF 서버에 전송하여 쿠키에 저장하도록 요청합니다. 토큰 저장 클라이언트가 보낸 토큰을 쿠키에 저장하는 엔드포인트를 만들었습니다. 쿠키 파싱 쿠키를 파싱하고, 토큰을 추출하는 유틸리티 함수를 만들었습니다. BFF axios 인스턴스 생성 BFF(Browser-facing server)에서 사용할 요청에 인증 헤더를 자동으로 추가하는 역

greeeedy

리버스 프록시와 API Gateway, BFF 패턴에 관한 내용을 정리한 포스트입니다. 리버스 프록시와 API Gateway 리버스 프록시의 일반적 용도 리버스 프록시는 클라이언트 측과 하나 이상의 백엔드 서버 간의 중재자 역할을 한다. Nginx와 같은 웹 서버 소프트웨어를 이용해서도 설정할 수 있다. 로드 밸런싱 : 들어오는 요청을 여러 백엔드 서버에 분산시키는 기능을 제공한다. 이러한 로드 밸런싱은 개별 시스템의 과부하를 방지하고 백엔드 장애를 방지한다. 일부 오류로 인해 특정 서버에 도달할 수 없게 되면 로드 밸런싱 모듈이 수신 요청을 나머지 백엔드로 재분배한다. 공격으로부터 보호 : 인터넷과 사설 네트워크 사이에 위치하여

rbw

참조 https://www.youtube.com/watch?v=XqQJ6-l26QM > 위 영상을 보고 정리한 글, 영어 촙오라 좀 틀린 부분이 있을 수도 없을 수도 ~ Backend Problem BFF를 활용하는 방법을 알아보기 전에, 기존 특정 레거시 프로젝트에 대해서 살펴보겠습니다. 범용 API가 존재하고, 처음에는 웹 클라이언트만 존재하는 상황이 있을 수 있습니다. 시간이 지남에 따라 iOS, 안드로이드가 추가되고 더 많은 클라이언트들이 추가될 수 있습니다. 이렇게 다양한 클라이언트가 동일한 API를 사용한다면 이 API가 실제로 목적에 적합하지 않은 상황도 일어날 수 있습니다. 예를 들어, 쇼핑 앱같은 경우 웹 클라이언트 환경에서는 상품 리스트의 경우 상품의 디테일한 정보, 바코드 등까지도 바로 보여줄 수 있지만, 모바일 환경에서는 공간이 매우 제한이 되어 있기 때문에 디테일한 정보, 바코드 등을 보여주지 못하는 상황이 그런 경우입니다. 요즘

s2ksh77

최근 들어 프론트엔드에서도 BFF들이 요구가 되면서, 기존에 SpringBoot로 구축해서 서비스를 운영 해보았던 환경 외에 자체적으로 docker 환경과 mysql을 사용한 BFF 환경 구축에 대한 부분을 기록용으로 남겨보고자 글을 작성하게 되었습니다. 기존에는 로컬DB 환경을 구축하기 위해 mongoDB와 같은 데이터베이스를 사용하거나 PostgresSQL 과 같이 nodejs의 express 환경에서 db를 구축해 사용 해보았었습니다. 하지만 docker를 사용하여 mysql을 사용할 수 있는 부분에 흥미를 갖게 되어 구축 해보았던 간략한 글을 적으려 합니다. Docker의 정의 Docker라고 하면 `리눅스의 응용 프로그램들을 프로세스 격리 기술들을 사용해 컨테이너로 실행하고 관리하는 오픈

bewisesh91

오픈 소스 프로젝트를 진행하면서 여러 아키텍쳐 패턴을 학습할 수 있었다. 그 중 가장 기억에 남는 것은 BFF(Backend For Frontend) Pattern이었다. 이는 여러 프론트엔드 애플리케이션 또는 인터페이스에 단일 백엔드 서비스를 지정하지 않으려는 패턴이다. 예를 들어, 애플리케이션이 처음 상호 작용하는 플랫폼이 Web으로 유일하다가 사용자 기반이 늘어남에 따라 Mobile(Android, iOS)로 점차 확장되었다고 가정해보자. 이때, 백엔드 서비스는 Web과 Mobile 인터페이스의 요구 사항을 모두 충족하는 범용 백엔드 서비스가 된다. 그런데 Mobile 인터페이스의 요구 사항은 Web과 다르기 때문에, 백엔드 서비스에서는 이를 충족하기 위해 Web에서는 필요없는 내용까지 구현하게

seeh_h

올해 초 즈음부터 여러 기업의 테크 블로그에서 BFF(Backend-For-Frontend)에 관련된 글을 많이 읽었다. BFF 개념과 용도에 대해 알게 되었지만, MSA 환경에서 개발 경험이 없다 보니 필요성에 대한 공감은 크게 하지 못하고 있었다. 최근 회사에서 MSA 구조를 채택하여 신규 제품을 개발하고 있다. 개발을 진행하면서 BFF의 필요성을 느끼고 도입을 하게 되었는데 작업하며 느낀 점을 공유하고자 포스팅을 작성하게 되었다. MSA(MicroService Architecture) 본격적으로 BFF 이야기를 하기 전에 MSA로 이야기를 시작해야 할 것 같다. MSA는 Microservice Architecture의 약자로 독립적인 배포가 가능한 서비스들로 구성된 아키텍처라는 의미를 갖는다. 기존에는 모든 서비스가 한 곳에 모인 Monolithic한 구조로 개발을 진행하는 경우가 많았지만, 서비스의 규모가 커지면서 Monolithic한 구조로는 해결

fffo

5. BFF(Backend for Frontend)의 이해 BFF는 마이크로 서비스 아키텍처 패턴 중 하나 5.1. BFF의 등장 배경 5.1.1. 모노리스 아키텍처(Monolith Architecture) 모든 프로세스가 긴밀하게 결합되고 단일 서비스로 실행됨 앱의 한 프로세스에 대한 수요가 급증하면 해당 아키텍처 전체를 확장해야함 앱의 한 프로세스가 중단되면 앱 전체가 중단됨 이러한 단점을 극복하고자 MSA 등장 5.1.2. 마이크로 서비스 아키텍처(Micro Service Architecture, MSA) 앱을 마이크로 서비스 단위로 나눠서 개발, 각각의 서비스는 API 통신으로 서로의 정보를 교환 마이크로 서비스?

skysoo

1.마이크로서비스 설계 원칙 2.마이크로서비스 데이터 설계 3.마이크로서비스 통신 설계 4.마이크로서비스 외부 API 통합 패턴 1. 마이크로서비스 설계 원칙 1. 비즈니스 도메인을 중심으로 모델링 도메인 기반 설계를 통해 더욱 안정된 서비스를 구축하고 다양한 사용자 인터페이스에 대해 보다 쉽게 각 서비스들을 재결합 할 수 있다. 2. 자동화 문화 많은 수의 마이크로서비스의 복잡성을 관리하려면 자동화가 필수적이다. CI/CD 빌드 파이프라인 단계에서의 SIT(System Integration Testing) & UAT(User Acceptance Testing) 테스트 프로비저닝, OS 구성, 서비스 이미지 생성 등 3. 구현 세부 정보 숨기기 서비스가 독립적으로 변경되고 진화할 수