가이드

내 앱의 데이터는 어디에 있나요

프로젝트마다 자기 자리가 있고, 다른 앱에서는 보이지 않습니다.

짧게 답하면예약·주문·회원 같은 정보는 그 프로젝트만의 자리에 쌓입니다. 다른 프로젝트에서 그 자리를 들여다볼 수 없습니다.

프로젝트끼리 자리를 나눠 씁니다

프로젝트마다 자기 표를 갖습니다. 옆 프로젝트의 데이터로 건너갈 길 자체가 없어서, 실수로도 넘어가지 않습니다. 가게를 두 개 하시면서 앱을 따로 만드셨다면 두 앱의 손님 명단도 따로 있습니다.

표를 통째로 열어 두지 않습니다. 줄마다 주인이 있고, 로그인한 사람은 자기 줄만 읽습니다. 이게 빠지면 주소만 알아도 남의 예약이 보입니다. 그래서 게시 전 검사에서 이 부분을 따로 봅니다.

갤러리에 올라간 앱들에 손님 열쇠로 실제 요청을 넣어 봤습니다. 표 653개에서 새는 곳은 없었습니다. 코드를 읽고 괜찮겠거니 한 것이 아니라, 문을 실제로 열어 본 결과입니다.

열쇠나 비밀번호를 브라우저에 저장하는 코드가 있으면 검사에서 걸립니다. 그런 것은 서버 쪽에만 둡니다. 손님에게 내려가는 파일에 열쇠가 섞이면 게시를 막습니다. 그냥 통과시키는 것보다 낫습니다.

지우기를 누르면 바로 안 보이게 됩니다. 30일이 지나면 코드·표·미리보기·백업까지 함께 없어집니다. 그 사이에는 되살릴 수 있습니다.

앱을 고치려면 코드와 표 구조를 읽어야 합니다. 손님이 실제로 넣은 내용을 가져다 일하는 것이 아닙니다. “예약 목록에 취소 버튼을 넣어 줘”라고 시키면 목록을 그리는 코드를 읽지, 그 안의 예약자 이름을 읽지 않습니다.

손님 개인정보를 받아도 되나요? 받으실 수 있고, 받는 만큼 책임도 생깁니다. 꼭 필요한 항목만 받으세요. 이름과 전화만으로 되는 일에 주민번호까지 받을 이유는 없습니다. 화면에 보일 때는 가려서 보이게 하는 편이 안전합니다.

우리 데이터를 다른 곳으로 옮길 수 있나요? 소스를 통째로 내보내 가실 수 있고 표 구조도 함께 나갑니다. 저희만 돌릴 수 있는 기술로 묶어 두지 않습니다.

백업은 어떻게 되나요? 잘 된 지점마다 되돌릴 자리가 쌓입니다. 되돌리면 코드와 표 구조가 그때 상태로 함께 돌아갑니다. 한쪽만 돌아가지 않습니다.