GraphQL은 뜨겁게 피어오르는 쓰레기 더미입니다.

나는 대부분의 내 기사에 대해 이의를 제기하는 것과 같은 방식으로 이 글에 대해 이의를 제기할 것입니다. 나를 믿지 않는다면 내 . 190개 이상의 댓글, 대부분은 내가 미친 놈이라고 주장하려고 합니다. 그러나 미신은 얼마나 많은 사람들이 그것이 진실이라고 믿는지에 관계없이 여전히 미신이며 GraphQL은 뜨거운 쓰레기 더미입니다.

우선, GraphQL은 프런트엔드 클라이언트가 SQL을 데이터베이스로 보낼 수 있도록 허용하는 것과 거의 같습니다. 큰 소리로 외치는 것에 대한 이름이 있으며 이를 SQL INJECTION ATTACKS라고 합니다. 의심스러운 경우 Google에 문의하십시오. 기능의 절반을 절단하여 GraphQL 끝점에 보안을 적용할 수 있다는 것을 알고 있습니다. 그러나 보안은 기본적으로 필요한 것 중 하나입니다. 일부 기술에 "기본 보안"이 없는 경우 서버 인프라에 대한 루트 액세스 권한이 없는 누구에게도 노출되지 않습니다.

두 번째로 GraphQL은 클라이언트에서 비즈니스 로직을 작성하도록 합니다. 이것은 Postman 계정이 있는 모든 사람이 비즈니스 논리를 우회하고 잠재적으로 은행 계좌를 비우고 버뮤다에서 자신의 계정으로 전체 보유를 이체하는 동시에 해먹에서 우산 음료를 마시고 있는 Instagram의 이미지를 공개적으로 공유할 수 있음을 의미합니다. 해변가에서.

GraphQL이 쓰레기인 이유를 몇 시간 동안 더 설명할 수 있지만 실제로는 위의 두 가지 사항으로 충분해야 합니다. "취미 프로젝트"및/또는 시스템 관리자 유형의 앱보다 훨씬 더 복잡한 것에 GraphQL을 사용하는 경우 다음과 같은 경고 표시를 해야 합니다.

I have no idea about anything related to software development

왜냐하면 실제로 GraphQL이 잘하는 것은 그것뿐이기 때문입니다. 내 제안은 우리가 GraphQL을 "이름 변경"하고 실제로 다음과 같이 참조하는 것입니다.

JSON based SQL insertion attacks

GraphQL 엔드포인트를 보호하는 것은 서버의 비즈니스 로직과 서버의 유효성 검사 및 보안을 통해 실제 소프트웨어 개발 솔루션을 구현하는 것과 마찬가지로 어려울 수 있습니다. GraphQL 엔드포인트를 자신 및/또는 앱의 시스템 관리자를 제외한 모든 사람에게 노출하는 것은 웹 사이트의 공개 부분에 자리 표시자가 있는 텍스트 영역을 제공하는 것보다 약간 더 안전할 것입니다. "여기에 SQL을 제공하십시오 ...". 이해가 되지 않으면 코드에 입력해 보겠습니다.

<textarea placeholder="Insert SQL here ..."></textarea>
<button (onclick)="executeSql()"></button>

Aista에서 GraphQL을 수행하지 않고 대신 Hyperlambda에서 우리의 작업을 구현하는 이유가 있습니다. 그 이유는 JSON 기반 SQL 삽입 공격을 좋아하지 않기 때문입니다.

GraphQL is a hot smoking pile of garbage, period!