2016-08-12 3 views
1

저는 JSON API를 살펴 보았고 확장 성 시나리오에 계속 매달려 있습니다. 당신은 각각 3 개 또는 4 개의 관계를 가진 모델의 큰 콜렉션 (1000)을 가지고 있다고 가정 해 보겠습니다. 나의 이해에서JSON API 스케일링

는, JSON API는 관련 ID (들)과 적어도 관계를 지정해야합니다 (선택적 include과의 관계를 사이드로드). 1000 개 모델의 컬렉션을 매 관계에 대한 JOIN을 할 경우 아래와 같이 유효한 JSON의 API 페이로드를 채울 수있을 :이 가능한 합리적인 방법으로 확장 할 수있는 표시되지 않습니다

... 
{ 
    "some_relationship_name": { 
    data: [ 
     { id: 1, type: "derp" } 
     ... 
    ] 
    } 
} 

.

답변

0

어디에 문제가 있는지 잘 모르겠습니다. 관계 당 20 바이트/관계/1000 레코드 => ~ 100kB가 있습니다. 기존 어댑터는 이러한 데이터를 충분히 빠르게 처리 할 때 문제가 없어야합니다.

데이터를 더 적게 전송해야하는 경우 몇 가지 옵션이 있습니다. 압축을 추가 할 수 있지만 이러한 작은 데이터의 경우 일반적으로 데이터를 압축하는 것보다 데이터를 전송하는 것이 더 빠릅니다.

다른 옵션은 실제로 필요한 데이터 만 보내는 것입니다. 대개 웹 응용 프로그램에 1000 개의 레코드가 필요하지 않습니다. 따라서 페이징 및 지연로드는 실제로 필요한 데이터 만 전송하는 데 도움이됩니다.

+0

나는 분명해야했습니다. 페이로드 크기에 대해 걱정하지 않아도 JOIN 성능에 대해 걱정하고 있습니다. 일반적으로 이러한 종류의 데이터로 JSON API를 준수하기를 원하지 않는 한 관계 ID를 포함하지 않아도됩니다. – maschwenk

1

관계의 id을 지정할 필요가 없습니다. links을 지정하면 링크를 가져올 수 있습니다. 체크 아웃 the specification.

그래서 당신은 같은 것을 할 수 있습니다

{ 
    id: '1' 
    type: 'base' 
    relationships: { 
     relA: { 
      links: { 
       self: '/base/1/relationships/relA', 
       related: '/base/1/relationships/relA/related', 
      } 
     }, 
     ... 
    } 
    attributes: {...} 
} 

그래서 당신은 당신이 직접 필요하지 않은 아무것도 가입 할 필요가 없습니다. 예를 들어, 목록에서 사용자는 상세보기에서만 필요한 정보를 결합하지 않습니다.