BFF 초기 분석

1. 현재 개발 에서 흔히 볼 수 있 는 '통 증 점'
앞 뒤 단 을 연결 할 때 일부 번 거 로 운 발생 빈도 가 낮 지 않 고 개발 효율 에 어느 정도 영향 을 줄 수 있 으 며 그 중에서 앞 뒤 단 이 인터페이스 데이터 형식 디자인 에 대한 차 이 를 포함한다.둘 중 하 나 는 분야 모델 을 바탕 으로 하 는 것 이 고 하 나 는 사용자 의 상호작용 을 바탕 으로 하 는 것 이기 때문에 디자인 된 데이터 구 조 는 항상 차이 가 있 기 때문에 전단 이 인터페이스 에서 데 이 터 를 얻 은 후에 '데이터 규격화' (나의 호칭...) 작업 을 더 해 야 한다.두 가지 예 를 들다.
이름 이 일치 하지 않 습 니 다. 예 를 들 어 이러한 목록 배열 ranks 가 있 습 니 다.
[

{
    id: 1,
    value: 'DUCHY'
},
{
    id: 2,
    value: 'KINGDOM'
},
{
    id: 3,
    value: 'EMPIRE'
}

] 페이지 의 렌 더 링 구성 요 소 는 value 라 는 속성 명 이 필요 하지만 인터페이스 데 이 터 는 name 을 사용 합 니 다. 그러면 옮 겨 다 니 며 속성 명 을 수 동 으로 수정 해 야 합 니 다.
유사 한 경우 (null, ') / ([], {}) 의 변환 등 이 있 습 니 다. 이것 은 모두 데이터 형식 을 위 한 추가 작업 으로 업무 논리 와 큰 관련 이 없습니다.
일부 인 터 페 이 스 를 재 활용 하기 위해 서 는 인터페이스 데이터 추가 처리 가 필요 합 니 다.
데이터 개체 info:
{

countries: [
    {
        name: 'Austria',
        cities: [
            'Vienna',
            'Tirol'
        ]
    },
    {
        name: 'Persia',
        cities: [
            'Isfahan',
            'Shiraz'
        ]
    },
    {
        name: 'United States',
        cities: [
            'San Francisco',
            'Mountain View'
        ]
    }
]

} 현재 한 장면 이 있 습 니 다. 저 는 countries 배열 의 첫 번 째 항목 (또는 특정한 장면 에서 첫 번 째 항목 만 의미 가 있 습 니 다) 만 원 합 니 다. 그러면 저 는 이 인터페이스 에서 얻 은 데 이 터 를 재 활용 하면 매번 let specified Country = countries [0] 의 기본 값 을 만들어 야 합 니 다. 더욱 복잡 한 장면 에서 이런 할당 은 더욱 깊 고 중복 횟수 가 많 을 수 있 습 니 다.
분명 한 것 은 데이터 형식 과 상호작용 을 처리 할 때 데이터 변 화 를 분리 해 야 한다. 그러면 전단 은 상호작용 의 업무 논 리 를 처리 하 는 데 더 많은 정력 을 기울 일 것 이다.
2. GraphQL 에 대한 탐색 과 응용
이러한 수요 에 대응 하려 면 현재 GraphQL 은 좋 은 방안 입 니 다. 이 를 통 해 요청 형식 을 지정 한 다음 에 필요 한 데 이 터 를 얻 을 수 있 습 니 다. 또한 directive, Fragment, Variable 등 논리 적 판단 과 추상 도 지원 합 니 다. 다음은 이 세 가 지 를 예 로 들 어 상기 사례 에 대한 해결 방안 을 보 여 드 리 겠 습 니 다.
(1) 의 첫 번 째 예:
GraphQL 의 alias 솔 루 션 을 고려 합 니 다: GraphQL 의 별명 alias 디자인 목적 은 같은 Type 에서 여러 대상 을 되 돌려 주 고 이름 충돌 이 발생 하지 않 는 것 입 니 다. 하지만 name - > value 의 이름 을 바 꿀 수도 있 습 니 다.
ranks {

id
value: name

} * 끼 워 넣 은 별명 이 가능 한 지 알 수 없습니다. 검증 이 필요 합 니 다.
(1) 의 두 번 째 예 에 대해:
variable 와 directive 를 사용 하여 논리 적 처 리 를 합 니 다.
query Country($isFirst: Boolean!) {

info(episode: $episode) {
    countries @include(if: $isFirst) {
        name
        cities
    }
}

} 데이터 모델 에서 첫 번 째 요 소 는 is First: true 를 포함 하면 됩 니 다.
3. BFF 의 위치 및 node. js 가 BFF 층 에서 할 수 있 는 일
BFF 의 응용 장면 은 매우 많 습 니 다. 백 엔 드 인 터 페 이 스 를 모 아서 제3자 api 에 제공 하 는 것 은 모두 책임 질 수 있 는 업무 입 니 다.취 합 백 엔 드 인 터 페 이 스 는 앞에서 비슷 한 조작 을 했 지만 몇 개의 인 터 페 이 스 를 취 합 하 는 것 이 아니 라 특정한 인 터 페 이 스 를 추가 로 처리 했다.
BFF 층 의 디자인 은 일반적으로 제품 의 신속 한 교체 수 요 를 만족 시 킬 수 있다. UI 의 상호작용 과 일부 서 비 스 를 모두 team (Frontend 일 수 있 음) 에 맡 기 면 서로 다른 team 의 의사 소통 과 조율 원 가 를 크게 줄 일 수 있 기 때문이다.
node. js 도 BFF 층 에 있 는 데이터 암호 화 (BFF 층 을 넣 는 것 이 적당 합 니까?), 퍼 가기 요청 (nginx 와 비교 해 야 합 니 다) 을 할 수 있 습 니 다.
성능 최적화 작업 도 할 수 있다.
성능 최적화 높 은 병발 과 부하 균형: 흔히 볼 수 있 는 상황 에서 높 은 병발 의 성능 제약 은 대량의 I / O 작업 시 CPU 이 용 률 이 비교적 낮 고 node. js 는 I / O 밀집 형 작업 을 처리 할 때 자신의 장점 을 가진다.
부하 균형 에 있어 nginx 는 자주 사용 하 는 요청 배분 방안 도 있 고 shared memory 솔 루 션 도 있 으 며 세 션 의 일치 성 을 확보 하 는 데 좋 은 표현 을 한다.
node. js 의 client Request 대상 도 header quue 를 유지 하고 요청 한 절 차 를 어느 정도 제어 할 수 있 습 니 다.