javascript - 웹사이트 프런트엔드와 백엔드 분리 문제, API 작성

웹사이트의 프론트엔드와 백엔드 분리 문제:
예를 들어 홈페이지는 여러 모듈로 구성되어 있는데, 각 모듈에는 자체 API 인터페이스가 있습니다.
프런트엔드 직원이 저에게 물었습니다. 그 사람한테 데이터를 한번에 돌려주려면 인터페이스도 다시 수정해야 하고,
이거 좋은가요? 아니면 여러 요청을 통해 별도로 데이터를 얻는 것이 더 낫습니까

답글 내용:

웹사이트의 프론트엔드와 백엔드 분리 문제:
예를 들어 홈페이지는 여러 모듈로 구성되어 있는데, 각 모듈에는 자체 API 인터페이스가 있습니다.
프런트엔드 직원이 저에게 물었습니다. 그 사람한테 데이터를 한번에 돌려주려면 인터페이스도 다시 수정해야 하고,
이거 좋은가요? 아니면 여러 요청을 통해 별도로 데이터를 얻는 것이 더 낫습니까

좀 더 진지한 해결책을 알려주세요. 하지만 귀하의 질문에 대한 답변이 아닐 수도 있습니다.

대형 프론트엔드 개념에 따라 중간에 Node 레이어를 추가하면 프론트엔드에서는 서버사이드 렌더링이 완료되고, 백엔드는 API 통합이 가능합니다. 그리고 이것은 프런트 엔드에 의해 유지됩니다. 백엔드 없이 직접 수행하세요. :)

리소스 소비가 동일하거나 리소스 소비가 상대적으로 적을 때 하나의 인터페이스가 작업을 처리할 수 있다면 두 개의 인터페이스를 작성하지 마세요

Node, go 및 기타 동시성 API. 한 번에 모두 보내지 않는 것이 가장 좋습니다. 편안한 API 관점에서 보면 이는 좋은 생각이 아닙니다. 즉, 프론트엔드가 변함에 따라 백엔드도 끊임없이 변화하므로 분리 및 모듈화에는 적합하지 않습니다. 프런트 엔드는 redux 및 데이터 캐싱과 같은 상호 작용을 캐시하고 줄일 수 있습니다. 매번 데이터를 얻기 위해 백엔드에 가지 마십시오. 데이터를 한 번 제공하더라도 모든 것을 얻으려면 백엔드에 가는 것을 멈출 수 없습니다. 많은 데이터를 얻은 후 먼저 캐시를 사용한 다음 일정 시간이 지난 후 또는 사용자가 새로 고침을 클릭하면 서버로 이동하여 데이터를 가져올 수 있습니다.

결국 HTTP 요청이 적을수록 좋습니다. 코드 몇 줄만 더 작성하면 됩니다

역할마다 문제에 대한 관점이 다릅니다.
프런트 엔드 관점에서는 모든 요청이 반환될 수 있으므로 http 요청이 줄어들고 성능이 향상되며 프런트 엔드에서 더 적은 요청을 보낼 수 있습니다.
백엔드 관점에서 인터페이스는 모듈로 작성되어 명확하고 간결합니다.

저는 백엔드 사람입니다. 제 일반적인 의견은 [적절하다고 생각됩니다. 개발이 어렵지 않으며 영향을 미치지 않습니다], 반환된 데이터에서 모듈을 구분할 수도 있습니다. 나중에 모듈을 추가하고 삭제하는 것도 쉽습니다.

사람마다 역할이 다르기 때문에 옳고 그름에 대해 논쟁할 필요는 없습니다. 절대적인 것도 없고, 어떤 상황에도 절대적으로 적합한 해결책은 없으므로 유연하게 대처하세요.

물론 고집할 수도 있습니다.

페이지가 매겨진 데이터가 수십 페이지에 달하는 등 반환되는 데이터가 많은 경우 반드시 페이징을 기반으로 데이터를 가져와야 합니다.

반환되는 데이터가 많지 않고, 반환되는 데이터의 양이 많아 성능에 영향이 없을 경우(즉, 영향이 미미한 경우) 작업 부하를 크게 줄일 수 있으므로 한 번만 반환하는 것이 좋습니다. 프론트 엔드와 동시에 요청으로 인해 데이터가 자주 발생하지 않아 성능에도 좋습니다.

HTTP 2.0 사용법을 모르시나요?

HTTP 2.0 다중 요청은 일단 전송되면 그럴 자격이 있습니다.

또한 배경이 RESTful인 경우 결합된 인터페이스는 로직을 파괴하여 매우 해롭습니다. 프런트 엔드가 RESTful을 인식하지 못하는 경우 활성화하면 됩니다.

새 인터페이스를 열고 필요에 따라 다양한 모듈의 데이터를 결합하면 됩니다. 어쨌든, 다른 모듈이 캡슐화되어 있으므로 호출하기만 하면 됩니다. 이 인터페이스도 이 목적으로 특별히 사용되므로 혼합하지 마십시오.