# Retool cho FDE: dựng công cụ nội bộ trong vài giờ, và biết lúc nào phải quay về React

> Retool có thể giúp bạn có bản demo ngay trong tuần đầu ở chỗ khách, nhưng chỉ khi bạn biết trước nó sẽ hết hiệu quả ở đâu.

Bản gốc: https://fdetimes.net/vi/cong-cu/retool-dung-cong-cu-noi-bo-nhanh-cho-khach/

Tuần đầu ở chỗ khách, thứ khách cần thấy nhiều khi chưa phải mô hình hay pipeline. Họ cần một màn hình để đội vận hành bấm vào và làm việc được. Chính Retool mô tả vấn đề nó giải quyết là cảnh các đội phải bỏ ra nhiều ngày kỹ sư để viết công cụ nội bộ từ con số không.

Với FDE, đó là bài toán quen thuộc. Bạn có quyền truy cập database của khách, có vài API nội bộ, và có một trưởng nhóm vận hành muốn duyệt yêu cầu mà không phải nhờ ai chạy SQL hộ. Retool đáng để bạn học vì nó nhắm thẳng vào những ngày kỹ sư bị tiêu tốn như thế. Có điều bạn phải biết nó dừng ở đâu.

## Retool thực ra là gì?

Trang chủ của Retool định vị sản phẩm là nền tảng để dựng, triển khai và quản lý công cụ nội bộ. Retool cho biết có hơn 10.000 đội đang dùng và có thể nối vào database, API hoặc LLM. Tài liệu chính thức chia nền tảng thành Apps, Agents, Workflows, Queries, Data Sources, Source Control, Administration và Permissions.

Điểm khiến Retool khác các công cụ no-code thuần túy là nó không giấu code đi. Query vào database được viết bằng SQL thô.

Retool coi mọi thứ nằm trong `{{ }}` là biểu thức JavaScript, và bạn viết được biểu thức như vậy ở gần như mọi chỗ trong app. Bạn cũng viết được cả JS query riêng.

Một developer quen SQL và JavaScript vì thế làm được việc ngay trong ngày đầu.

## Thử dựng một màn hình duyệt hoàn tiền

Giả sử khách là một công ty giao hàng. Đội chăm sóc khách hàng cần xem các đơn đang chờ hoàn tiền, lọc theo trạng thái và bấm duyệt. Dữ liệu đã có sẵn trong bảng `orders` của Postgres.

Bạn kéo vào một dropdown đặt tên `statusSelect` và một bảng dữ liệu, rồi viết query đọc dữ liệu, lấy giá trị lọc từ dropdown qua `{{ }}`:

```sql
select id, customer_name, amount, status
from orders
where status = {{ statusSelect.value }}
order by created_at desc
```

Tiếp theo bạn thêm nút "Duyệt" gắn với một query cập nhật thứ hai, dạng `update orders set status = 'refunded' where id = {{ table.selectedRow.id }}`, rồi cho bảng tải lại sau khi query chạy xong.

Lỗi hay gặp nhất ở bước này là gắn câu update thẳng vào nút mà không có lớp chặn nào. Một cú bấm nhầm thành một lần hoàn tiền nhầm. Nếu ai mở được app cũng bấm được nút, công cụ vừa dựng đã thành lỗ hổng.

Cách sửa tối thiểu bắt đầu ngay trong SQL: thêm `and status = 'pending'` vào điều kiện `where` để một đơn không thể bị duyệt hai lần. Bạn cũng có thể tự dựng thêm một lớp chặn, chẳng hạn một ô `reasonInput` bắt người duyệt ghi lý do, và thêm `and {{ reasonInput.value }} <> ''` vào câu update để nó không ghi gì khi ô còn trống.

Đừng mặc định nền tảng làm sẵn bước này; hãy đọc mục Permissions trong tài liệu Retool để giới hạn ai được dùng chức năng duyệt trước khi đưa app cho cả đội.

Tên component ở đây chỉ là ví dụ. Mọi thứ trong `{{ }}` là JavaScript nên bạn có thể định dạng số tiền, ẩn nút với những dòng đã duyệt, hay ghép chuỗi hiển thị mà không cần rời khỏi Retool.

Với một màn hình cỡ này, trưởng nhóm vận hành có thể có công cụ chạy trên dữ liệu thật chỉ sau một buổi chiều. Giá trị lớn nhất ở đây nằm ở vòng phản hồi chứ không phải bản thân màn hình.

Họ dùng thử vài ngày và cho bạn biết quy trình thực tế khác bản mô tả ban đầu ở chỗ nào, trước khi bạn kịp đầu tư vào một kiến trúc sai.

**Điểm mấu chốt:** Công cụ nội bộ dựng nhanh có giá trị vì nó cho bạn phản hồi thật sớm hơn vài tuần.

## Ba ranh giới bạn cần thấy trước

Ranh giới đầu tiên là giao diện. Retool có sẵn rất nhiều component, nhưng khi chúng không đáp ứng được, chẳng hạn khách cần một bản đồ tuyến giao hàng tương tác theo kiểu riêng, bạn phải tự viết custom component. Tài liệu ghi rõ custom component bắt buộc viết bằng React và TypeScript. Từ lúc đó bạn đang viết code frontend thật, có build và có bảo trì.

Ranh giới thứ hai là hạ tầng. Gói nào của Retool cũng cho phép self-host, điều này quan trọng với các khách ngân hàng hay y tế có yêu cầu dữ liệu không được rời hệ thống của họ.

Nhưng bản self-host chạy production được triển khai trên Kubernetes bằng Helm, và một số tính năng self-host nâng cao chỉ có ở gói Enterprise. Nếu đội IT của khách chưa từng vận hành Kubernetes, "dựng trong vài giờ" có thể biến thành vài tuần chờ hạ tầng.

Ranh giới thứ ba là người dùng. Retool tính giá riêng cho builder, người dùng nội bộ và người dùng bên ngoài như đối tác hay khách hàng của khách.

Khi yêu cầu chuyển từ "công cụ cho đội vận hành" sang "cổng cho tài xế đối tác", bài toán chi phí và phân quyền đã khác, và bạn nên nói rõ điều này với khách trước khi họ tự phát hiện ra.

## Đừng để tốc độ biến thành nợ

Lời chê quen thuộc dành cho công cụ low-code là app chạy được nhưng không ai biết ai đã sửa gì. Retool trả lời bằng Source Control: app, workflow, resource và theme được quản lý qua branch và pull request.

Retool cũng quảng bá mô hình quản trị trong đó đội nghiệp vụ làm nhanh còn IT vẫn nhìn thấy toàn bộ, để không phải dựng lại từ đầu trước khi lên production.

Với FDE, đây là chi tiết đáng giá nhất khi bàn giao. Một app Retool có lịch sử pull request rõ ràng là thứ đội kỹ thuật của khách có thể tiếp quản. Còn một app chỉ một người biết cách sửa sẽ là vấn đề họ phải gánh sau khi bạn rời dự án.

## Học gì trước?

Hãy học SQL cho chắc trước, vì gần như mọi màn hình Retool đều bắt đầu từ một query. Sau đó là JavaScript đủ để viết biểu thức gọn trong `{{ }}`. Kubernetes và React để sau, khi dự án thật sự cần đến.

Trong CV, đừng chỉ ghi "biết Retool". Hãy viết theo kiểu "dựng công cụ duyệt hoàn tiền trên Postgres cho đội vận hành trong một ngày, bàn giao qua pull request".

Khi đọc một JD FDE, hãy tự kiểm tra xem mô tả công việc có nhắc đến việc dựng công cụ nội bộ hay làm prototype nhanh cho khách không. Nếu có, đó là chỗ nên đưa ví dụ này lên đầu.

Retool không thay thế được việc viết phần mềm. Nó giúp bạn có thứ để khách dùng thử ngay trong tuần đầu, còn phần việc của bạn là biết lúc nào nên dừng lại và viết code thật.

**Thử ngay tuần này:**

- Tạo một app Retool nối vào một database Postgres thử nghiệm, viết một query có tham số lấy từ ô input qua &#123;&#123; &#125;&#125;, rồi thêm nút cập nhật trạng thái.
- Viết sẵn một checklist năm câu hỏi cho buổi discovery: dữ liệu nằm đâu, có bắt buộc self-host không, ai là người dùng (nội bộ hay đối tác), có cần UI đặc thù không, ai duyệt thay đổi.
- Bật Source Control, sửa app trên một branch và mở pull request để quen quy trình review.

## Nguồn

- [Build internal software better, with AI. | Retool](https://retool.com/)

- [About us](https://retool.com/about)

- [Retool Docs](https://docs.retool.com/)

- [Queries and code quickstart | Retool Docs](https://docs.retool.com/queries/quickstart)

- [Build custom React components | Retool Docs](https://docs.retool.com/apps/web/guides/components/custom)

- [Retool Pricing: Find the plan that works for you](https://retool.com/pricing)

- [Self-hosted deployments | Retool Docs](https://docs.retool.com/self-hosted)

- [Source Control documentation | Retool Docs](https://docs.retool.com/source-control)