더 빠른 것은 무엇입니까? REST API를 사용하거나 데이터베이스를 직접 쿼리 하시겠습니까?

현명하게 더 빠른 성능은 무엇입니까? REST API를 생성하고 웹 앱이 REST API를 사용하여 데이터베이스와의 모든 상호 작용을 수행하거나 데이터베이스를 직접 쿼리 (예 : 언어가 JDBC for Java와 같은 데이터베이스를 쿼리하는 데 사용하는 일반적인 객체 사용)?

REST로 보는 방법 :

1. 코드에서 객체를 만들어 REST 메소드를 호출합니다.
2. http 메소드 호출
3. REST API 내부의 코드는 데이터베이스를 쿼리합니다.
4. 데이터베이스가 일부 데이터를 반환
5. REST API 코드는 데이터를 Json으로 압축하여 클라이언트로 보냅니다.
6. 클라이언트가 Json / XML 응답을받습니다.
7. 코드에서 객체에 대한 응답 매핑

반면에 데이터베이스를 직접 쿼리합니다.

1. 쿼리 문자열을 사용하여 데이터베이스를 쿼리하는 개체를 만듭니다.
2. 데이터베이스가 일부 데이터를 반환
3. 코드에서 객체에 대한 응답 매핑

이것이 REST API 사용이 느리다는 것을 의미하지 않습니까? 아마도 데이터베이스 유형에 따라 다를 수 있습니까 (SQL 대 NoSQL)?

복잡성을 추가하면 코드가 느리게 실행됩니다. 필요하지 않은 REST 서비스를 도입하면 시스템이 더 많은 작업을 수행함에 따라 실행 속도가 느려집니다.

데이터베이스를 추상화하는 것이 좋습니다. 속도가 걱정된다면 데이터를 메모리에 캐시하여 요청을 처리하기 위해 데이터베이스를 건드릴 필요가 없도록 할 수 있습니다.

성능을 최적화하기 전에 해결하려는 문제와 사용중인 아키텍처를 살펴보기 전에 데이터베이스 옵션이 직접 액세스 대 REST가 될 상황을 생각하는 데 어려움을 겪고 있습니다.

당신이 걱정하는 것이 속도라면, 그렇습니다. 위에서 언급 한 이유로 휴식 서비스가 느려질 것입니다. 그러나 설명하는 유형의 속도는 거의 주요 관심사가 아니며 다른 경우 다른 방법으로 해결할 수 있습니다. 조기 최적화는 모든 악의 근원입니다 .

주요 관심사가 상호 운용성 (모바일, 웹, B2B) 인 경우 REST는 기술에 구애받지 않기 때문에 매우 매력적입니다.

데이터베이스를 코딩한다고 가정하십시오. 기본 데이터 저장소를 변경하기로 선택한 경우 어떻게해야합니까? 기본 상점과 밀접하게 연결되어 있다면 얼마나 어려울까요?

진정한 대답은 에 달려 있지만, 바라는 점이 몇 가지 있습니다.

이 질문에 대답하기 어렵다면.

정답은 다음과 같아야합니다.

REST로 보는 방법 :

1. 코드에서 객체를 만들어 REST 메소드를 호출합니다.
2. http 메소드 호출
3. REST API 내부의 코드는 데이터베이스를 쿼리합니다.
4. 데이터베이스가 일부 데이터를 반환
5. REST API 코드는 데이터를 Json으로 압축하여 클라이언트로 보냅니다.
6. 클라이언트가 Json / XML 응답을받습니다.
7. 코드에서 객체에 대한 응답 매핑

당신의 생각에 실수가 있습니다.

그리고이 실수는 REST와 그 원칙을 완전히 이해하지 못한다는 사실에서 비롯됩니다. REST는 발명되지 않았다. 왜냐하면 일부 괴상한 사람들은 유선으로 HTTP를 통해 Javascript 객체를 보내는 것이 시원하다는 것을 알았 기 때문이다. HTTP 사용의 주요 장점은 캐싱 을 사용할 수 있다는 것입니다 . 결과를 캐시 가능 하게 만들면 DB에 대한 요청이 줄어 듭니다. 그리고 마샬링 이 필요하지 않습니다 . 답변을 직접 전달할 수 있습니다.

@Klees의 답변이 옳지 않습니다 :

복잡성을 추가하면 코드가 느리게 실행됩니다. 필요하지 않은 REST 서비스를 도입하면 시스템이 더 많은 작업을 수행함에 따라 실행 속도가 느려집니다.

캐시 가능 결과를 처리 할 때는 애플리케이션에 영향을 미치지 않습니다. 알려진 질문에 대한 알려진 답변을 리버스 프록시를 통해 제공 할 수 있습니다.

추가 서비스 계층을 도입하면 항상 복잡성과 성능 오버 헤드 비용이 발생합니다. REST API와 같은 공유 서비스 계층을 도입하면 공유 캐싱으로 인해 성능이 향상 될 수있는 특정 종류의 아키텍처가 있지만 아키텍처의 종류가 아닌 것 같습니다.

동일한 데이터베이스에 직접 연결하는 여러 웹 앱 또는 여러 데스크톱 앱이있는 아키텍처를 고려하십시오. 동일한 쿼리를 자주 수행하면 공유 서비스에서 쿼리 결과를 캐시하는 성능이 향상 될 수 있습니다. 특히 웹 응용 프로그램을 통하지 않고 동일한 데이터베이스에 직접 액세스하고 동일한 쿼리를 수행하는 수백 개의 데스크톱 응용 프로그램을 말한 경우 크게 개선 될 수 있습니다. 그러나이 아키텍처에서도 공유 서비스를 도입하는 주된 이유는 성능보다는 보안 및 데이터 추상화 일 것입니다.

그러나 데이터베이스에 직접 연결하는 단일 웹 앱이있는 것처럼 들립니다. 이 경우 추가 서비스 계층을 도입해도 이점이 없습니다. 캐싱, 데이터베이스 추상화 등은 동일한 응용 프로그램의 데이터 액세스 계층에서 처리 될 수 있습니다.

때에 따라 다르지.

분명히 코드에 레이어가 많을수록 속도가 느려집니다. 그러나 ... 직접적인 엔드-투-엔드 성능이 확장 성만큼 중요하지 않은 지점이 있습니다. 로컬 PC에서 1 명의 사용자가 데이터베이스에 액세스하면 빠르게 진행될 수 있습니다. 동일한 PC에서 동일한 DB에 액세스하는 수천 명의 사용자가 있다면 모두 실망 할 것입니다. 해결책은 DB를 다른 상자로 옮기고 중간에 레이어를 추가하는 것입니다. 한 명의 사용자의 경우 속도가 느리지 만 수천 명의 사용자가 액세스하면 속도가 빨라집니다. (단순한 답변이지만 원칙적으로 사실입니다).

보안과 같은 미들 티어 계층 뒤에 DB를 숨기는 다른 이유가 있습니다.

어디에서 길을 잃었는지 모르겠지만, REST API를 사용할 때 추가 단계를 수행하고 있으며 추가 단계 "항상"은 프로그래밍과 관련된 경우 속도가 느리다는 것을 의미합니다.

장단점이 있지만 응용 프로그램에서 데이터베이스에 직접 액세스 할 수 있다면 웹 API 대신 데이터베이스를 직접 호출하는 것이 좋습니다. 물론 웹 API를 사용하면 응용 프로그램을 다른 플랫폼으로 쉽게 이식 할 수 있습니다.

쉬다 :

• 다중 프론트 엔드와 1 개의 백엔드에 개방
• 자신의 API를 생성하거나 Loopback과 같은 API를 사용해야합니다.
• 오프라인으로 작동하지 않습니다

로컬 DB :

• '계층'에 열리지 않으면 동기화하려면 백엔드에 액세스해야합니다.
• API를 만들 필요가 없으며 DB 인터페이스를 사용하십시오.
• 오프라인 작업

이것은 매우 큰 차이이며, 사람들은 종종 이러한 점을 잊어 버렸습니다.