사람들이 왜 DBAL 대신 REST API를 사용합니까?

지난 두 회사에서는 웹 앱을 통해 데이터를 쿼리하기 위해 REST API를 사용했습니다. 즉. 웹 앱이 SQL을 직접 수행하는 대신 REST API를 호출하여 SQL을 수행하고 결과를 리턴합니다.

내 질문은 ... 왜 이런 짓을합니까?

그것이 제 3 자에게 노출 될 예정이라면 이해할 수있었습니다. 전체 DB보다 제한된 REST API를 노출하는 것이 좋습니다. 그러나이 두 회사 모두 그렇지 않습니다.

이 REST API를 사용하면 DBMS 간을 쉽게 전환 할 수 있다고 제안되었습니다. 그러나 이것이 DBAL (데이터베이스 추상화 계층)의 요점이 아닌가? 어쩌면 ORM을 DBAL로 사용하거나 원시 SQL을 작성하고 DBAL이 DB 관련 내용을 적절하게 변환하도록 할 수 있습니다 (예 : LIMIT for MySQL을 TOP을 MSSQL로 변환).

어느 쪽이든 그것은 나에게 불필요 해 보인다. 그리고 그것이 문제 진단을 더 어렵게 만든다고 생각합니다. 웹앱에 대한 보고서가 잘못된 숫자를 제공하는 경우 SQL 쿼리를 덤프 할 수 없습니다. REST URL을 덤프 한 다음 REST API 역할을하는 프로젝트로 이동하여 SQL을 가져와야합니다. 따라서 진단 프로세스 속도를 저하시키는 추가 간접 계층입니다.

클라이언트가 데이터베이스 추상화 계층을 사용하더라도 데이터베이스에 직접 액세스하도록 허용하는 경우 다음을 수행하십시오.

• 코드와 코드 사이에 연결이 있습니다. 특히 데이터베이스 구조와 코드 사이에 매우 강한 연결이 있습니다.
• 클라이언트는 데이터베이스에서 바람직하지 않은 작업을 수행 할 수 있습니다. 데이터를 업데이트하지 않거나 너무 많은 시간이 걸리는 쿼리 작성, 잠금을 깨끗하게 얻지 못했기 때문에 교착 상태 발생 여부 등 ...
• 데이터베이스 구조에서 최적의 선택보다 덜한 선택을 한 경우, 특히 클라이언트를 새 구조로 마이그레이션 할 수있는 좋은 방법이없는 경우 해당 선택에서 벗어나는 것이 매우 어려울 수 있습니다.

즉, REST 부분을 전혀 다루지 않습니다. 데이터베이스를 유지 관리하는 팀과 데이터베이스를 사용하는 팀이 동기화되지 않은 경우 API 뒤에 데이터베이스를 격리하는 것이 더 합리적인 선택입니다. 자신의 속도로 진화합니다.

웹 애플리케이션과 데이터베이스 사이에 REST API 계층을 도입하면 확실한 이점이 없으며 복잡성과 성능 오버 헤드가 발생합니다.

모순되는 답변을 얻는 이유는 아키텍처에서 '클라이언트'가 무엇인지 혼동하기 때문입니다.

아키텍처에서 (올바로 이해하면) 단일 웹 앱과 상호 작용하는 브라우저가 있으며 데이터베이스와 상호 작용합니다. 웹앱과 데이터베이스 사이에 REST API 계층을 도입해도 아무런 이점이 없습니다. 명시된 모든 이점 (캐싱, 데이터베이스 격리 등)은 코드의 데이터 액세스 계층으로 달성 할 수 있습니다.

그러나 REST API가 적합한 다른 아키텍처가 있습니다.

• 데이터베이스에 액세스하는 클라이언트가 여러 개인 경우 (즉, 단일 웹 앱이 아니라 동일한 데이터베이스에 액세스하는 여러 독립 웹 앱) 데이터 모델, 캐싱 등을 공유 할 수 있도록 공통 REST 인터페이스를 작성하면 이점이있을 수 있습니다. 동일한 DAL 라이브러리를 공유하여 이점을 얻을 수 있지만 앱이 다른 언어로 개발되고 다른 언어로 개발 된 경우에는 작동하지 않습니다. 플랫폼. 이것은 엔터프라이즈 시스템에서 일반적입니다.

• 데이터베이스에 직접 액세스하는 여러 데스크톱 앱이있는 경우 이것은 고전적인 "2 계층"아키텍처로, 웹 앱에 비해 선호도가 떨어졌습니다. REST 계층을 도입하면 데이터 액세스 논리를 중앙 집중화 할 수 있으며 특히 여러 분산 클라이언트가 동일한 데이터베이스에 직접 액세스하는 것이 위험하므로 보안을보다 엄격하게 제어 할 수 있습니다.

• 서버에서 데이터를 직접 가져 오는 JavaScript 코드가 있으면 어떤 경우 든 REST API와 같은 것이 필요합니다.

경고 : 큰 게시물, 의견, 모호한 '당신에게 가장 잘 맞는 일'결론

일반적으로 이것은 데이터베이스 주위에 '육각 아키텍처'를 구현하는 수단으로 수행됩니다. 웹 응용 프로그램, 모바일 응용 프로그램, 데스크톱 응용 프로그램, 대량 가져 오기 및 백그라운드 처리가 모두 동일한 방식으로 데이터베이스를 사용하도록 할 수 있습니다. 데이터베이스에 액세스하기위한 리치 라이브러리를 작성하고 모든 프로세스가 해당 라이브러리를 사용하도록하여 동일한 범위를 어느 정도 달성 ​​할 수 있습니다. 그리고 만약 당신이 아주 간단한 시스템을 갖춘 작은 가게에 있다면 그것은 아마도 더 나은 길일 것입니다. 더 간단한 접근 방식이며 더 복잡한 시스템의 고급 기능이 필요하지 않은 경우 왜 복잡성을 지불해야합니까? 그러나 규모와 상관없이 데이터베이스와 상호 작용해야하는 크고 복잡한 시스템을 사용하는 경우

플랫폼 독립 및 유지 보수

데이터베이스가 있고 해당 데이터베이스와 상호 작용하기 위해 Python 라이브러리를 작성하고 모든 사람이 해당 라이브러리를 가져와 데이터베이스와 상호 작용하면 훌륭합니다. 그러나 갑자기 모바일 앱을 작성해야하며 이제 모바일 앱도 데이터베이스와 통신해야한다고 가정 해 봅시다. iOS 엔지니어는 Python을 사용하지 않으며 Android 엔지니어는 Python을 사용하지 않습니다. iOS 사용자는 Apple의 언어를 사용하고 Android 엔지니어는 Java를 사용하려고합니다. 그런 다음 3 가지 언어로 데이터 액세스 라이브러리를 작성하고 유지 관리해야합니다. iOS 및 Android 개발자는 Xamarin과 같은 것을 사용하여 공유 할 수있는 코드를 최대화하기로 결정할 수 있습니다. 아마도 여전히 데이터 액세스 라이브러리를 .NET으로 이식해야한다는 점을 제외하면 완벽합니다. 그리고 회사에서 방금 다른 회사를 구입했습니다. 웹 응용 프로그램은 별개이지만 관련 제품이며 비즈니스는 회사 플랫폼의 일부 데이터를 새로 인수 한 자회사 플랫폼에 통합하려고합니다. 한 가지 문제가 있습니다. 자회사는 신생 기업이었으며 대부분의 응용 프로그램을 다트에 작성하기로 결정했습니다. 또한 Xamarin을 조종하는 모바일 팀은 이유가 무엇이든 (아마도 당신이 통제 할 수없는 이유 때문에) 자신을위한 것이 아니라고 결정하고 개발하려는 모바일 장치에 특정한 도구와 언어를 사용하기로 결정했습니다. 그러나 그 단계에있는 동안 팀은 이미 .NET에서 데이터 액세스 라이브러리의 많은 부분을 제공했으며 회사의 다른 팀은 미친 Salesforce 통합 작업을 작성하고 .NET에서 모든 작업을 수행하기로 결정했습니다. 의 데이터 액세스 라이브러리였습니다.

이제 매우 현실적인 이벤트 전환으로 인해 Python, .NET, Swift, Java 및 Dart로 작성된 데이터 액세스 라이브러리가 있습니다. 그들은 당신이 원하는만큼 좋지 않습니다. 언어마다 ORM 도구가 다르기 때문에 원하는만큼 더 많은 코드를 작성해야했기 때문에 원하는만큼 효과적으로 ORM을 사용할 수 없었습니다. 그리고 당신은 그들이 원하는대로 각 화신에 많은 시간을 할애 할 수 없었습니다. 그들 중 5 명이 있기 때문입니다. 그리고 라이브러리의 Dart 버전은 특히 털이 많기 때문에 라이브러리와 지원이 실제로 없기 때문에 일부는 자신의 트랜잭션을 롤업해야했기 때문에 특히 털이 있습니다. 이 때문에 Dart 응용 프로그램에는 데이터베이스에 대한 읽기 전용 기능 만 있어야한다고 주장했습니다. 그러나 비즈니스는 이미 계획중인 기능이 추가 노력의 가치가 있다고 생각했습니다. 그리고 데이터 액세스 라이브러리의 모든 화신에 존재하는 일부 유효성 검사 논리에 버그가 있음이 밝혀졌습니다. 이제 모든 라이브러리에서이 버그를 수정하기 위해 테스트와 코드를 작성하고, 모든 라이브러리에 대한 변경 사항에 대한 코드 검토를 받고, 모든 라이브러리에서 QA를 받고, 모든 시스템을 사용하여 모든 시스템에 대한 변경 사항을 릴리스해야합니다. 이 라이브러리들. 한편, 고객은 회사의 주력 제품을 대상으로 한 것이 아니라 상상조차 할 수 없었던 취약성의 조합을 모아서 불쾌감을 느끼고 Twitter로 가져 왔습니다. 그리고 제품 소유자는 상황에 대해 전혀 이해하지 않기로 결정합니다.

일부 환경에서는 위의 예가 고려되지 않은 것임을 이해하십시오. 또한 이러한 일련의 사건은 몇 년 동안 전개 될 수 있다는 점을 고려하십시오. 일반적으로 아키텍트와 비즈니스 사람들이 다른 시스템을 데이터베이스에 연결하는 것에 대해 이야기하기 시작하면 로드맵에 '데이터베이스 앞에 REST API를 배치'하려고합니다. 초기에이 데이터베이스가 몇몇 시스템에서 공유되기 시작한 것이 확실 할 때 웹 서비스 / REST API가 그 앞에 놓였다는 것을 고려하십시오. 유효성 검사 버그를 수정하는 것은 5 회 대신 한 번 수행하기 때문에 훨씬 빠르고 쉽습니다. 수정 프로그램을 해제하면 조정하기가 훨씬 쉬워집니다.

TLDR; 데이터 액세스 논리를 중앙 집중화하고 매우 얇은 HTTP 클라이언트를 유지 관리하는 것이 데이터 액세스 논리를 데이터에 액세스해야하는 각 응용 프로그램에 배포하는 것보다 쉽습니다. 실제로 HTTP 클라이언트는 메타 데이터에서 생성 될 수도 있습니다. 대규모 시스템에서 REST API를 사용하면 더 적은 코드를 유지할 수 있습니다

성능 및 확장 성

어떤 사람들은 먼저 웹 서비스를 거치지 않고 데이터베이스와 직접 대화하는 것이 더 빠르다고 생각할 수 있습니다. 응용 프로그램이 하나 뿐인 경우에도 마찬가지입니다. 그러나 더 큰 시스템에서는 감정에 동의하지 않습니다. 결국, 어느 정도의 규모에서 데이터베이스 앞에 일종의 캐시를 두는 것이 매우 유리할 것입니다. 아마도 최대 절전 모드를 사용 중이고 Infinispan 그리드를 L2 캐시로 설치하려고합니다. 응용 프로그램과 별도로 웹 서비스를 호스팅하기 위해 4 개의 강력한 서버 클러스터가있는 경우 동기식 복제를 설정 한 내장 토폴로지를 사용할 수 있습니다. 30 개의 응용 프로그램 서버 클러스터에이를 저장하려고하면 해당 설정에서 복제를 설정하는 오버 헤드가 너무 높아 지므로 분산 모드 또는 특정 종류의 전용 토폴로지에서 Infinispan을 실행해야하며 캐시에서 읽으려면 갑자기 최대 절전 모드가 네트워크를 통해 나가야합니다. 또한 Infinispan은 Java에서만 작동합니다. 다른 언어가있는 경우 다른 캐싱 솔루션이 필요합니다. 데이터베이스에 도달하기 전에 애플리케이션에서 웹 서비스로 이동해야하는 네트워크 오버 헤드는 일반적으로 자체 오버 헤드와 함께 제공되는 훨씬 더 복잡한 캐싱 솔루션의 필요성으로 인해 상쇄됩니다.

또한 REST API의 해당 HTTP 계층은 또 다른 유용한 캐싱 메커니즘을 제공합니다. REST API 용 서버는 응답에 캐싱 헤더를 넣을 수 있으며 이러한 응답은 네트워크 계층에서 캐싱 될 수 있으며 예외적으로 확장 성이 뛰어납니다. 하나 또는 두 개의 서버가있는 소규모 설정에서 가장 좋은 방법은 데이터베이스와 통신 할 때 응용 프로그램에서 인 메모리 캐시를 사용하는 것이지만, 많은 서버에서 많은 응용 프로그램이 실행되는 대형 플랫폼에서는 제대로 구성하면 오징어 나 니스 또는 nginx와 같은 것이 상대적으로 작은 하드웨어에서 미친 수준으로 확장 될 수 있기 때문에 캐싱을 처리 할 수 ​​있습니다. 초당 수십만 또는 수백만 건의 처리량이 애플리케이션 서버 나 데이터베이스보다 HTTP 캐시에서 처리하는 것이 훨씬 저렴합니다.

게다가, 많은 클라이언트가 데이터베이스를 가리키게하는 대신 몇 개의 서버를 가리키게하는 대신 데이터베이스를 가리키면 데이터베이스 튜닝 및 연결 풀링이 훨씬 더 어려워 질 수 있습니다. 일반적으로 응용 프로그램 서버의 실제 작업량은 대부분 응용 프로그램입니다. 데이터베이스에서 데이터가 되돌아 오기를 기다리는 것은 종종 시간이 걸리지 만 일반적으로 계산 비용이 많이 들지 않습니다. 애플리케이션의 워크로드를 처리하기 위해 40 대의 서버가 필요할 수 있지만 데이터베이스에서 데이터 페치를 조정하기 위해 40 대의 서버가 필요하지 않을 수 있습니다. 해당 작업을 웹 서비스 전용으로 사용하는 경우 웹 서비스가 나머지 응용 프로그램보다 훨씬 적은 서버에서 실행되므로 데이터베이스에 대한 연결이 훨씬 적어야합니다. 데이터베이스는 일반적으로

TLDR; 하나의 전용 웹 서비스 내에서 발생하는 일이 다른 언어와 기술을 사용하여 여러 다른 애플리케이션에서 발생하는 일보다 데이터 액세스를 조정, 확장 및 캐시하는 것이 더 쉽습니다.

마지막 생각들

이 생각에서 멀리 오지 마십시오 "오 와우, 난 항상 내 데이터를 얻을 수 REST API를 사용한다" 또는 이 바보는 우리가 데이터베이스에 우리의 웹 응용 프로그램 회담 때문에 직접 잘못을하고있는 말을하려고 "하지만, 우리 물건은 잘 작동합니다! " . 내가 만들고자하는 주요 포인트는 시스템과 비즈니스마다 요구 사항이 다르다는 것입니다. 대부분의 경우 REST API를 데이터베이스 앞에 두는 것은 실제로 의미가 없습니다. 복잡성을 정당화해야하는보다 복잡한 아키텍처입니다. 그러나 복잡성이 보장되면 REST API를 사용하면 많은 이점이 있습니다. 서로 다른 우려를 측정하고 시스템에 적합한 접근 방식을 선택할 수 있다는 것은 훌륭한 엔지니어입니다.

또한 REST API가 디버깅하는 데 방해가되면 해당 그림에 문제가 있거나 누락되었을 수 있습니다. 추상화 계층을 추가하면 본질적으로 디버깅이 어려워집니다. 대규모의 n- 계층 시스템으로 작업 할 때 분산 로깅 컨텍스트가 있는지 확인하고 싶습니다. 사용자가 요청을 시작할 때 해당 요청에 대한 GUID를 생성하고 해당 사용자의 사용자 이름과 요청을 기록하십시오. 그런 다음 응용 프로그램이 다른 시스템과 통신 할 때 해당 GUID를 전달하십시오. 적절한 로그 집계 및 인덱싱을 사용하면 문제를보고하는 사용자를 위해 전체 플랫폼을 쿼리하고 모든 작업을 볼 수 있으며 시스템을 통해 문제가 발생한 위치를 신속하게 파악할 수 있습니다. 다시 한 번 더 복잡한 아키텍처입니다.

출처 : http://alistair.cockburn.us/Hexagonal+architecture https://github.com/brettwooldridge/HikariCP/wiki/About-Pool-Sizing

DBAL이 무엇인지 올바르게 이해 하면 REST 인터페이스를 사용 하여 클라이언트에 모든 언어 를 사용할 수 있으며 DBAL은 클라이언트에 단일 언어 를 사용할 수있는 라이브러리입니다 .

이는 개발 팀이 많고 모두 같은 언어에 능숙하지 않은 회사에 유리할 수 있습니다. 소프트웨어가 DB를 직접 쿼리하도록 허용하는 것은 기능면에서 동일하지만 "전체 DB보다 제한된 REST API를 노출하는 것이 좋습니다"라고 말하면됩니다.

더 추상적 인 용어로, 당신은 스스로 질문에 대답하고 있습니다.

따라서 진단 프로세스 속도를 늦추는 추가 간접 계층입니다.

...이 유명한 격언 이 있기 때문에 : "컴퓨터 과학의 모든 문제는 다른 수준의 간접적 인 방법으로 해결할 수 있습니다". :)

같은 회사에 있다고해서 모든 사람에게 모든 것을 공개해야한다는 의미는 아닙니다. REST API는 명확한 계약으로 회사의 팀간에 제한된 소비자 / 제공자 관계를 정의하는 방법입니다. 아마존은 이러한 형태의 조직에서 선구자였습니다 .

API는 또한 추상화 계층을 제공하므로 특정 관용구 세트를 사용할 수 있습니다. 데이터베이스에서 사용되는 것과 동일한 용어로 소비자와 반드시 대화하고 싶지는 않습니다. 또한 각 소비자에게 반드시 같은 방식으로 이야기하고 싶지는 않습니다.

REST는 데이터베이스 쿼리 용이며 그렇지 않다고 생각합니다. REST는 현재 무언가의 상태를 나타냅니다. REST를 사용하면 표현을 변경하거나 검색하지만 그게 전부입니다. 해당 상태가 데이터베이스에서 사용 가능 해지면 문제가되지 않으며 그 표현이 REST의 일부가 아니며 데이터베이스 쿼리도 아니기 때문에 아무도 신경 쓰지 않습니다.