앱 제안서에는 Flutter나 React Native가 크게 적히고, 서버는 한 줄로 남습니다. 출시 주에 막히는 곳은 대개 그 한 줄입니다. 로그인, 권한, 파일 업로드, 상태 변경, 관리자 조회, 푸시. 이 여섯이 없는 앱은 스토어에 올라가도 운영이 시작되지 않습니다.
파이랩과 비엔코드가 먼저 고정하는 것은 프레임워크 상호가 아니라 이 경계입니다. 앱은 토큰과 화면 상태를 갖고, 서버는 권한과 기록을 갖습니다. 관리자 대시보드는 같은 API를 다른 권한으로 봅니다. 충전 관제처럼 현장 숫자와 관리 숫자가 같이 있어야 하는 제품은 특히 그렇습니다. 앱 전용 비밀 엔드포인트를 따로 두면 나중에 웹 관리자가 같은 버그를 한 번 더 만듭니다.
푸시는 기능 목록의 맨 아래가 아니라 장애 목록의 맨 위입니다. 토큰 만료, 수신 거부, 야간 정책, 재전송. 결제나 예약이 푸시에만 의존하면 알림이 꺼진 사용자는 거래를 잃습니다. 앱 안 받은편지함이나 상태 화면이 원본이고, 푸시는 두드리는 역할이어야 합니다.
데이터베이스 제품명은 나중으로 미뤄도 됩니다. 미루면 안 되는 것은 되돌리기입니다. 예약 취소, 장비 명령 실패, 중복 결제 요청. 이 세 가지의 기록 방식이 정해지면 MySQL이든 PostgreSQL이든 구현은 따라옵니다. 앱 스택 회의에서 이 질문을 먼저 하면 서버 선택이 짧아집니다.
