Hola, I’m Hieu, a Software Engineer

supabase_flutter: auth, Postgres, realtime và storage supabase_flutter đáng chú ý vì nó giải quyết khởi tạo client có kiểu, auth event, RLS và lưu session. Bài này trình bày cách đặt package vào đúng boundary của một ứng dụng Flutter production thay vì chỉ copy một snippet vào màn hình. Package này sở hữu phần nào? Giữ API của package ở một adapter hoặc feature boundary có tên rõ ràng. Đưa lifecycle, lỗi và trạng thái loading vào contract mà UI có thể kiểm thử. Chỉ expose capability cần thiết; đừng để toàn app phụ thuộc vào chi tiết triển khai. Snippet bắt đầu await Supabase . initialize ( url : const String . fromEnvironment ( 'SUPABASE_URL' ), publishableKey : const String . fromEnvironment ( 'SUPABASE_KEY' ), ); final supabase = Supabase .instance.client; await supabase.auth. signInWithPassword ( email : email, password : password, ); Checklist trước khi ship Đọc README và changelog của package đúng version đang pin. Viết một...

supabase_flutter: auth, Postgres, realtime, and storage supabase_flutter is useful because it focuses on typed client initialization, auth events, RLS, and session persistence. The important engineering move is to place the package behind a clear boundary, so your Flutter UI depends on a stable capability rather than a vendor-shaped API. What the library should own Keep package calls inside a named adapter or feature boundary. Make lifecycle, errors, and loading state part of a testable contract. Expose only the capability the app needs; hide implementation details from the whole tree. A focused starting point await Supabase . initialize ( url : const String . fromEnvironment ( 'SUPABASE_URL' ), publishableKey : const String . fromEnvironment ( 'SUPABASE_KEY' ), ); final supabase = Supabase .instance.client; await supabase.auth. signInWithPassword ( email : email, password : password, ); Production checklist Read the README and c...

Serverpod là backend “không, bạn không cần học ba ngôn ngữ”: server Dart, client Flutter sinh tự động, tooling database kèm theo. Vì sao team chọn Type dùng chung hết lệch JSON. Auth và scaffolding database giảm lo trang trắng. Một toolchain cho hiring và CI. Cạm bẫy Lock-in full-stack là thật — giữ domain logic di động nếu có thể tách sau. Không để secret trong path code client sinh. Cân nhắc Serverpod khi team Flutter-first và muốn backend mạch lạc không đổi ngữ cảnh Node/Go. Bài viết gốc đăng tại FlutterCook . Bản trên đó là bản được cập nhật mới nhất.

Serverpod is the “no, you may not learn three languages” backend: Dart server, generated Flutter clients, database tooling included. Why teams pick it Shared types end JSON drift. Auth and database scaffolding reduce blank-page anxiety. One toolchain for hiring and CI. Pitfalls Full-stack lock-in is real — keep domain logic portable if you might split later. Do not put secrets in client-generated code paths. Consider Serverpod when the team is Flutter-first and wants a coherent backend without Node/Go context switching. Originally published on FlutterCook . Read the latest version there — that copy is the one kept up to date.

Appwrite Flutter: backend service với client rõ ràng appwrite đáng chú ý vì nó giải quyết cấu hình endpoint/project, auth, database, storage và function. Bài này trình bày cách đặt package vào đúng boundary của một ứng dụng Flutter production thay vì chỉ copy một snippet vào màn hình. Package này sở hữu phần nào? Giữ API của package ở một adapter hoặc feature boundary có tên rõ ràng. Đưa lifecycle, lỗi và trạng thái loading vào contract mà UI có thể kiểm thử. Chỉ expose capability cần thiết; đừng để toàn app phụ thuộc vào chi tiết triển khai. Snippet bắt đầu final client = Client () . setEndpoint ( 'https://cloud.appwrite.io/v1' ) . setProject (projectId); final account = Account (client); await account. createEmailPasswordSession ( email : email, password : password, ); Checklist trước khi ship Đọc README và changelog của package đúng version đang pin. Viết một test cho lifecycle, lỗi và hành vi khi app về background. Kiểm tra Android, iO...

Appwrite Flutter: backend services with explicit clients appwrite is useful because it focuses on endpoint/project configuration, auth, databases, storage, and functions. The important engineering move is to place the package behind a clear boundary, so your Flutter UI depends on a stable capability rather than a vendor-shaped API. What the library should own Keep package calls inside a named adapter or feature boundary. Make lifecycle, errors, and loading state part of a testable contract. Expose only the capability the app needs; hide implementation details from the whole tree. A focused starting point final client = Client () . setEndpoint ( 'https://cloud.appwrite.io/v1' ) . setProject (projectId); final account = Account (client); await account. createEmailPasswordSession ( email : email, password : password, ); Production checklist Read the README and changelog for the exact version you pin. Add one test for lifecycle, failure, and ap...

Serverpod removes JSON drift by generating typed Flutter clients from server methods. Bài này chuyển quan sát đó thành một mô hình nhỏ để bạn có thể kiểm thử, đo lường và giữ cho code dễ bảo trì khi app lớn lên. Vấn đề cốt lõi Generated clients, auth, and why Flutter-first teams pick Dart backends. Câu hỏi hữu ích không phải API hay pattern có đẹp riêng lẻ hay không, mà là state nằm ở đâu, boundary nào chịu trách nhiệm khi lỗi xảy ra, và người dùng phục hồi thế nào khi happy path biến mất. Mô hình thực tế Hiring and CI stay in one toolchain. Hãy bắt đầu bằng một owner rõ ràng cho behavior. Widget chỉ nên render và phát intent; IO, persistence, permission và retry nên nằm sau một interface nhỏ. Nhờ vậy bạn có seam để fake trong test và một chỗ ghi lại các dữ kiện cần theo dõi ở production. Trong app Flutter, boundary thường có dạng: Widget phát intent như load, submit, refresh hoặc retry. Controller hoặc use case validate intent rồi gọi boundary. Boundary trả về data có kiểu ...

Serverpod removes JSON drift by generating typed Flutter clients from server methods. This article turns that observation into a small implementation model you can test, measure, and keep boring when the app grows. The problem in one sentence Generated clients, auth, and why Flutter-first teams pick Dart backends. The useful question is not whether the API or pattern looks elegant in isolation. It is where state lives, which boundary owns failure, and how a user recovers when the happy path disappears. A practical model Hiring and CI stay in one toolchain. Start with one explicit owner for the behavior. Keep widgets responsible for rendering and user intent; keep IO, persistence, permissions, and retries behind a small interface. That gives you a seam for a fake in tests and a place to record the facts that matter in production. For a Flutter app, the boundary usually looks like this: The widget emits an intent such as load, submit, refresh, or retry. A controller or use case...

Thông báo tới nơi. Lúc thì ứng dụng hiển thị nó, lúc thì hệ điều hành, lúc chạm vào thì mở đúng màn hình còn lúc lại quăng người dùng ra trang chủ. Hành vi trông như ngẫu nhiên cho tới khi bạn nhìn ra cấu trúc bên dưới: cùng một tin nhắn đi theo bốn đường khác nhau tuỳ theo lúc đó ứng dụng đang làm gì. Trạng thái ứng dụng Ai hiển thị Handler nào chạy Chạy nổi Mặc định là không ai onMessage Chạy nền Hệ điều hành onBackgroundMessage (isolate riêng) Đã tắt hẳn Hệ điều hành onBackgroundMessage (isolate riêng) Được mở bằng cách chạm — onMessageOpenedApp , hoặc getInitialMessage nếu trước đó đã tắt hẳn Mọi lỗi thông báo tôi từng gỡ đều là một trong các dòng đó chưa được xử lý. Nối đủ bốn dòng thì phần lớn sự bí ẩn biến mất. Notification message so với data message Trước khi vào mã, đây là phân biệt quyết định mọi thứ: một payload FCM có thể chứa khối notification , khối data , hoặc cả hai. Có notification — hệ điều hành tự hiển thị khi ứng dụng chạy nề...

The notification arrives. Sometimes the app shows it, sometimes the system does, sometimes tapping it opens the right screen and sometimes it dumps the user on the home page. The behaviour feels random until you see the structure underneath: the same message takes four different paths depending on what the app was doing. App state Who displays it Which handler runs Foreground Nobody, by default onMessage Background The OS onBackgroundMessage (separate isolate) Terminated The OS onBackgroundMessage (separate isolate) Opened by tapping — onMessageOpenedApp , or getInitialMessage if it was terminated Every notification bug I have debugged was one of those rows being unhandled. Wire all four and most of the mystery disappears. Notification messages versus data messages Before the code, the distinction that determines everything: an FCM payload can contain a notification block, a data block, or both. notification present — the OS displays it automa...

Thông báo tới nơi. Lúc thì ứng dụng hiển thị nó, lúc thì hệ điều hành, lúc chạm vào thì mở đúng màn hình còn lúc lại quăng người dùng ra trang chủ. Hành vi trông như ngẫu nhiên cho tới khi bạn nhìn ra cấu trúc bên dưới: cùng một tin nhắn đi theo bốn đường khác nhau tuỳ theo lúc đó ứng dụng đang làm gì. Trạng thái ứng dụng Ai hiển thị Handler nào chạy Chạy nổi Mặc định là không ai onMessage Chạy nền Hệ điều hành onBackgroundMessage (isolate riêng) Đã tắt hẳn Hệ điều hành onBackgroundMessage (isolate riêng) Được mở bằng cách chạm — onMessageOpenedApp , hoặc getInitialMessage nếu trước đó đã tắt hẳn Mọi lỗi thông báo tôi từng gỡ đều là một trong các dòng đó chưa được xử lý. Nối đủ bốn dòng thì phần lớn sự bí ẩn biến mất. Notification message so với data message Trước khi vào mã, đây là phân biệt quyết định mọi thứ: một payload FCM có thể chứa khối notification , khối data , hoặc cả hai. Có notification — hệ điều hành tự hiển thị khi ứng dụng chạy nề...

Thông báo tới nơi. Lúc thì ứng dụng hiển thị nó, lúc thì hệ điều hành, lúc chạm vào thì mở đúng màn hình còn lúc lại quăng người dùng ra trang chủ. Hành vi trông như ngẫu nhiên cho tới khi bạn nhìn ra cấu trúc bên dưới: cùng một tin nhắn đi theo bốn đường khác nhau tuỳ theo lúc đó ứng dụng đang làm gì. Trạng thái ứng dụng Ai hiển thị Handler nào chạy Chạy nổi Mặc định là không ai onMessage Chạy nền Hệ điều hành onBackgroundMessage (isolate riêng) Đã tắt hẳn Hệ điều hành onBackgroundMessage (isolate riêng) Được mở bằng cách chạm — onMessageOpenedApp , hoặc getInitialMessage nếu trước đó đã tắt hẳn Mọi lỗi thông báo tôi từng gỡ đều là một trong các dòng đó chưa được xử lý. Nối đủ bốn dòng thì phần lớn sự bí ẩn biến mất. Notification message so với data message Trước khi vào mã, đây là phân biệt quyết định mọi thứ: một payload FCM có thể chứa khối notification , khối data , hoặc cả hai. Có notification — hệ điều hành tự hiển thị khi ứng dụng chạy nề...