#30일 애플리케이션 쓰기: 서버측 SDK
간단한 소개
Appwrite는 SDK와 API를 통해 응용 프로그램 개발을 가속화하고 응용 프로그램 개발을 더욱 쉽게 하는 원천적이고 위탁 관리된 백엔드 서비스이다.#30DaysOfAppwrite는 한 달 동안 진행되는 행사로 개발자에게 앱 write의 모든 기능, 기초 기능부터 클라우드 기능 등 고급 기능을 이해하도록 하기 위한 것이다!그 밖에 우리는 이러한 개념을 실제 세계의 응용 프로그램을 구축할 때 어떻게 응용하는지 보여주는 기능이 완비된 미디어 복제도 구축할 것이다.우리는 또한 우리 개발자를 따르기 위해 감동적인 보상을 제공했다.
서버측 SDK
일곱 번째 날에 오신 걸 환영합니다.👋 . 오늘 AppwriteServer Side SDKs를 살펴보고 클라이언트와 서버 SDK 간의 차이에 대해 토론하겠습니다.많은 개발자들에게 클라이언트 SDK와 서버 측 SDK 간의 차이는 신비로운 것 같아서 이 안내서는 그 중의 일부 곤혹스러움을 밝히는 데 목적을 두고 있다.
Appwrite의 바람은 이러한 사실을 강조했다. 백엔드 즉 서비스는 전방 개발자만을 위해 설계해서는 안 된다는 것이다.이러한 바람을 바탕으로 Appwrite는 플랫폼과 무관하게 설계되었고 클라이언트와 서버 측 응용 프로그램과 틈새 없이 통합되었다.Appwrite는 자체 관리되기 때문에 기존 방화벽 뒤에서 사용할 수 있고 기존 백엔드 서비스와 함께 작업할 수 있습니다.Appwrite의 목표는 백엔드를 대체하는 것이 아니라 함께 작업하는 것입니다.
Appwrite는 6개의 서버측 SDK를 공식적으로 지원하며 추가 지원을 제공합니다.만약 당신이 아직 모른다면, 우리의 모든 SDK는 API의 과장된 규범에 따라 자동으로 생성된 것이다.이를 통해 Dell 소규모 팀은 총 8개의 SDK(클라이언트 + 서버)를 유지 관리할 수 있습니다.우리는 단지❤️ PRs!원하는 언어로 SDK를 만들 수 있도록 도와주시려면SDK Generator 언제든지 확인하십시오.
🤔 그것들은 무엇이 다릅니까?
인증
클라이언트 SDK와 서버 측 SDK 사이의 관건적인 차이점은 인증 메커니즘에 있다.서버 측 SDK는 역할 영역 API 키를 사용하여 Appwrite API에 액세스하고 클라이언트 SDK는 보안 쿠키에 의존하여 인증합니다.
범위
두 번째 주요 차이점은 클라이언트와 서버측 SDK가 접근할 수 있는 범위다.SDK를 통해 수행할 수 있는 작업의 종류를 제한합니다.서버 측 SDK는 더욱 강력한 기능과 유연성을 제공하며, Appwrite의 더 많은 부분을 제어할 수 있습니다.API 키를 사용하면 자신이 선택한 SDK를 사용하여 Appwrite 서비스에 액세스할 수 있습니다.
새 API 키를 만들려면 Appwrite 콘솔을 사용하여 프로젝트 설정의 API 키 탭으로 이동한 다음 "API 키 추가"버튼을 클릭합니다.새 API 키를 추가할 때 응용 프로그램에 부여할 역할 영역을 선택할 수 있습니다.가장 좋은 방법은 프로젝트 목표를 충족시키는 데 필요한 권한만 허용하는 것이다.API 키를 교체해야 하는 경우 새 키를 만들고 애플리케이션 자격 증명을 업데이트한 다음 준비가 완료되면 이전 키를 삭제합니다.
서버에서 API 키가 있는 Appwrite API를 사용하면 admin mode
에서 자동으로 실행됩니다.관리 모드에서는 기본값user permission access control 제한을 비활성화하고 프로젝트의 모든 서버 리소스(문서, 사용자, 컬렉션, 파일, 팀)에 액세스할 수 있으며 읽기 및 쓰기 권한을 고려하지 않습니다.파일이나 문서 같은 사용자의 데이터를 처리하거나 사용자 목록을 얻으려면 매우 유용하다.
It is not recommended to run admin mode from a client as it will lead to huge privacy and security risks. Check the Admin Mode documentation to learn more.
다음 표는 클라이언트와 서버 측의 SDK가 할 수 있는 일과 할 수 없는 일을 잘 보여주고 우리가 토론한 내용을 잘 정리했다.
성함
묘사
서버
손님: 네.
해석하다
현재 로그인한 사용자의 읽기와 쓰기 권한을 나타냅니다.
❌
✅
사용자읽다
항목 사용자의 권한 읽기
✅
❌
사용자쓰다
항목 사용자 작성, 업데이트 및 삭제 권한
✅
❌
단체.읽다
프로젝트 팀 읽기 권한
✅
✅
단체.쓰다
프로젝트 팀 작성, 업데이트 및 삭제 권한
✅
✅
수장하다.읽다
항목 데이터베이스 컬렉션 읽기 권한
✅
❌
수장하다.쓰다
프로젝트 데이터베이스 집합의 창설, 업데이트 및 삭제 권한
✅
❌
서류읽다
항목 데이터베이스 문서 읽기 권한
✅
✅
서류쓰다
항목 데이터베이스 문서 작성, 업데이트 및 삭제 권한
✅
✅
서류철.읽다
항목에 저장된 파일 읽기 및 이미지 미리 보기 권한
✅
✅
서류철.쓰다
항목 저장 파일 생성, 업데이트 및 삭제 권한
✅
✅
기능읽다
항목의 기능 및 코드 레이블을 읽을 수 있습니다.
✅
❌
기능쓰다
항목 생성, 업데이트 및 삭제 기능 및 코드 태그
✅
❌
집행하다.읽다
프로젝트 실행 로그 읽기 권한
✅
✅
집행하다.쓰다
항목 기능 실행 권한
✅
✅
지점읽다
항목에 대한 로케일 서비스 액세스
✅
✅
화신읽다
프로젝트의 아바타 서비스 액세스
✅
✅
건강읽다
항목 상태 읽기 권한
✅
❌
개시하다
서버측 SDK를 사용하기 시작하고 첫 번째 요청을 하는 것은 매우 간단합니다.이 예에서 우리는 Node SDK를 선택할 것이다. 같은 원칙은 모든 다른 SDK에도 적용된다.
첫 번째 단계는 노드 프로젝트를 만들고 설치node-appwrite
패키지입니다.
$ mkdir getting-started
$ cd getting-started
$ npm init -y
$ npm install node-appwrite --save
다음 단계에서는 Appwrite 대시보드로 이동하여 새 항목을 만듭니다.항목의 이름을 지정하고 '만들기' 를 누르면 시작합니다.프로젝트를 만든 후 API 키 섹션으로 이동하여 필요한 역할 영역이 있는 키users.read
와 users.write
역할 영역이 있는지 확인합니다. 예제가 이에 의존하기 때문입니다.이 열쇠를 복사해라. 왜냐하면 우리는 다음 단계에 그것을 필요로 하기 때문이다.또한 Appwrite 대시보드의 설정 섹션에서 사용할 수 있는 항목 ID와 API 끝점도 고려해야 합니다.
SDK를 초기화하고 첫 번째 요청을 할 때입니다.이전 단계에서 복사한 모든 값을 기입하십시오.그런 다음 Appwrite SDK를 사용하여 사용자를 만들려고 합니다.
const sdk = require('node-appwrite');
let client = new sdk.Client();
client
.setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your API Endpoint
.setProject('5df5acd0d48c2') // Your project ID
.setKey('919c2d18fb5d4...a2ae413da83346ad2') // Your secret key
;
let users = new sdk.Users(client);
let promise = users.create('[email protected]', 'password');
promise.then(function (response) {
console.log(response);
}, function (error) {
console.log(error);
});
여기 있습니다!Appwrite의 서버 측 SDK 요청은 이번이 처음입니다!만약 우리가 지원하는 다른 언어에서 이 예를 보고 싶다면, 그것들을 볼 수 있다. here
모험심이 있고 당신이 가장 좋아하는 HTTP 요청 라이브러리를 사용해서 Appwrite API를 사용하고 싶다면 이 책은 바로 이 목적을 위해 쓴 것입니다!
크레디트
우리는 네가 이 문장을 좋아하길 바란다.너는 소셜 미디어에서 우리의 모든 댓글을 주목할 수 있다.전체 활동 일정here을 찾을 수 있습니다.
일곱 번째 날에 오신 걸 환영합니다.👋 . 오늘 AppwriteServer Side SDKs를 살펴보고 클라이언트와 서버 SDK 간의 차이에 대해 토론하겠습니다.많은 개발자들에게 클라이언트 SDK와 서버 측 SDK 간의 차이는 신비로운 것 같아서 이 안내서는 그 중의 일부 곤혹스러움을 밝히는 데 목적을 두고 있다.
Appwrite의 바람은 이러한 사실을 강조했다. 백엔드 즉 서비스는 전방 개발자만을 위해 설계해서는 안 된다는 것이다.이러한 바람을 바탕으로 Appwrite는 플랫폼과 무관하게 설계되었고 클라이언트와 서버 측 응용 프로그램과 틈새 없이 통합되었다.Appwrite는 자체 관리되기 때문에 기존 방화벽 뒤에서 사용할 수 있고 기존 백엔드 서비스와 함께 작업할 수 있습니다.Appwrite의 목표는 백엔드를 대체하는 것이 아니라 함께 작업하는 것입니다.
Appwrite는 6개의 서버측 SDK를 공식적으로 지원하며 추가 지원을 제공합니다.만약 당신이 아직 모른다면, 우리의 모든 SDK는 API의 과장된 규범에 따라 자동으로 생성된 것이다.이를 통해 Dell 소규모 팀은 총 8개의 SDK(클라이언트 + 서버)를 유지 관리할 수 있습니다.우리는 단지❤️ PRs!원하는 언어로 SDK를 만들 수 있도록 도와주시려면SDK Generator 언제든지 확인하십시오.
🤔 그것들은 무엇이 다릅니까?
인증
클라이언트 SDK와 서버 측 SDK 사이의 관건적인 차이점은 인증 메커니즘에 있다.서버 측 SDK는 역할 영역 API 키를 사용하여 Appwrite API에 액세스하고 클라이언트 SDK는 보안 쿠키에 의존하여 인증합니다.
범위
두 번째 주요 차이점은 클라이언트와 서버측 SDK가 접근할 수 있는 범위다.SDK를 통해 수행할 수 있는 작업의 종류를 제한합니다.서버 측 SDK는 더욱 강력한 기능과 유연성을 제공하며, Appwrite의 더 많은 부분을 제어할 수 있습니다.API 키를 사용하면 자신이 선택한 SDK를 사용하여 Appwrite 서비스에 액세스할 수 있습니다.
새 API 키를 만들려면 Appwrite 콘솔을 사용하여 프로젝트 설정의 API 키 탭으로 이동한 다음 "API 키 추가"버튼을 클릭합니다.새 API 키를 추가할 때 응용 프로그램에 부여할 역할 영역을 선택할 수 있습니다.가장 좋은 방법은 프로젝트 목표를 충족시키는 데 필요한 권한만 허용하는 것이다.API 키를 교체해야 하는 경우 새 키를 만들고 애플리케이션 자격 증명을 업데이트한 다음 준비가 완료되면 이전 키를 삭제합니다.
서버에서 API 키가 있는 Appwrite API를 사용하면
admin mode
에서 자동으로 실행됩니다.관리 모드에서는 기본값user permission access control 제한을 비활성화하고 프로젝트의 모든 서버 리소스(문서, 사용자, 컬렉션, 파일, 팀)에 액세스할 수 있으며 읽기 및 쓰기 권한을 고려하지 않습니다.파일이나 문서 같은 사용자의 데이터를 처리하거나 사용자 목록을 얻으려면 매우 유용하다.It is not recommended to run admin mode from a client as it will lead to huge privacy and security risks. Check the Admin Mode documentation to learn more.
다음 표는 클라이언트와 서버 측의 SDK가 할 수 있는 일과 할 수 없는 일을 잘 보여주고 우리가 토론한 내용을 잘 정리했다.
성함
묘사
서버
손님: 네.
해석하다
현재 로그인한 사용자의 읽기와 쓰기 권한을 나타냅니다.
❌
✅
사용자읽다
항목 사용자의 권한 읽기
✅
❌
사용자쓰다
항목 사용자 작성, 업데이트 및 삭제 권한
✅
❌
단체.읽다
프로젝트 팀 읽기 권한
✅
✅
단체.쓰다
프로젝트 팀 작성, 업데이트 및 삭제 권한
✅
✅
수장하다.읽다
항목 데이터베이스 컬렉션 읽기 권한
✅
❌
수장하다.쓰다
프로젝트 데이터베이스 집합의 창설, 업데이트 및 삭제 권한
✅
❌
서류읽다
항목 데이터베이스 문서 읽기 권한
✅
✅
서류쓰다
항목 데이터베이스 문서 작성, 업데이트 및 삭제 권한
✅
✅
서류철.읽다
항목에 저장된 파일 읽기 및 이미지 미리 보기 권한
✅
✅
서류철.쓰다
항목 저장 파일 생성, 업데이트 및 삭제 권한
✅
✅
기능읽다
항목의 기능 및 코드 레이블을 읽을 수 있습니다.
✅
❌
기능쓰다
항목 생성, 업데이트 및 삭제 기능 및 코드 태그
✅
❌
집행하다.읽다
프로젝트 실행 로그 읽기 권한
✅
✅
집행하다.쓰다
항목 기능 실행 권한
✅
✅
지점읽다
항목에 대한 로케일 서비스 액세스
✅
✅
화신읽다
프로젝트의 아바타 서비스 액세스
✅
✅
건강읽다
항목 상태 읽기 권한
✅
❌
개시하다
서버측 SDK를 사용하기 시작하고 첫 번째 요청을 하는 것은 매우 간단합니다.이 예에서 우리는 Node SDK를 선택할 것이다. 같은 원칙은 모든 다른 SDK에도 적용된다.
첫 번째 단계는 노드 프로젝트를 만들고 설치
node-appwrite
패키지입니다.$ mkdir getting-started
$ cd getting-started
$ npm init -y
$ npm install node-appwrite --save
다음 단계에서는 Appwrite 대시보드로 이동하여 새 항목을 만듭니다.항목의 이름을 지정하고 '만들기' 를 누르면 시작합니다.프로젝트를 만든 후 API 키 섹션으로 이동하여 필요한 역할 영역이 있는 키users.read
와 users.write
역할 영역이 있는지 확인합니다. 예제가 이에 의존하기 때문입니다.이 열쇠를 복사해라. 왜냐하면 우리는 다음 단계에 그것을 필요로 하기 때문이다.또한 Appwrite 대시보드의 설정 섹션에서 사용할 수 있는 항목 ID와 API 끝점도 고려해야 합니다.SDK를 초기화하고 첫 번째 요청을 할 때입니다.이전 단계에서 복사한 모든 값을 기입하십시오.그런 다음 Appwrite SDK를 사용하여 사용자를 만들려고 합니다.
const sdk = require('node-appwrite');
let client = new sdk.Client();
client
.setEndpoint('https://[HOSTNAME_OR_IP]/v1') // Your API Endpoint
.setProject('5df5acd0d48c2') // Your project ID
.setKey('919c2d18fb5d4...a2ae413da83346ad2') // Your secret key
;
let users = new sdk.Users(client);
let promise = users.create('[email protected]', 'password');
promise.then(function (response) {
console.log(response);
}, function (error) {
console.log(error);
});
여기 있습니다!Appwrite의 서버 측 SDK 요청은 이번이 처음입니다!만약 우리가 지원하는 다른 언어에서 이 예를 보고 싶다면, 그것들을 볼 수 있다. here모험심이 있고 당신이 가장 좋아하는 HTTP 요청 라이브러리를 사용해서 Appwrite API를 사용하고 싶다면 이 책은 바로 이 목적을 위해 쓴 것입니다!
크레디트
우리는 네가 이 문장을 좋아하길 바란다.너는 소셜 미디어에서 우리의 모든 댓글을 주목할 수 있다.전체 활동 일정here을 찾을 수 있습니다.
Appwrite Homepage
Reference
이 문제에 관하여(#30일 애플리케이션 쓰기: 서버측 SDK), 우리는 이곳에서 더 많은 자료를 발견하고 링크를 클릭하여 보았다 https://dev.to/appwrite/30daysofappwrite-server-side-sdks-24di텍스트를 자유롭게 공유하거나 복사할 수 있습니다.하지만 이 문서의 URL은 참조 URL로 남겨 두십시오.
우수한 개발자 콘텐츠 발견에 전념 (Collection and Share based on the CC Protocol.)