많은 비동기 호출 대 API에 대한 단일 호출

우리는 자바 스크립트를 통해 HTML5 프론트 엔드에서 사용할 REST API를 개발하고 있습니다. 이 응용 프로그램은 조직 내에서 사용되며 일반적으로 약 300 명의 사용자가 있지만 최대 1000 명의 사용자까지 확장 할 수 있습니다.

일반적으로 API에 대한 연결은 LAN 내에서 이루어 지므로 연결 속도가 느리고 연결이 3G / 4G를 통해 지연 될 수있는 인터넷에서 가끔 사용되는 것을 배제하지는 않지만 연결 품질과 대기 시간은 양호합니다.

우리가 생각한 두 가지 옵션은 다음과 같습니다.

1. 프론트 엔드는 인터페이스의 다양한 구성 요소를로드하기 위해 API에 대한 여러 개의 비동기 비동기 호출을 작성합니다.

   • 장점 : 단순성.
   • 단점 : 서버에 대한 추가 연결.

2. 프론트 엔드의 컨트롤러는 API를 한 번 호출하여 객체를 가져와야하는 매개 변수로 전달합니다.

   • 장점 : 서버가 데이터베이스에 여러 번 연결하더라도 서버에 한 번만 연결됩니다.
   • 단점 : 프런트 엔드와 API 모두에 메커니즘이 필요합니다. 디자인이 복잡합니다.

추가 설명 : 다른 리소스가 있습니다 ... / 제품 ... / 위치 등.이 리소스는 단독으로 가져올 수 있지만 다른 추상 리소스가 있습니다 ... / screen?

다음과 같은 이유로 옵션 1 (여러 비동기 호출)이 가장 좋습니다.

1. 각 개별 통화는 고유 한 엔터티 이므로 문제가 발생하면 개별적으로 다시 시도 할 수 있습니다. 단일체 '원콜'아키텍처에서 한 가지가 실패하면 전체 호출을 다시 수행해야합니다.
2. 서버 측 코드가 더 간단 해집니다. 다시 한 번 모듈화 는 다른 개발자가 다른 API 리소스에서 작업 할 수 있음을 의미합니다.
3. 일반적인 MVC 패턴 에서는 하나의 API 호출로 여러 개의 개별 리소스를 로드하는 것이 이치에 맞지 않습니다 . 당신이 요청을 할 수 있도록 예를 들어, /products페이지에 표시 할 제품의 목록을 얻으려면, 당신은 인기 제품 판매 지역의 목록을 표시하려면, 당신은 두 개의 별도의 자원을 가지고 Product와 Location. 동일한 페이지에 표시되지만 논리적으로 전화를 걸 /products거나 위치를 반환 하도록 할 수는 없습니다.
4. 로깅 / 이용 보고서는 모듈 식 접근 방식에서 더 간단합니다. 요청을 /products하고 위치를로드 하는 경우 로그 파일이 실제로 혼란 스러울 수 있습니다
5. 특정 리소스에 문제가있는 경우 원콜 방식을 사용하면 전체 페이지가 중단되고 사용자에게 문제가 무엇인지 명확하지 않게됩니다. 따라서 팀에서 문제를 해결하는 데 시간이 더 오래 걸립니다. 그러나 모듈 식 접근 방식에서 한 가지 문제가 발생하면 무엇이 깨 졌는지 명확하게 알 수 있으며 더 빨리 해결할 수 있습니다. 또한 페이지의 나머지 부분을 망치지 않습니다 (사물이 너무 밀접하게 결합되어 있지 않으면 ...)
6. 사물이 분리되면 일반적으로 변경하는 것이 더 쉬울 것입니다. 한 번의 API 호출로 5 개의 리소스를로드하는 경우 무언가를 변경하려고 할 때 문제 를 해결하지 않는 방법을 파악하기가 더 어려워집니다

요점은 리소스가 분리되어 있고 REST 서버에서 단일 서버 경로에서 많은 개별 리소스를 반환하는 것은 "서버에 대한 연결을 저장하는"경우에도 의미가 없다는 것입니다. 그런데 매개 변수를 사용하여 조건에 따라 다른 리소스를로드하는 것은 RESTful이 아닙니다.

그러나 논리적 옵션은 리소스를 분리하기 위해 여러 개의 비동기 요청을 하는 것입니다 .

PS-특히 HTTP 연결의 오버 헤드가 매우 낮아 LAN에있는 경우 "서버에 대한 연결"을 미리 최적화하지 마십시오. 박쥐에서 더 단순한 디자인을 선택하는 대신 이런 종류의 사고는 나중에 문제를 일으킬 것입니다.