Buổi demo nào của phần mềm quản lý trường học cũng diễn ra trong văn phòng có wifi tốt. Còn lần hỏng đầu tiên thì luôn xảy ra trong một phòng học dưới tầng hầm, năm phút trước giờ vào lớp.
Chúng tôi học điều đó theo cách thông thường, và ECMS Mobile là thứ ra đời từ đó.
Cái hỏng thật sự quan trọng
Giáo viên mở ứng dụng, bấm qua ba mươi học sinh, nhấn lưu, và nhận một vòng xoay. Chuông reo. Họ đóng ứng dụng.
Chuyện xảy ra tiếp theo quyết định trường có tiếp tục dùng hệ thống hay không. Nếu dữ liệu điểm danh mất, giáo viên quay về ghi giấy cho hết học kỳ và nền tảng đã thua. Nếu dữ liệu được xếp hàng và tự về khi điện thoại bắt được sóng ngoài hành lang, không ai nhận ra là đã có vấn đề.
Vì vậy điểm danh không ghi thẳng ra mạng. Nó ghi cục bộ, và một hàng đợi gửi lại sẽ đẩy đi khi có kết nối.
"Offline-first" trên thực tế phải nghĩa là gì
Từ này hay bị dùng cho có. Ba điều phải đúng, nếu không thì chỉ là trang trí:
- Ghi cục bộ phải thành công và giao diện phải nói vậy. Không phải một vòng xoay lạc quan mà vẫn có thể thất bại. Điểm danh đã được ghi; việc gửi đi là chuyện riêng người dùng không cần nghĩ tới.
- Hàng đợi phải bền và không trùng lặp. Nó sống sót khi ứng dụng bị tắt, và gửi lại cùng một lượt điểm danh hai lần không tạo ra hai bản ghi. Máy chủ phải coi lần thứ hai là cùng một sự kiện, không phải một lần sửa.
- Đọc cũng phải chạy. Một danh sách lớp mà giáo viên không mở được thì vô dụng ngang với một lần lưu thất bại. Dữ liệu lớp được cache để màn hình hiện ra mà không cần gọi mạng.
Client sinh tự động, để lệch hợp đồng làm hỏng bản build
Ứng dụng bao mười lăm nhóm tính năng trên khoảng 367 file Dart: AI, bài tập, điểm danh, xác thực, lớp học, nội dung, thi cử, gia đình, tài chính, trang chủ, LMS, thông báo, hồ sơ, lịch học và ôn tập SRS. Đó là một bề mặt lớn phải giữ đồng bộ với một API NestJS vẫn đang thay đổi.
Sáu nhóm trong số đó nay dùng API client sinh tự động từ đặc tả OpenAPI của nền tảng thay vì lời gọi HTTP viết tay. Khác biệt nằm ở chỗ lỗi lộ ra lúc nào: một trường bị đổi tên trước đây hiện ra dưới dạng màn hình trắng cho giáo viên ở tuần thứ ba, còn nay nó hiện ra dưới dạng lỗi biên dịch trên máy lập trình viên ở phút thứ nhất.
Đặc tả trở thành thứ chịu lực. Nếu backend phát hành một route mà đặc tả không mô tả, ứng dụng không gọi được, và câu "cứ viết tay tạm đã" lặng lẽ đưa trở lại đúng cái lệch mà bạn sinh client để tránh. Quy tắc giữ cho nó trung thực: đặc tả là một phần của định nghĩa "xong" của API, không phải tài liệu viết sau.
Phân loại lỗi, vì "đã có lỗi xảy ra" không phải là một thông báo
Lớp network core phân loại thất bại thành các nhóm mà giao diện thật sự phản ứng được: không có kết nối (xếp hàng, báo bình tĩnh), phiên xác thực hết hạn (làm mới, thử lại một lần, rồi đưa về màn đăng nhập), dữ liệu bị từ chối do không hợp lệ (chỉ đúng ô nhập), và lỗi máy chủ (báo cáo, giữ bản cục bộ).
Gộp cả bốn thành một thông báo đỏ là thứ tạo ra cái phiếu hỗ trợ ghi "ứng dụng không dùng được".
Kết luận nhàm chán
Không có điều nào ở trên là tính năng ai đó ghi trong hồ sơ mời thầu. Chẳng ai viết "phải có hàng đợi gửi lại bền bỉ" vào yêu cầu kỹ thuật.
Nhưng nền tảng được đánh giá bằng việc một giáo viên với chiếc điện thoại một vạch sóng có hoàn thành được công việc trong chín mươi giây trước giờ vào lớp hay không. Mọi thứ còn lại - phân tích, gia sư AI, dự báo doanh thu - chỉ đến được với những người đã vượt qua bài kiểm tra đầu tiên đó.