많은 작은 요청과 소수의 큰 요청 (API 디자인)

현재 다음과 같이 조직과 프로젝트를 진행하고 있습니다.

• 클라이언트 -REST API를 통해 기본 서버에서 데이터를 가져옵니다.
• 서버 -타사 API를 통해 다른 여러 서버에서 데이터를 요청합니다.
• 타사 API-서버에 데이터를 제공하는 통제 할 수없는 서비스 (Reddit, Hackernews, Quora 등)

주장을 위해 클라이언트가 먼저 각 타사 API의 항목 목록이 필요하다고 가정 해 봅시다. 이 목록에서 항목이 선택되어 고객이 항목의 전체 내용과 항목에 대한 응답 (예 : 설명)을 볼 수 있어야합니다. 세 가지 옵션 중 하나를 결정하려고합니다.

일품 요리

이 방법에서는 서버에 3 개의 개별 엔드 포인트가 있습니다. 하나는 항목 목록을 가져오고 다른 하나는 항목의 기본 컨텐츠를 가져오고 다른 하나는 항목의 응답을 가져옵니다.

• 장점 : 필요한 것보다 더 많은 요청을하지 않습니다. 요청은 작아야하므로 일반적으로 더 빠릅니다.
• 단점 : 요청을 많이해야합니다. 목록에서 항목을 선택한 후 사용자는 기본 컨텐츠를보기 전에 기다렸다가 응답을보기 위해 더 오래 기다려야 할 수 있습니다

서버 측 캐시

이 요청에서 모든 소스의 모든 데이터를 "가져 오기"위해 서버를 한 번 호출합니다. 그러면 데이터가 서버에 캐시됩니다. 그러면 서버에 이미 데이터가 있고 클라이언트에 데이터를 공급하기 때문에 호출 사이에 대기 시간이 많지 않다는 점을 제외하면 클라이언트는 이전과 동일한 REST 끝점을 갖습니다.

• 장점 : 클라이언트 측에서 여전히 구현하기는 쉽지만 대기 시간 문제는 없습니다.
• 단점 : 조금 더 관련이있는 서버 측이며 첫 번째 호출에는 실제로 시간이 오래 걸릴 수 있습니다.

클라이언트 측 캐시

이 시나리오는 클라이언트가 서버에 한 번만 요청하면 모든 데이터를 제공한다는 점을 제외하면 이전 시나리오와 유사합니다. 여기에서 데이터를 저장하고 적절하게 사용하는 것은 고객의 책임입니다.

• 장점 : 손쉬운 서버 구현, 첫 호출 후 매우 빠름
• 단점 : 첫 번째 호출은 매우 느리고 더 복잡한 클라이언트 측 구현입니다.

어느 것이 가장 좋은 방법인지 확실하지 않거나 명확한 해결책이 누락되었을 수 있습니다. 어떤 조언이라도 대단히 감사하겠습니다!

명심해야 할 것은 클라이언트와 서버 사이에 예상되는 네트워크 대기 시간 (핑 시간)입니다. 대역폭이 좋은 대기 시간이 긴 상황에서는 많은 작은 요청이 하나의 큰 요청 보다 훨씬 나쁘게 수행됩니다 .

최근에 팀 중 하나가 인도에있는 다중 팀 데이터베이스 기반 웹 응용 프로그램 프로젝트를 공동 작업하고 있습니다 (나머지는 미국에 있음). 우리는 개발자가 로컬 웹 서버 인스턴스를 연결하기 위해 미국 사무소에 호스트 된 단일 데이터베이스 인스턴스를 가지고 있습니다. 내 책상은 데이터베이스 인스턴스에서 50 피트, 2 개의 LAN 홉이 떨어져있을 수 있으며 성능은 좋습니다.

우리가 인도의 개발자들과 처음으로 일을 시작했을 때, 그들은 응용 프로그램을 시작하고 페이지 간을 탐색하는 데 막대한 대기 시간이 발생했습니다. 우리는 여기서 10 분의 대기 시간을 이야기하고 있습니다. 책상에서 개발자 데이터베이스 서버까지의 ~ 200ms 핑 시간에 데이터베이스에 대한 많은 간단한 쿼리가 곱해지기 때문입니다. 내 로컬 0.5ms 핑은 너무나 사소하여 웹 서버와 데이터베이스 서버 간의 대화가 중요하지 않았습니다. 우리가 웹 서버와 데이터베이스 서버를 지리적으로 분리 한 것은 이번이 처음입니다.

이 경우의 해결책은 데이터베이스 서버를 복제하고 인도에서 사본을 세우는 것이었지만 여기서 중요한 점은 클라이언트와 서버가 멀리 떨어져 있으면 네트워크 대기 시간에 여러 통신 수를 곱한다는 점을 명심해야합니다. 철사. 연결이 설정되면 대역폭은 일반적으로 훨씬 덜 중요합니다.

이 세 가지 옵션은 상호 배타적이지 않으므로 클라이언트 측 캐시와 서버 측 캐시를 함께 사용할 수 있습니다. 그러나 주석과 같이 일부 데이터는 캐시에 너무 오래 보관하면 오래되지 않을 수 있습니다. 이러한 경우인지 확인할 수 없다는 점을 고려하면 저장하지 않는 것이 좋습니다. 반면에 콘텐츠는 일반적으로 크게 변경되지 않으므로 서버 쪽을 캐싱 한 다음 클라이언트 쪽에서 일부를 미리 가져와 대기 시간을 줄이더라도 아무런 해가 없습니다.

귀하가 제공 한 정보, 옵션 1을 기준으로합니다.

• 단일 고객 요청으로 사과와 오렌지를 섞어서 과일 바구니가 매우 클 수 있습니다.

• 캐싱은 성능을 얻지 만 일관성 ( 손실 데이터)을 잃을 수있는 절충점입니다. 확인 된 성능 문제가없는 경우 일반적으로 동기화 문제는 위험하지 않습니다.

나는 항상 더 나은 성능과 확장 성을 갖춘 몇 가지 큰 요청을 발견했습니다. 그러나 모든 접근 방식에는 장단점이 있으므로 서버와 클라이언트의 요구에 따라 다릅니다. 클라이언트가 검색 할 전체 범위 또는 데이터 세트를 지정하도록하는 다른 옵션을 사용하고 싶을 수도 있습니다. 모든 데이터가 아니라 일부 범위는 사용 가능한 대역폭과 일치하도록 시간이 지남에 따라 조정됩니다.

나는 (거의) 할인 옵션 3을 원합니다. 1과 2 사이의 선택은 두 가지에 달려 있습니다.

• (A) 단일 총 반입 결과가 얼마나 큰가
• (B) 클라이언트 / 사용자가 일반적으로 해당 세션에서 사용할 결과의 세부 사항 양.

A와 B가 극단적 인 경우 쉽게 결정을 내릴 수 있습니다.

• A가 크고 B가 작은 경우 옵션 1 (A la Carte)로 이동하십시오.
• A가 작고 B가 큰 경우 2 (서버 측 캐시) 또는 3 (클라이언트 측 캐시)으로 이동하십시오.

다른 A / B (대형 / 소형) 변형의 경우 재량을 적용해야합니다. 나는 종종 다른 클라이언트의 다양한 사용 사례를 충족시키기 위해 거친 엔드 포인트와 정밀한 엔드 포인트를 모두 제공 합니다 .

항상 프로그래밍에서와 같이 다릅니다.

실제 질문은 A / B / C 또는이 세 가지의 조합을 결정할 때 고려해야 할 사항입니다.

실제 차별 요소는 사용중인 타사 API의 구현 세부 사항이라고 말하고 싶습니다. 예를 들어 다음과 같은 사항을 고려해야합니다. 데이터가 자주 예기치 않게 변경됩니까? 그들은 "정말"입니까 아니면 휴식입니까?

데이터가 너무 자주 변경되어 서버 측 캐시에서 부실 캐시 문제가 발생하기 때문에 빠르고 쉽게 전화를 걸 수있는 서비스의 경우 반드시 옵션 1 : 더 많은 요청, 캐시 없음, 필요한 경우에만 수행하십시오.

외부 데이터가 예측 가능한 방식으로 변경되거나 사용량이 제한되거나 단순히 서버에서 데이터를 캐싱하는 데 더 나은 사용자 경험을 얻을 수있는 경우 2로 이동하십시오. 그러나 캐시는 무료가 아닙니다. 디버깅 측면에서 비용이 들며 때로는 업데이트를 보지 않는다고 불평하는 사용자가 있습니다.

옵션 3은 데이터가 많지 않은 경우에만 고려하지만이 경우 옵션 1 또는 2조차도 작동 할 수 있으며 서버에 더 많은 논리를 유지하므로 1 또는 2를 고수합니다.

그냥 내 2c.