동기화의 경계 설계하기
작은 팀의 집중력은 한정되어 있습니다. 네트워크 대화를 조정하는 시간만큼 가져오기 실패를 설명하거나 메시지 가독성을 높일 시간이 줄어듭니다. JMAP은 로컬 모델과 사서함 서비스 사이에 일관된 경계를 제시합니다. 장점은 아키텍처의 명확함이지 이메일이 저절로 쉬워진다는 약속이 아닙니다.
기반은 2019년에 발표된 RFC 8620입니다. 같은 해 발표된 RFC 8621은 이메일 객체, 사서함, 스레드와 클라이언트의 전송 제출을 정의합니다. 독점 API를 역으로 추측하는 대신 명확한 데이터 모델을 제공하는 공개 표준입니다.
요청 순서 대신 필요한 작업 표현하기
JMAP은 HTTPS로 JSON을 교환합니다. 요청 하나에 여러 메서드 호출을 넣고, 뒤의 호출에서 앞선 결과를 참조할 수 있습니다. 받은편지함 화면이라면 쿼리와 결과 식별자에 해당하는 데이터 조회를 함께 기술할 수 있습니다. 서버가 알린 제한은 따라야 합니다. 종속된 네트워크 왕복이 줄면 지연이 큰 연결에서 도움이 될 수 있지만 실제 결과는 작업과 구현에 달려 있습니다.
개발자는 의존 관계를 명시할 수 있습니다. 화면에 어떤 속성이 필요한지, 어떤 결과가 다음 작업에 쓰이는지 표현합니다. 그래도 페이지 나누기, 오류 처리와 작업량 제한은 필요합니다. 일괄 호출은 요청을 정리하는 도구이지 창을 열 때마다 계정 전체를 내려받을 근거가 아닙니다.
상태를 영속적인 체크포인트로 다루기
상태 토큰으로 알려진 시점 이후의 변경을 요청합니다. /changes는 생성, 수정, 삭제된 식별자를 알리고 클라이언트는 필요한 데이터를 가져와 로컬 저장소를 갱신합니다. 푸시는 상태 변경을 알려 동기화의 계기를 제공합니다. 실제 상태 조정을 대신하지는 않습니다.
체크포인트는 실제로 영속 저장된 데이터와 일치해야 합니다. 응답을 받은 뒤 저장하기 전에 충돌하는 경우도 설계해야 합니다. 서버가 요청한 변경 이력을 계산할 수 없으면 cannotCalculateChanges를 반환하며, 더 넓은 재동기화가 필요합니다. 오랫동안 접속하지 않은 뒤의 복구도 정상 동작의 일부입니다.
남은 책임을 분명히 하기
JMAP은 서버 사이의 SMTP 전달을 대체하지 않습니다. 클라이언트의 전송 제출과 메일망의 전달은 다른 작업입니다. 스팸이나 종단 간 프라이버시를 자동으로 해결하거나 오프라인 앱을 만들어 주지도 않습니다. 로컬 저장, 대기 중인 동작의 규칙과 충돌 처리는 여전히 필요합니다.
지원은 보편적이지 않습니다. 기능을 탐지하고 지원할 서비스를 정하며 필요한 호환 경로를 유지해야 합니다. 성능은 서버, 클라이언트와 작업에 따라 달라집니다. 현대 IMAP에도 동기화 기능이 있으므로 단순한 신구 비교는 부족합니다.
스튜디오의 교훈은 복구를 이해할 수 있게 만드는 계약을 고르는 것입니다. 이메일 앱을 만들기 어려운 이유: 스튜디오가 보는 50년의 호환성 는 물려받은 제약을, JMAP이 이메일을 현대화하는 방법 는 사용자 관점을 설명합니다. 명확한 서버 통신은 더 좋은 앱을 만들 여유를 주지만 실제로 구현할 책임은 팀에 남습니다.