Bynle

Client

React, với React Router canh giữ các tuyến riêng tư và một cây tuyến tách biệt dành cho tài khoản soát vé.

Ứng dụng

Các view REST của Django gom thành mười bộ xử lý theo miền, kèm serializer để kiểm tra dữ liệu và chuyển đổi JSON.

Dữ liệu

PostgreSQL cho dữ liệu có cấu trúc, chạy từ một image Docker; một bucket S3 cho tệp tải lên.

Tích hợp

Stripe cho thanh toán và đăng ký Connect, kèm một bước kiểm tra trạng thái quyết định câu lạc bộ hay người dùng có được phép thu tiền hay không.

Triển khai

Railway cho backend và cơ sở dữ liệu, AWS Amplify cho frontend, và quản lý phiên bản bằng Git cho cả hai.

Việc kiểm thử chạy trên ba hướng: rà soát mã ở mọi merge request, kiểm thử đơn vị cho backend, và các buổi thử nghiệm với sinh viên thật.

Backend khép lại với 134 kiểm thử đơn vị trải trên model và view — tính toàn vẹn dữ liệu cùng quy tắc kiểm tra ở một bên, xử lý yêu cầu và logic nghiệp vụ ở bên kia, gồm cả những phép kiểm tra quyền như xác nhận rằng chỉ tài khoản soát vé mới chạm được tới điểm xác thực vé. Không thay đổi nào vào được nhánh chính mà người kia chưa rà soát.

Thử nghiệm với người dùng đã thay đổi sản phẩm. Hai đề nghị lặp lại đủ rõ để chúng tôi bắt tay vào làm:

• Chuông thông báo. Người dùng muốn với tới lời mời kết bạn và các lượt chuyển vé đến từ bất cứ đâu, thay vì phải lần vào đúng trang chứa chúng. Một cái chuông kèm số đếm được đưa lên thanh điều hướng.
• Xoá lượt chuyển đã gửi. Người tham gia muốn rút lại lượt chuyển vé đã gửi nhầm, hoặc sau khi đổi ý. Các lượt chuyển đã gửi trở nên xoá được.

Cái gì đã hỏng

1. 01

   Quản trị viên câu lạc bộ bị mô hình hoá thành một lớp riêng

   Vấn đề

   Ban đầu quản trị viên câu lạc bộ là một lớp model riêng. Đó là hình dạng sai: quan hệ giữa người dùng và câu lạc bộ vốn là nhiều-nhiều, và ép nó đi qua một lớp riêng khiến việc quản trị trở nên vụng về.

   Cách khắc phục

   Tái cấu trúc sang quan hệ nhiều-nhiều, cho phép nhiều người quản trị nhiều câu lạc bộ mà không rườm rà, và làm gọn toàn bộ đường đi của việc quản trị.

2. 02

   Hai người, những migration bị xoá, một cơ sở dữ liệu vỡ

   Vấn đề

   Giai đoạn đầu, hai đứa làm trên hai nhánh riêng và cùng sinh migration mỗi khi đổi model. Cả hai đều chưa hiểu migration của Django đủ sâu, và cả hai đều từng xoá bớt. Khi rebase để gộp vào main, cơ sở dữ liệu vỡ: nó không còn khớp với model nữa, và chúng tôi mất rất lâu mới tìm ra vì sao.

   Cách khắc phục

   Chúng tôi thống nhất không bao giờ xoá migration nữa, trừ khi cơ sở dữ liệu đã sao lưu và việc xoá sạch là thực sự cần thiết. Một kịch bản dựng lại dữ liệu từ đầu giúp chúng tôi khôi phục nhanh một bộ dữ liệu chạy được trong lúc gỡ rối.

3. 03

   Vé vẫn hợp lệ khi đang chuyển nhượng

   Vấn đề

   Trong lúc một lượt chuyển vé còn dang dở, tấm vé vẫn ở trạng thái hoạt động, tạo nguy cơ có người vào cửa trái phép bằng chính tấm vé đang được trao đi.

   Cách khắc phục

   Vé giữ trạng thái chuyển nhượng cho tới khi người nhận chấp nhận hoặc người gửi huỷ. Ở trạng thái đó, vé không quét được và bị tính là không hợp lệ tại cửa.

4. 04

   Triển khai ba mảnh cùng lúc

   Vấn đề

   Đưa backend Django, frontend React và cơ sở dữ liệu lên cùng nhau ngốn nhiều ngày đọc tài liệu và một chuỗi dài những lần triển khai thất bại ở phía máy chủ backend.

   Cách khắc phục

   Railway, vốn tích hợp với kho mã và tự lấy phiên bản mới nhất của một nhánh cố định, dựng được backend cùng cơ sở dữ liệu trong một thực thể dùng chung; còn frontend thì chuyển sang AWS Amplify.