Cách nhanh là dùng presigned URL (URL ký sẵn). API ký một URL, client PUT file thẳng lên bucket, và dữ liệu file không hề chạm tới API. Đây là câu trả lời chuẩn, và nó thành chuẩn là có lý do. Nhưng ngay khoảnh khắc bạn làm vậy, backend đã bị gạt ra khỏi cuộc chơi. Nó phát ra một URL rồi không nghe thấy gì nữa. File đã tới chưa? Kích thước có đúng như mong đợi không? Nó có thật sự là JPEG không? Phải có thứ gì đó báo cho backend biết, mà các lựa chọn thường thấy thì đều hơi chán: tin rằng client sẽ gọi lại báo “xong rồi” (client thì nói dối, crash, và mất sóng), định kỳ hỏi thăm bucket theo lịch (polling, vừa chậm vừa lãng phí), hoặc xử lý lười (lazy) vào lần đọc đầu tiên (người xem đầu tiên phải trả giá, và bạn vẫn không biết khi nào file đủ an toàn để tham chiếu tới). Chính điều này khiến upload trực tiếp lên S3 trông khó hơn thực tế. Phần upload thì dễ. Thứ còn thiếu là tín hiệu báo về.

Object notification (thông báo object) chính là tín hiệu đó. Tigris, dịch vụ lưu trữ tương thích S3 mà tôi dùng trên Fly.io, sẽ POST một body JSON nhỏ tới ứng dụng của bạn mỗi khi có object được tạo hoặc bị xóa trong bucket. Trên AWS, thứ tương đương là S3 event notification, mà thường nghĩa là phải nối thêm một Lambda, một hàng đợi SQS hoặc EventBridge trước khi bất cứ thứ gì chạm được tới code của bạn (SNS thì có thể POST tới một endpoint HTTPS, nhưng khi đó bạn lại phải xác nhận subscription và xác minh chữ ký trước đã). Tigris giữ mọi thứ ở mức một request HTTP tới một URL do bạn sở hữu, gần như là mức đơn giản nhất mà việc báo tín hiệu từ storage sang backend có thể đạt tới. Tính năng này tồn tại để bucket nói chuyện được với backend của bạn mà bạn không phải tự xây một cây cầu nối cho nó.

Bài này đi trọn cả luồng: phần cài đặt, một endpoint Django nhận sự kiện, một luồng upload bằng presigned URL mà vẫn giữ nguyên toàn bộ phần xử lý phía server, và những cái bẫy hay gặp (CORS, giới hạn kích thước, thời hạn, nhiều file). Cuối bài là cùng tín hiệu ấy làm việc hậu trường (back office): các file log rơi vào bucket được biến thành cảnh báo trên Discord, và nhờ đó tôi xóa được một cron job đã phải chăm bẵm suốt mấy tháng.

Câu trả lời ngắn

#

Trong dashboard của Tigris, mở bucket, vào Settings, rồi Object notifications. Đưa cho nó một URL HTTPS trỏ tới ứng dụng của bạn và chọn basic auth (một cặp username và password mà Tigris sẽ gửi trong header Authorization; lựa chọn còn lại là bearer token). Thêm một bộ lọc để chỉ nhận thông báo về những key bạn quan tâm. Bộ lọc là một biểu thức kiểu SQL, nên “chỉ ba prefix mà bài này xử lý” sẽ là:

WHERE `key` REGEXP "^(uploads/raw|logs/api|media)/"

Sau đó, mỗi khi có thay đổi, Tigris gửi một lô (batch) sự kiện như thế này:

{
  "events": [
    {
      "eventName": "OBJECT_CREATED_PUT",
      "eventTime": "2026-11-07T09:12:44Z",
      "bucket": "example-bucket",
      "object": { "key": "uploads/raw/1f3c.jpg", "size": 48213, "eTag": "9b2c…" }
    }
  ]
}

Những tên sự kiện bạn sẽ gặp là OBJECT_CREATED_PUT, OBJECT_CREATED_MULTIPART, OBJECT_CREATED_COPY và OBJECT_DELETED, cộng thêm các sự kiện đổi tên và chuyển tầng lưu trữ (storage tier). Endpoint của bạn kiểm tra auth, định tuyến từng sự kiện theo prefix của key, và trả về mã 2xx trong vòng mười giây. Có ba điều cần tính trước ngay từ đầu: việc gửi theo kiểu at least once (ít nhất một lần), nên bạn sẽ gặp sự kiện bị lặp; sự kiện được gom theo lô, nên một request có thể chứa nhiều sự kiện cùng lúc; và chúng có thể đến không theo thứ tự, nên đừng suy ra cái nào “mới nhất” từ thứ tự chúng tới.

Một webhook Django cho sự kiện của bucket

#

View này được viết nhàm chán một cách có chủ đích. Nó kiểm tra auth, parse body, rồi giao từng sự kiện cho một bộ định tuyến (router):

import base64, hmac, json, logging
from django.conf import settings
from django.http import JsonResponse
from django.views.decorators.csrf import csrf_exempt
from django.views.decorators.http import require_POST

from .bucket_events import handle, parse

logger = logging.getLogger(__name__)

def _authorised(request, secret) -> bool:
    header = request.headers.get("Authorization", "")
    if not header.startswith("Basic "):
        return False
    try:
        user, _, password = base64.b64decode(header[6:]).decode().partition(":")
    except (ValueError, UnicodeDecodeError):
        return False
    return hmac.compare_digest(user.encode(), b"tigris") and hmac.compare_digest(
        password.encode(), secret.encode()
    )

@csrf_exempt
@require_POST
def bucket_webhook(request):
    secret = settings.BUCKET_WEBHOOK_SECRET
    if not secret:
        return JsonResponse({"error": "not configured"}, status=503)
    if not _authorised(request, secret):
        return JsonResponse({"error": "unauthorised"}, status=401)
    try:
        body = json.loads(request.body or b"{}")
    except ValueError:
        return JsonResponse({"error": "invalid json"}, status=400)
    for event in parse(body):
        try:
            handle(event)
        except Exception:
            logger.exception("bucket event failed: %s", event.key)
    return JsonResponse({"ok": True})

compare_digest ở đó để phép kiểm tra luôn mất cùng một khoảng thời gian, bất kể bạn gửi gì lên (so sánh trên bytes, vì với chuỗi thì nó ném lỗi khi gặp ký tự ngoài ASCII, và một header cố tình chế ra sẽ nhận 500 thay vì 401). Nếu secret chưa được đặt, chẳng hạn trên một máy staging mới dựng, endpoint sẽ từ chối tất cả chứ không phải chấp nhận tất cả. Còn một handler ném ra ngoại lệ thì được ghi log và vẫn được trả lời 200: Tigris gửi lại bất cứ thứ gì không phải 2xx, lần gửi lại sẽ vấp đúng bug đó, và đến lúc ấy sự kiện đã được claim rồi (đánh dấu là đã nhận, xem hai mục bên dưới) nên lần gửi lại cũng chẳng làm được gì. Chính dòng log mới là thứ giúp bug được sửa. Cách làm này giả định rằng lỗi là tất định (deterministic), tức là lần nào chạy cũng hỏng y như nhau. Một lần timeout tạm thời phía storage sẽ tiêu thụ mất sự kiện đó vĩnh viễn: với ảnh thì không sao, vì bước lưu có thể tự xử lý, nhưng cảnh báo từ một file log thì sẽ mất luôn. Nếu điều đó quan trọng với bạn, hãy giải phóng claim trong khối except và trả về 500 để Tigris gửi lại, đồng thời chấp nhận rằng một bug thật khi ấy sẽ bị gửi lại cho tới khi được sửa.

Định tuyến theo prefix

#

Mọi thứ trong bucket vốn đã được tổ chức theo prefix, nên định tuyến theo prefix là cách tự nhiên nhất. Mỗi mục đích sử dụng là một hàm và một dòng trong bảng:

HANDLERS = [
    ("uploads/raw/",   on_raw_photo),
    ("logs/api/",      on_api_log_file),
    ("media/",         on_media_change),
]

def handle(event):
    for prefix, fn in HANDLERS:
        if event.key.startswith(prefix):
            if claim(event):  # xem bên dưới
                fn(event)
            return

Sau này muốn thêm việc thứ tư thì chỉ cần một hàm mới và một dòng mới. Tôi thích cách này hơn mình tưởng.

“Ít nhất một lần” nghĩa là “có thể hai lần”

#

Tigris sẽ gửi lại nếu endpoint của bạn phản hồi chậm hoặc trả lỗi, và giống hầu hết các bên gửi webhook khác, nó không hứa rằng bạn chỉ thấy mỗi sự kiện đúng một lần. Vì vậy, trước khi handler chạy, sự kiện được claim theo bộ ba (key, eTag, eventName). eTag ở đây quan trọng: nếu một file bị ghi đè, đó là phiên bản mới với eTag mới và cần được xử lý lại. Còn nếu chỉ là cùng phiên bản đó được gửi lặp lại thì không cần xử lý nữa.

from django.core.cache import cache

def claim(event, ttl=7 * 24 * 3600) -> bool:
    k = f"bucket-event:{event.name}:{event.key}:{event.etag}"
    return cache.add(k, 1, ttl)  # False nếu đã có bên khác claim trước

cache.add chỉ ghi key khi key đó chưa tồn tại, và trên Redis thao tác này là nguyên tử (atomic), nên hai máy cùng nhận một lần gửi lại không thể cùng thắng. Trong hệ thống thật, tôi dùng một cơ chế lease lưu trong database cho việc này, vì muốn nó sống sót qua cả một lần flush Redis, nhưng ý tưởng thì y hệt.

Upload ảnh thẳng lên S3 mà pipeline vẫn nguyên vẹn

#

Đây là phần khiến toàn bộ công sức làm đường ống (plumbing) ở trên trở nên xứng đáng.

Trước đây, chọn ảnh cho một tin đăng nghĩa là ứng dụng giữ ảnh lại trên máy, và khi bạn bấm Đăng thì nó gửi tất cả lên API dưới dạng base64. API resize ảnh, tạo thumbnail, tính màu chủ đạo và blurhash, xong xuôi mới phản hồi. Mười tấm ảnh trên một đường mạng chậm là một vòng xoay loading rất dài. Và một request chứa mười tấm ảnh base64 là một body to và chậm mà API server phải giữ trong bộ nhớ, đó cũng là lý do thầm lặng khiến tôi cứ phải giữ ảnh ở kích thước nhỏ.

Giờ luồng này gồm bốn bước, và backend được báo về từng bước một.

1. Client thu nhỏ ảnh và xin một suất upload

#

Ứng dụng vẫn resize ngay trên thiết bị, về đúng cạnh dài nhất mà server sẽ giữ (1080px), dưới dạng JPEG với chất lượng 0.7. Lần resize đó chỉ để tiết kiệm băng thông cho người dùng, không vì gì khác. Rồi nó xin API một suất upload (upload slot):

import uuid
from datetime import timedelta
import boto3
from django.utils import timezone

s3 = boto3.client("s3", endpoint_url="https://fly.storage.tigris.dev")
BUCKET = "example-bucket"

def create_upload_slot(user):
    public_id = uuid.uuid4()
    key = f"uploads/raw/{public_id}.jpg"
    upload = PhotoUpload.objects.create(
        user=user,
        public_id=public_id,
        raw_key=key,
        expires_at=timezone.now() + timedelta(days=2),
    )
    url = s3.generate_presigned_url(
        "put_object",
        Params={"Bucket": BUCKET, "Key": key, "ContentType": "image/jpeg"},
        ExpiresIn=15 * 60,
    )
    return {
        "upload_id": str(upload.public_id),
        "url": url,
        "method": "PUT",
        "headers": {"Content-Type": "image/jpeg"},
        "expires_in": 15 * 60,
    }

Suất upload là một dòng trong database trước khi trở thành một file. Chính điều đó cho server biết ai đã xin nó, khi nào nó hết hạn, và sau này là nó có từng được dùng hay không.

2. Client PUT thẳng lên bucket

#

const slot = await api.post("/photo-uploads/");
const res = await fetch(slot.url, {
  method: slot.method,
  headers: slot.headers,
  body: blob,
});
if (!res.ok) throw new Error("upload refused");
// giữ lại slot.upload_id cho bước lưu

API không bao giờ nhìn thấy dữ liệu file. Từ trình duyệt, từ React Native hay từ app native đều y như nhau; khác biệt duy nhất là trình duyệt cần một rule CORS trên bucket, sẽ nói ở phần các cái bẫy bên dưới.

3. Tigris báo cho backend, và pipeline chạy

#

Trong vòng vài giây, Tigris POST một sự kiện OBJECT_CREATED_PUT cho uploads/raw/…, và handler chạy đúng pipeline xử lý ảnh mà đường base64 trước giờ vẫn dùng, trong lúc người dùng còn đang gõ tiêu đề:

from io import BytesIO
from PIL import Image, ImageOps
from django.core.files.base import ContentFile
from django.utils import timezone
import blurhash

MAX_BYTES = 15 * 1024 * 1024

def on_raw_photo(event):
    if not event.name.startswith("OBJECT_CREATED"):
        return
    if event.size > MAX_BYTES:
        s3.delete_object(Bucket=event.bucket, Key=event.key)
        return
    upload = PhotoUpload.objects.filter(raw_key=event.key, processed_at=None).first()
    if upload is None:
        return
    data = s3.get_object(Bucket=event.bucket, Key=event.key)["Body"].read()
    process(upload, data)

def to_webp(im, longest, quality):
    im = im.copy()
    im.thumbnail((longest, longest))
    buf = BytesIO()
    im.save(buf, "WEBP", quality=quality, icc_profile=im.info.get("icc_profile"))
    return ContentFile(buf.getvalue())

def process(upload, data):
    with Image.open(BytesIO(data)) as im:
        im = ImageOps.exif_transpose(im).convert("RGB")
        im.thumbnail((1080, 1080))
        upload.width, upload.height = im.size
        upload.dominant_color = "#%02x%02x%02x" % im.resize((1, 1)).getpixel((0, 0))
        upload.image.save(f"{upload.public_id}.webp", to_webp(im, 1080, 80), save=False)
        upload.thumbnail.save(f"{upload.public_id}_t.webp", to_webp(im, 320, 70), save=False)
        upload.blurhash = blurhash.encode(im.resize((32, 32)), 4, 3)
    upload.processed_at = timezone.now()
    upload.save()

Dòng đầu tiên của on_raw_photo quan trọng hơn vẻ ngoài của nó. Router gửi mọi sự kiện dưới uploads/raw/ tới đây, kể cả các sự kiện xóa do job dọn upload mồ côi và do chính phép kiểm tra kích thước ngay bên dưới tạo ra, mà get_object trên một key đã bị xóa thì chỉ ném lỗi chứ chẳng làm gì khác.

Vậy nên việc client thu nhỏ ảnh chỉ là để nhẹ đường truyền, không hơn. Server vẫn là bên quyết định định dạng (WebP), các kích thước, thumbnail, ảnh placeholder, và chiều rộng chiều cao được lưu lại. Việc encode lại qua Pillow cũng đồng thời bỏ đi khối EXIF, nơi camera điện thoại cất vị trí GPS, nên phần tước bỏ thông tin riêng tư có được miễn phí. Profile ICC lẽ ra cũng sẽ mất theo cùng cách đó, khiến ảnh chụp từ điện thoại có dải màu rộng (wide-gamut) bị lệch màu đôi chút, nên to_webp giữ nó lại và truyền tiếp. Nếu bạn muốn giữ ảnh gốc nguyên từng pixel thì đừng thu nhỏ ở client; luồng vẫn y nguyên, chỉ là các lệnh PUT nặng hơn, và PUT nặng hơn chính xác là thứ mà thiết kế này làm cho rẻ. Một điểm cần lưu ý: ảnh gốc từ iPhone là HEIC, mà Pillow chỉ mở được khi đã cài pillow-heif.

4. Bước lưu gắn ảnh vào và không bao giờ chờ webhook

#

Khi người dùng bấm Đăng, request mang theo upload_ids thay vì dữ liệu ảnh. Server tra từng id một, với ba kết quả có thể xảy ra:

def take(user, upload_ids):
    uploads = list(PhotoUpload.objects.filter(
        user=user, public_id__in=upload_ids, expires_at__gt=timezone.now()
    ))
    if len(uploads) != len(set(upload_ids)):     # đã hết hạn, hoặc không phải của người dùng này
        raise UploadNotReadyError(upload_ids)
    for upload in uploads:
        if upload.processed_at is None:          # webhook chưa tới
            data = read_raw(upload)              # None nếu lệnh PUT chưa từng tới nơi
            if data is None:
                raise UploadNotReadyError(upload.public_id)
            process(upload, data)
    return uploads

Nếu thông báo đã chạy rồi, các file đã xử lý được gắn vào nguyên như vậy. Nếu file đã nằm trong bucket nhưng thông báo chưa tới, bước lưu xử lý ngay tại chỗ, nên một tin đăng không bao giờ phải chờ webhook. Thông báo là một lợi thế xuất phát sớm, không phải một phụ thuộc bắt buộc. Còn nếu file hoàn toàn chưa có, hoặc một id đã hết hạn hay thuộc về người khác, bước lưu trả về lỗi validation và ứng dụng sẽ thử lại sau một chút; ứng dụng vốn chờ các lệnh PUT của chính nó xong rồi mới gửi, nên trên thực tế chuyện này hiếm.

Vài chi tiết giúp cách này đứng vững. Suất upload thuộc về một người dùng, nên server chỉ chấp nhận những upload id do chính người đó tạo; nếu không, bất kỳ ai nhìn thấy một id đều có thể gắn ảnh của bạn vào tin đăng của họ. Mọi thứ đều có đường lui: nếu xin suất upload thất bại, lệnh PUT bị từ chối, hoặc API đang ở phiên bản cũ, ứng dụng gửi base64 y như trước. Nó chỉ đi đường upload khi mọi ảnh mới đều có suất, nên ảnh của một tin đăng hoặc toàn bộ là upload hoặc toàn bộ là base64, và thứ tự của chúng vẫn là một danh sách duy nhất. Và upload mồ côi sẽ tự hết hạn: có người chọn ảnh xong rồi bỏ ngang, nên một upload không bao giờ được gắn vào đâu sẽ hết hạn sau hai ngày, và job dọn media mồ côi sẵn có sẽ xóa các file của nó.

Những cái bẫy khi upload bằng presigned URL: CORS, giới hạn kích thước, thời hạn, nhiều file

#

Phần lớn những gì trục trặc với upload bằng presigned URL đều trục trặc trước khi thông báo kịp bắn ra. Đây là những thứ tôi muốn gom lại trên một trang.

CORS, chỉ với trình duyệt

#

App native không quan tâm chuyện này. Trình duyệt thì gửi một request preflight OPTIONS tới bucket trước khi PUT, và upload sẽ thất bại với lỗi CORS trừ khi các rule CORS của bucket cho phép PUT từ origin của bạn kèm header Content-Type. Tigris nhận cấu hình CORS chuẩn của S3, nên rule trông giống hệt trên AWS. Đó là thứ đầu tiên cần kiểm tra khi một lệnh PUT bằng presigned URL chạy được từ curl mà không chạy được từ trang web.

Content type là một phần của chữ ký

#

Ký kèm ContentType nghĩa là client phải gửi đúng header đó, nếu không bucket trả về 403 SignatureDoesNotMatch. Đó là lý do suất upload trả về cả headers cùng với URL. Hãy ký như vậy một cách có chủ đích, nhưng cần biết rõ nó đem lại gì và không đem lại gì: header thì bị ép buộc, còn nội dung thì không, nên một file PDF gắn nhãn image/jpeg vẫn lọt qua. Pipeline mới là phép kiểm tra thật; Pillow từ chối mở thứ gì không phải ảnh, và dòng đó không bao giờ được đánh dấu là đã xử lý.

Giới hạn kích thước

#

Một presigned PUT URL không mang theo giới hạn kích thước nào. Nếu bạn cần một chốt chặn cứng trước khi dữ liệu kịp tới nơi, presigned POST với điều kiện policy content-length-range làm được việc đó. Tôi không bận tâm, vì thông báo đã mang theo size của object: handler xóa bất cứ thứ gì vượt giới hạn trước khi đọc nó, còn đường xử lý lúc lưu thì chỉ đọc tối đa bằng giới hạn cộng thêm một byte, đủ để nhận ra file quá lớn. Ứng dụng gửi vài trăm kilobyte; thứ gì tiến gần tới mười lăm megabyte thì chắc chắn không phải do ứng dụng gửi lên.

Thời hạn hiệu lực

#

Có hai mốc hết hạn khác nhau. Presigned URL có hiệu lực mười lăm phút, thừa đủ cho một lệnh PUT và đủ ngắn để một URL bị lộ sớm trở nên vô dụng. Dòng suất upload có hiệu lực hai ngày, đủ cho trường hợp ai đó chọn ảnh, đặt điện thoại xuống, rồi hôm sau mới hoàn thành tin đăng. Client coi một upload đang dang dở là cũ sau một ngày và bắt đầu một upload mới thay vì ngồi hy vọng.

Nhiều file, và file lớn hơn

#

Mỗi file một suất upload. Mười tấm ảnh là mười suất và mười lệnh PUT song song, mỗi lệnh có thanh tiến trình (progress) riêng (XMLHttpRequest cho bạn upload.onprogress; fetch thì không), điều bạn không thể có với một lệnh POST base64 khổng lồ. Quá vài megabyte thì dùng multipart (mỗi phần tối thiểu 5 MiB, nên cách này dành cho những file lớn hơn mức đó khá nhiều): tạo multipart upload trên server, ký sẵn từng upload_part, rồi hoàn tất khi các phần đã tới đủ. Tigris gửi OBJECT_CREATED_MULTIPART khi upload được hoàn tất (complete), nên cùng handler đó được kích hoạt và không có gì khác phải thay đổi.

Không theo thứ tự

#

Sự kiện có thể đến không theo thứ tự, vì object có thể đã được ghi ở nhiều hơn một region. Với upload thì không sao: một key, một sự kiện. Với một key bị ghi đè, hãy tin vào eTag và Last-Modified của object, chứ không phải thứ tự các webhook tới chỗ bạn.

Cùng tín hiệu đó cho log: cảnh báo lên Discord

#

Một khi bucket đã nói chuyện được với backend, bất cứ thứ gì rơi vào bucket đều có thể được phản ứng theo cùng một cách, và thứ thứ hai tôi trỏ nó vào là log.

Log của ứng dụng được đẩy vào bucket dưới dạng các file gzip nhỏ, mỗi ứng dụng khoảng năm phút một file. Suốt gần cả năm, một GitHub Action chạy cron 15 phút một lần dùng DuckDB đọc 20 phút gần nhất trong kho lưu trữ đó, lọc ra các dòng request chậm, rồi gửi bản tổng hợp lên Discord. Trên giấy thì ổn. Thực tế, các workflow chạy theo lịch của GitHub không chạy đúng giờ khi nền tảng đang bận, nên “15 phút một lần” thành ra “vài tiếng một lần”, và đến khi chạy được thì khoảng thời gian cần xử lý đã dồn lại lớn hơn nhiều, thỉnh thoảng còn hết bộ nhớ. Phần cửa sổ chồng lấn mà tôi thêm vào để không bỏ sót gì giữa hai lần chạy lại khiến cùng một request chậm đôi khi hiện lên hai lần. Cả một bộ máy cồng kềnh chỉ để làm một việc: “báo tôi biết khi có request chậm”.

Giờ mỗi file log được đọc đúng một lần, ngay khi nó vừa tới. Mỗi file chỉ vài kilobyte sau khi gzip. Handler lọc ra các dòng request chậm, và nếu có đủ nhiều, hoặc có một request chậm hẳn, nó gửi bản tổng hợp vào một kênh Discord thông qua webhook. Tương tự với một loạt phản hồi 5xx dồn dập trong cùng một file. Gọi Discord webhook từ Python chỉ là một lệnh:

import requests
from django.conf import settings

def discord_alert(text: str) -> None:
    requests.post(
        settings.DISCORD_WEBHOOK_URL,
        json={"content": text[:1900]},  # Discord giới hạn một tin nhắn ở 2000 ký tự
        timeout=5,
    )

Không còn cron, không còn cửa sổ chồng lấn, không còn báo trùng, và cảnh báo đến trong vòng vài phút sau request thay vì đợi đến khi GitHub rảnh tay. Cái Action đó đã bị xóa.

Nhân tiện đã mở từng file ra, tôi đếm luôn những gì có trong đó (lỗi, cảnh báo, health check) rồi cộng vào một bảng thống kê theo giờ. Trước đây, bản tóm tắt hằng ngày phải quét cả một ngày log trong kho lưu trữ. Giờ nó chỉ đọc vài trăm dòng, và chỉ quay lại quét kho lưu trữ khi bảng thống kê bị hở ở đâu đó.

Một chốt chặn cho lệnh xóa

#

Cái này tôi không hề lên kế hoạch. Nó tự nảy ra khi đã có sự kiện OBJECT_DELETED. Khi một file media bị xóa, handler kiểm tra xem còn dòng nào trong database trỏ tới file đó không. Nếu còn, nghĩa là có bug ở đâu đó (hoặc có ai đó lỡ tay trong console của bucket), nên handler xóa giá trị ở cột đó (ứng dụng sẽ hiển thị ảnh placeholder thay vì ảnh lỗi) rồi báo cáo lại.

Nó cũng đếm số lượt xóa theo giờ. Dọn dẹp bình thường chỉ xóa vài file. Nếu có lúc nó thấy vài trăm lượt xóa trong một giờ, tôi muốn được biết ngay khi chuyện đang xảy ra, chứ không phải đợi đến lúc người dùng bắt đầu báo ảnh trắng trơn.

Vài điều nên biết

#

Phản hồi thật nhanh. Tigris cho mỗi lần gửi mười giây. Đọc một file log 5 KB hay xử lý một tấm ảnh điện thoại thì vừa; thứ gì có thể lâu hơn thì đẩy vào hàng đợi (queue) và để view trả 200 ngay, nếu không Tigris sẽ timeout rồi gửi lại, và bạn lại quay về chuyện khử trùng lặp.

Lọc ngay tại bucket. Bộ đẩy log của tôi ghi một file vài phút một lần cho mỗi ứng dụng, ngày này qua ngày khác. Nếu bạn chỉ quan tâm một prefix, hãy nói rõ trong bộ lọc của thông báo để ứng dụng của bạn không bị đánh thức vì mọi thứ khác.

Kiểm thử bằng body giả. Payload nhỏ và ổn định, nên các bài kiểm thử chỉ cần POST JSON vào view kèm header Authorization đúng, rồi assert xem handler đã làm gì. Không cần đụng đến storage thật.

Đừng để nó gánh trọng trách ngay từ ngày đầu. Mỗi cách dùng ở đây đều có đường lui: bước lưu có thể tự xử lý ảnh, bản tóm tắt hằng ngày vẫn có thể quét kho lưu trữ, ứng dụng vẫn có thể gửi base64. Thông báo giúp từng việc nhanh hơn và rẻ hơn, nhưng không việc nào sụp đổ nếu lỡ mất một webhook.

Khoảnh khắc đã nhất trong tuần là lúc xóa file workflow đó. Bốn mươi dòng YAML, một script Python, hai repository secret và câu hỏi lặp đi lặp lại “sao cảnh báo không bắn ra” đều biến mất, thay vào đó là một handler đọc một file nhỏ ngay khi nó vừa tới. Nhưng chuyện upload mới là mục đích chính. Ảnh đi lên nhanh hết mức đường mạng cho phép, server vẫn là bên quyết định cuối cùng với từng tấm một, và không ai phải xây cầu nối giữa bucket và backend, vì giờ bucket tự kể lại chuyện gì vừa xảy ra.

Cập nhật, ngày 13 tháng 9 năm 2026. Sau khi bài này lên, Codemagic đã ra mắt Patch, một máy chủ OTA mã nguồn mở, tự vận hành được (self-hosted), theo mô hình CodePush. Nếu bạn tìm tới đây vì không muốn tự viết máy chủ, thì giờ đã có một lựa chọn thật sự: tôi đã chuyển một ứng dụng từ hệ thống bên dưới sang Patch và viết lại quá trình đó, ngoài ra còn có một ghi chú ngắn ở phần Tổng kết. Minh bạch: Codemagic đã trả tiền để tôi thực hiện đợt di chuyển đó và viết về nó, và họ đề nghị nhắc tới ở đây. Phần mã trong bài sau đó đã được rút gọn thành các ví dụ ngắn.

Với ứng dụng báo giá mà tôi đang làm, các bản sửa lỗi được đẩy thẳng qua mạng (over the air): phần mã JavaScript mới về tận điện thoại người dùng mà không phải chờ App Store duyệt. Thật ra EAS Update, dịch vụ do chính Expo vận hành, sẵn sàng lo việc này giúp bạn. Nhưng tôi vẫn tự làm một bản riêng bằng Django REST Framework và Tigris S3, và từ đó tới giờ, mọi bản cập nhật cho cả iOS lẫn Android đều đi qua hệ thống này.

Cơ chế cập nhật OTA của Expo như sau: thư viện expo-updates trong ứng dụng gửi yêu cầu lấy manifest tới một máy chủ cập nhật, kèm theo nền tảng (platform) và phiên bản runtime (runtime version) trong header. Máy chủ trả về bản cập nhật mới nhất còn tương thích, cùng URL của gói mã (bundle) JavaScript và các tài nguyên đi kèm; ứng dụng tải chúng về và chạy gói mã mới ở lần khởi động kế tiếp. EAS Update là máy chủ do Expo vận hành cho giao thức đó, nhưng thực ra máy chủ nào nói đúng giao thức cũng dùng được, và tôi đã tự làm một cái như thế.

Trong bài này, tôi sẽ đi qua toàn bộ hệ thống: các mô hình dữ liệu (model), endpoint trả về manifest, quy trình phát hành (publish), và cả những cái bẫy mà phải tự vận hành thì bạn mới gặp.

Vì sao lại tự vận hành?

#

Với tôi thì lý do chính là tiền. EAS Update tính phí theo mức sử dụng, nên khi bạn đẩy bản cập nhật thường xuyên cho một lượng người dùng ngày càng đông, chi phí sẽ cộng dồn lên. Trong khi đó, dịch vụ lưu trữ tương thích S3 như Tigris thì gần như miễn phí. Cũng có vài lý do khác, biết đâu còn quan trọng hơn với bạn. Một số ngành bắt buộc mọi tài nguyên (asset) của ứng dụng phải nằm trong hạ tầng của chính công ty. Tự nắm máy chủ cũng có nghĩa là tự nắm luồng cập nhật: nếu sản phẩm cần, bạn có thể phát hành dần cho từng nhóm người dùng, hay thử nghiệm A/B với các gói mã (bundle) khác nhau. Và quy trình cập nhật của bạn không còn phụ thuộc vào chuyện dịch vụ của Expo có ổn định hay không, hay lần tới họ sẽ đổi bảng giá ra sao.

Các thành phần kết nối với nhau thế nào

#

Hệ thống gồm bốn thành phần: một máy chủ Django trả về manifest của bản cập nhật và lưu siêu dữ liệu (metadata); Tigris chứa các tệp gói mã và tài nguyên thật; một script phát hành lo phần kết xuất (export), tải lên và đăng ký bản cập nhật; và cuối cùng là chính ứng dụng di động, được cấu hình trỏ về máy chủ của tôi thay vì máy chủ của Expo.

┌─────────────────┐
│   Mobile App    │
│  (expo-updates) │
└────────┬────────┘
         │ 1. Request manifest
         │    (with headers: platform, runtime-version)
         ↓
┌─────────────────┐
│  Django Server  │
│  /api/expo-     │◄─── 2. Query DB for latest update
│   updates/      │
│   manifest/     │
└────────┬────────┘
         │ 3. Generate presigned URLs
         │
         ↓
┌─────────────────┐
│   Tigris S3     │
│  (Asset Files)  │◄─── 4. App downloads bundles directly
└─────────────────┘

Bắt tay vào làm

#

Hai mô hình dữ liệu

#

Mọi thứ đều xoay quanh hai mô hình ExpoUpdate và ExpoUpdateAsset. Mô hình thứ nhất lưu siêu dữ liệu của từng bản cập nhật:

class ExpoUpdate(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4)
    runtime_version = models.CharField(max_length=50, db_index=True)
    platform = models.CharField(
        max_length=10,
        choices=[("ios", "iOS"), ("android", "Android")],
        db_index=True
    )
    is_active = models.BooleanField(default=True, db_index=True)
    manifest_data = models.JSONField()
    description = models.TextField(blank=True)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        indexes = [
            models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
        ]

Trong mô hình này có vài chỗ tôi cố ý thiết kế như vậy. runtime_version tương ứng với runtimeVersion trong app.json, và trường này gánh khá nhiều việc: máy khách chỉ tải những bản cập nhật có cùng phiên bản runtime (runtime version) với mình. iOS và Android được lưu thành hai bản ghi riêng, vì gói mã của hai nền tảng khác nhau. is_active chính là cơ chế khôi phục về phiên bản trước (rollback): chỉ cần tắt bản cập nhật bị lỗi là máy khách quay về bản trước đó. Còn manifest_data lưu nguyên manifest theo giao thức Expo Updates v1 dưới dạng JSON, nên về sau muốn trả manifest ra thì chỉ cần tra một lần là xong.

ExpoUpdateAsset thì theo dõi từng tệp riêng lẻ:

class ExpoUpdateAsset(models.Model):
    id = models.UUIDField(primary_key=True, default=uuid.uuid4)
    update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE, related_name="assets")
    hash = models.CharField(max_length=255, db_index=True)
    key = models.CharField(max_length=255)
    content_type = models.CharField(max_length=100)
    file_extension = models.CharField(max_length=10)
    file_path = models.CharField(max_length=500)
    file_size = models.IntegerField(default=0)

Tài nguyên được định danh bằng mã băm (hash) SHA-256, nên nội dung của chúng không bao giờ đổi và có thể lưu đệm (cache) thoải mái. Một tài nguyên dùng chung cho bao nhiêu bản cập nhật cũng được.

Endpoint manifest

#

/api/expo-updates/manifest/ là nơi ứng dụng và máy chủ thật sự trao đổi với nhau. Endpoint này được xây dựng theo giao thức Expo Updates v1:

@action(detail=False, methods=["get"], url_path="manifest")
def manifest(self, request):
    # Extract required headers
    protocol_version = request.META.get("HTTP_EXPO_PROTOCOL_VERSION")
    platform = request.META.get("HTTP_EXPO_PLATFORM")
    runtime_version = request.META.get("HTTP_EXPO_RUNTIME_VERSION")

    # Validate protocol version
    if protocol_version != "1":
        return Response(
            {"error": f"Unsupported protocol version: {protocol_version}"},
            status=400
        )

    # Find latest active update for this runtime + platform
    update = ExpoUpdate.objects.filter(
        runtime_version=runtime_version,
        platform=platform,
        is_active=True,
    ).order_by("-created_at").first()

    # No update available - client uses embedded bundle
    if not update:
        response = Response(status=204)
        response["expo-protocol-version"] = "1"
        return response

    # Generate presigned URLs for all assets
    manifest_data = build_manifest(update)  # fills in presigned asset URLs

    return Response(manifest_data, status=200)

Ở đây có ba chi tiết cần để ý. Thứ nhất, phản hồi (response) 204 nghĩa là “không có bản cập nhật nào”, và ứng dụng cứ thế chạy tiếp với gói mã nhúng sẵn. Thứ hai, URL của tài nguyên trong manifest là URL ký sẵn (presigned URL), nên ứng dụng tải thẳng từ CDN của Tigris chứ không phải truyền mọi thứ qua Django. Thứ ba, header expo-protocol-version trong phản hồi là bắt buộc, vì máy khách sẽ kiểm tra giá trị này.

Phát hành bản cập nhật

#

Phần phát hành là một lệnh quản trị (management command) của Django, bên ngoài bọc thêm một shell script. Lệnh này đọc đầu ra của expo export, tính mã băm SHA-256 cho từng tài nguyên, tải song song gói mã và tài nguyên lên Tigris, ghi bản ghi vào cơ sở dữ liệu, và nếu cần thì đặt thêm vào bucket một tệp JSON dùng để nhập (import) dữ liệu, phục vụ việc đồng bộ lên môi trường production. Rút gọn lại thì phần quan trọng trông như sau:

from concurrent.futures import ThreadPoolExecutor

from django.db import transaction


def publish(platform, runtime_version, manifest, files):
    # Upload the bundle and assets in parallel (keys are content hashes)
    with ThreadPoolExecutor(max_workers=10) as executor:
        list(executor.map(upload_asset, files))

    # Swap the active update in one transaction
    with transaction.atomic():
        ExpoUpdate.objects.filter(
            runtime_version=runtime_version,
            platform=platform,
            is_active=True,
        ).update(is_active=False)

        return ExpoUpdate.objects.create(
            runtime_version=runtime_version,
            platform=platform,
            manifest_data=manifest,
        )

Còn thứ tôi thật sự gõ hằng ngày là script bọc ngoài:

# Publish to local environment
./publish.sh ios

# Publish to production
./publish.sh ios --production

# Dry run to validate
./publish.sh --dry-run

Script này nạp các biến môi trường production trước khi kết xuất, chạy được cho một hoặc cả hai nền tảng, và lo luôn phần đồng bộ lên production mà tôi sẽ nói ngay bên dưới.

Đồng bộ lên production

#

Tôi không muốn để sẵn thông tin đăng nhập (credential) của production trên laptop, nên việc triển khai lên production được chia làm hai bước. Đầu tiên là phát hành từ môi trường cục bộ (local): tài nguyên được đẩy lên Tigris, kèm một bản chụp siêu dữ liệu dạng JSON. Sau đó gọi một endpoint API trên production, kèm theo đường dẫn S3, để máy chủ tự nhập siêu dữ liệu về:

@action(detail=False, methods=["post"], url_path="import-update")
def import_update(self, request):
    # Authenticate via Bearer token
    token = request.META.get("HTTP_AUTHORIZATION", "").removeprefix("Bearer ")
    if not hmac.compare_digest(token, settings.IMPORT_TOKEN):
        return Response({"error": "Invalid token"}, status=401)

    # Download the import JSON from the bucket
    s3_key = request.data.get("s3_key")
    obj = s3_client.get_object(Bucket=bucket_name, Key=s3_key)
    data = json.loads(obj["Body"].read())

    # Import into the production database
    with transaction.atomic():
        update, _ = ExpoUpdate.objects.update_or_create(id=data["id"], defaults={...})
        for asset_data in data["assets"]:
            ExpoUpdateAsset.objects.update_or_create(...)

    # Clean up the import JSON
    s3_client.delete_object(Bucket=bucket_name, Key=s3_key)
    return Response({"update_id": str(update.id)})

Trỏ ứng dụng về máy chủ của bạn

#

Trong app.json, bạn khai báo URL cập nhật và phiên bản runtime:

{
  "expo": {
    "runtimeVersion": "1.0.0",
    "updates": {
      "url": "https://api.example.com/api/expo-updates/manifest/"
    }
  }
}

Chỗ này phải thật chặt chẽ: runtimeVersion ở ứng dụng và ở máy chủ lúc nào cũng phải khớp nhau. Mỗi khi thay đổi phần mã native hoặc nâng cấp Expo SDK, hãy tăng phiên bản runtime rồi phát hành bản cập nhật mới cho phiên bản đó.

Lưu trữ trên Tigris

#

Tigris là dịch vụ lưu trữ đối tượng (object storage) tương thích S3, rẻ hơn AWS S3 khá nhiều, lại có sẵn bộ nhớ đệm tại biên (edge cache) trên toàn cầu. Điểm này rất đáng giá khi người dùng phải tải về những gói mã nặng vài MB. Cấu hình phía Django như sau:

# settings.py
BUCKET_NAME = os.getenv("BUCKET_NAME")
AWS_ENDPOINT_URL_S3 = os.getenv("AWS_ENDPOINT_URL_S3")
AWS_ACCESS_KEY_ID = os.getenv("AWS_ACCESS_KEY_ID")
AWS_SECRET_ACCESS_KEY = os.getenv("AWS_SECRET_ACCESS_KEY")
AWS_REGION = os.getenv("AWS_REGION", "auto")

Còn phần khởi tạo client S3 thì chỉ là boto3 như bình thường:

import boto3

def create_s3_client(endpoint_url, region, access_key, secret_key):
    return boto3.client(
        "s3",
        endpoint_url=endpoint_url,
        region_name=region,
        aws_access_key_id=access_key,
        aws_secret_access_key=secret_key,
    )

Mọi lượt tải đều đi qua URL ký sẵn, nên ứng dụng lấy tệp thẳng từ CDN:

presigned_url = s3_client.generate_presigned_url(
    "get_object",
    Params={"Bucket": bucket_name, "Key": asset.file_path},
    ExpiresIn=3600,  # 1 hour
)

Bảo mật

#

Endpoint manifest được cố ý để không cần xác thực, vì ứng dụng phải nhận được bản cập nhật ngay cả khi chưa có ai đăng nhập. Endpoint nhập dữ liệu thì khác hẳn. Endpoint này ghi được vào cơ sở dữ liệu production, nên bắt buộc phải có một khóa bí mật dùng chung (shared secret), và phép so sánh khóa phải chạy trong thời gian không đổi (constant-time) để chặn tấn công định thời (timing attack):

IMPORT_TOKEN = os.getenv("IMPORT_TOKEN")

# Constant-time comparison prevents timing attacks
if not hmac.compare_digest(token, IMPORT_TOKEN):
    return Response({"error": "Invalid token"}, status=401)

Tính toàn vẹn của tài nguyên thì thiết kế đã lo sẵn: tệp nào cũng được đối chiếu với mã băm SHA-256 của nó, nên tài nguyên nào bị chỉnh sửa sẽ bị loại ngay. Ngoài ra, URL ký sẵn hết hạn sau một giờ, nên không ai dùng liên kết trực tiếp (hotlink) tới gói mã của bạn mãi được.

Giữ cho hệ thống chạy nhanh

#

Nhờ chỉ mục kết hợp (composite index) trên (runtime_version, platform, is_active, -created_at), truy vấn lấy manifest vẫn nhanh dù bản cập nhật có tích lại nhiều đến đâu:

class Meta:
    indexes = [
        models.Index(fields=["runtime_version", "platform", "is_active", "-created_at"])
    ]

Script phát hành tải tài nguyên lên song song:

with ThreadPoolExecutor(max_workers=10) as executor:
    futures = {executor.submit(upload_asset, asset): asset for asset in assets}
    for future in as_completed(futures):
        # Track progress

Với một bản cập nhật điển hình có khoảng 50 tài nguyên, thời gian phát hành giảm từ chừng 2 phút xuống còn 15 giây. Khâu phân phối thì không phải làm gì cả: Tigris tự lưu đệm tài nguyên ở các điểm biên (edge location) gần người dùng của bạn.

Quy trình làm việc hằng ngày

#

Trong lúc phát triển

#

# 1. Make code changes in the app
git commit -am "Fix bug"

# 2. Publish OTA update to local environment
./publish.sh ios

# 3. Test on device
# App automatically downloads and applies update

Đưa lên production

#

# 1. Publish to production
./publish.sh ios --production

# 2. Monitor
# Check Django admin for update records
# Verify assets in Tigris dashboard

Khôi phục về phiên bản trước

#

# Mark problematic update as inactive in Django admin
# or via management shell:
python manage.py shell

>>> from updates.models import ExpoUpdate
>>> bad_update = ExpoUpdate.objects.get(id="uuid-here")
>>> bad_update.is_active = False
>>> bad_update.save()

# Clients will now receive the previous active update

Chi phí thực tế

#

Ứng dụng này hiện có khoảng 500 người dùng hoạt động. Trên Tigris, ~200 MB các bản cập nhật tích lũy từ trước tới giờ tốn chừng $0.02/tháng, còn ~50 GB lưu lượng tải ra (egress) mỗi tháng từ các lượt tải bản cập nhật thì khoảng $1.00. Phần Django chạy ké trên chính máy chủ đang chạy API của tôi, nên không phát sinh thêm đồng nào. Tính tròn thì tổng cộng là một đô mỗi tháng. Với mức sử dụng tương tự, EAS Update sẽ rơi vào khoảng $300–500/năm, nên có thể nói hệ thống này hoàn vốn gần như ngay lập tức.

Giám sát và gỡ lỗi

#

Phần này chẳng có gì cầu kỳ. Viewset ghi nhật ký (log) mọi yêu cầu lấy manifest:

logger.info(f"Manifest request: platform={platform}, runtime={runtime_version}")

Trên thực tế, Django admin chính là bảng điều khiển. Chỉ cần đăng ký các mô hình là bạn xem và lọc được mọi thứ:

@admin.register(ExpoUpdate)
class ExpoUpdateAdmin(admin.ModelAdmin):
    list_display = ["platform", "runtime_version", "is_active", "created_at"]
    list_filter = ["platform", "is_active", "runtime_version"]
    search_fields = ["description"]

Còn ở phía máy khách, expo-updates sẽ cho bạn biết nó đang thấy gì:

import * as Updates from 'expo-updates';

Updates.checkForUpdateAsync().then(update => {
  console.log('Update available:', update.isAvailable);
  console.log('Manifest:', update.manifest);
});

Những cái bẫy

#

Lệch phiên bản runtime

#

Lỗi hay gặp nhất cũng là lỗi khó phát hiện nhất: máy khách chỉ tải những bản cập nhật khớp với phiên bản runtime của mình. Nếu ứng dụng đã cài đang ở runtime 1.0.0 mà bạn lại phát hành cho 1.0.1, thì sẽ chẳng có bản cập nhật nào về máy, mà cũng chẳng có lỗi nào báo ra. Hãy giữ phiên bản runtime đồng bộ với các bản dựng (build), và chỉ tăng nó khi phần mã native thay đổi.

Dấu thời gian createdAt

#

Thư viện expo-updates phía máy khách so sánh createdAt trong manifest với commitTime của gói mã nhúng sẵn, và chỉ áp dụng bản cập nhật nào có createdAt mới hơn. Trong viewset, tôi ghi đè giá trị này bằng dấu thời gian (timestamp) lấy từ cơ sở dữ liệu:

manifest_data["createdAt"] = update.created_at.strftime("%Y-%m-%dT%H:%M:%S.%fZ")

Khi phát triển trên máy cục bộ, nếu bạn dựng lại bản nhị phân của ứng dụng sau khi đã phát hành OTA, hãy phát hành lại bản OTA đó để dấu thời gian của nó mới hơn.

Giá trị key của tài nguyên trong manifest

#

Trường key trên mỗi tài nguyên trong manifest là thứ expo-updates dùng để lưu đệm, và giá trị này phải là một mã băm tất định (MD5 của tên tệp là được), chứ không phải UUID ngẫu nhiên hay một chuỗi tùy ý. Làm sai chỗ này thì máy khách có thể không lưu đệm hoặc không lấy lại được tài nguyên đúng cách, và bản cập nhật sẽ âm thầm hỏng sau lần tải thành công đầu tiên. Cảm ơn bạn đọc Raphael Mutschler đã chỉ ra lỗi này: bản cập nhật bên anh ấy chỉ chạy được đúng một lần, rồi anh mới tìm ra nguyên nhân.

Cấu hình ứng dụng trong expoClient

#

Nếu ứng dụng của bạn dùng Linking, Constants, hay bất cứ thứ gì đọc cấu hình ứng dụng (app config) lúc chạy, thì trường extra.expoClient trong manifest phải chứa cấu hình đó. Thiếu trường này, lúc đầu ứng dụng có thể vẫn mở lên bình thường, nhưng sau khi bị đóng thì bị sập (crash) hoặc không chịu mở lại nữa. Lý do là expo-updates thay manifest nhúng sẵn bằng manifest OTA, và nếu thiếu expoClient thì các API kia mất luôn phần cấu hình mà chúng dựa vào. Lỗi này cũng do Raphael Mutschler phát hiện.

Dọn dẹp tài nguyên

#

Các bản cập nhật cũ cứ thế chất đống trên Tigris. Hiện tại tôi vẫn dọn bằng tay:

# Delete updates older than 30 days
from datetime import timedelta
from django.utils import timezone

cutoff = timezone.now() - timedelta(days=30)
old_updates = ExpoUpdate.objects.filter(created_at__lt=cutoff, is_active=False)

for update in old_updates:
    # Delete assets from S3
    for asset in update.assets.all():
        s3_client.delete_object(Bucket=bucket_name, Key=asset.file_path)
    # Delete DB records
    update.delete()

Rõ ràng đoạn này nên được đưa vào một tác vụ chạy định kỳ (scheduled task). Chỉ là tôi chưa có thời gian làm.

Những thứ tôi muốn làm tiếp

#

(Tháng 9 năm 2026: Patch giờ đã có sẵn cả ba thứ này và hơn thế nữa; xem bài viết về đợt di chuyển.)

Phát hành theo từng đợt

#

Chỉ cần thêm một trường rollout_percentage là có thể phát hành bản cập nhật cho một phần người dùng trước:

rollout_percentage = models.IntegerField(default=100)

# In the manifest view:
if update.rollout_percentage < 100:
    # Hash user ID and check if they're in rollout group
    user_hash = int(hashlib.sha256(user_id.encode()).hexdigest(), 16)
    if (user_hash % 100) >= update.rollout_percentage:
        return Response(status=204)  # No update

Tách riêng bản cập nhật cho staging

#

Thêm một trường environment thì các bản dựng cho môi trường staging có thể nhận bản cập nhật khác với production:

environment = models.CharField(max_length=20, default="production")

# Client sends environment in custom header
environment = request.META.get("HTTP_X_UPDATE_ENVIRONMENT", "production")
update = ExpoUpdate.objects.filter(environment=environment, ...).first()

Thống kê lượt tải

#

Và một mô hình nhỏ nữa sẽ trả lời đàng hoàng câu hỏi “rốt cuộc đã có ai nhận được bản này chưa?”:

class ExpoUpdateDownload(models.Model):
    update = models.ForeignKey(ExpoUpdate, on_delete=models.CASCADE)
    user_id = models.CharField(max_length=255, null=True)
    platform = models.CharField(max_length=10)
    downloaded_at = models.DateTimeField(auto_now_add=True)

Tổng kết

#

Toàn bộ hệ thống chỉ gồm hai mô hình và vài view của Django, một script phát hành, và một đô mỗi tháng tiền hạ tầng. Ít hơn nhiều so với tôi nghĩ lúc bắt đầu, và từ đó tới nay nó vẫn lặng lẽ làm tốt việc của mình cho ứng dụng trên cả hai nền tảng.

Phần mã ở trên là các ví dụ đã được rút gọn từ chính ứng dụng đang chạy production đó, nên bạn cứ điều chỉnh cho hợp với dự án của mình. Còn nếu muốn bắt đầu từ một thứ đã chạy được sẵn, bạn đọc Raphael Mutschler cũng đã công bố một phiên bản độc lập của riêng anh ấy tại expo-ota-server.

Nếu bạn không muốn tự viết máy chủ

#

Từ lúc tôi viết bài này, đã có hai thứ xuất hiện làm được cùng việc mà không cần tới Django. Thứ nhất là expo-ota-server của Raphael ở trên. Thứ hai là Codemagic Patch: mã nguồn mở, chạy trên máy của chính bạn qua một bộ cài Docker Compose, và nói giao thức CodePush thay vì Expo Updates, nên bạn thay expo-updates bằng SDK của nó và thay eas update bằng cmpatch release-react. Nó dùng được kho lưu trữ tương thích S3, nên một bucket Tigris như trong bài này cũng chạy được.

Ngay từ đầu, nó đã có sẵn những thứ tôi liệt kê ở mục “Những thứ tôi muốn làm tiếp” mà chưa bao giờ xây: môi trường triển khai staging và production riêng, phát hành theo tỷ lệ phần trăm, số lượt tải và cài của từng bản, cập nhật bắt buộc, bản vá nhị phân, ký mã (code signing), và khôi phục (rollback) ngay trên thiết bị khi gói mã mới bị sập trước khi ứng dụng kịp báo sẵn sàng. Cái giá phải trả là một bản nhị phân native mới trước khi bất kỳ ai nhận được bản cập nhật qua Patch, vì SDK phải có trong ứng dụng, và một máy chủ phải vận hành thay cho một lệnh quản trị.

Tôi đã chuyển một ứng dụng của chính mình, với dự án native đã commit và quy trình phát hành thật, từ hệ thống trong bài này sang Patch. Bài viết đó kể lại những gì chạy tốt, những gì không, và thật sự thì khó tới mức nào. Codemagic tài trợ cho phần việc đó và có một lượt đọc duyệt về tính chính xác của sự kiện, chứ không phải duyệt biên tập.

Muốn đọc toàn bộ đặc tả, bạn tham khảo tài liệu đặc tả giao thức Expo Updates.