Backstage Community Plugins: Kho plugin cộng đồng bạn nên biết

Nếu bạn đang dùng Backstage để xây dựng Internal Developer Portal cho team, chắc chắn bạn đã từng đau đầu với câu hỏi: plugin mình cần có sẵn chưa, hay phải tự build từ đầu? Và nếu có sẵn thì nó nằm ở đâu, ai maintain, còn được update không?

Đó chính xác là vấn đề mà repo backstage/community-plugins sinh ra để giải quyết.

Tại sao lại có repo này?

Trước đây, tất cả plugin - cả core lẫn community - đều nằm chung trong repo backstage/backstage. Nghe có vẻ tiện, nhưng thực tế thì rất lộn xộn. Maintainer của một plugin nhỏ phải follow toàn bộ release cycle của core Backstage, mọi thứ bị couple chặt vào nhau, và team Backstage core thì phải review PR từ hàng trăm plugin khác nhau.

Vậy là họ quyết định tách ra. Plugin nào là core functionality thì vẫn giữ trong backstage/backstage. Còn plugin do cộng đồng đóng góp thì chuyển sang backstage/community-plugins - nơi mỗi plugin có thể có release cycle riêng, maintainer riêng, và không bị block bởi những thứ không liên quan.

Theo kinh nghiệm của mình, đây là một quyết định kiến trúc rất đúng đắn. Khi bạn có một monorepo khổng lồ với quá nhiều concerns khác nhau, mọi thứ đều chậm lại - CI chậm, review chậm, release chậm. Tách ra thành các workspace độc lập là cách để scale cộng đồng open source một cách bền vững.

Cấu trúc Workspace - Cái này khá thú vị

Repo này không tổ chức theo kiểu "mỗi plugin một folder" đơn giản. Thay vào đó, nó dùng khái niệm workspace.

Mỗi workspace đại diện cho một topic hoặc domain cụ thể. Ví dụ:

• catalog - các plugin liên quan đến Software Catalog
• kubernetes - plugin để integrate với K8s
• techdocs - plugin cho TechDocs
• jenkins, github-actions, datadog, v.v.

Một workspace có thể chứa một hoặc nhiều plugin liên quan. Điểm hay là mỗi workspace có changesets và release cycle riêng biệt. Nghĩa là nếu team bạn chỉ dùng plugin kubernetes, bạn không bị ảnh hưởng khi team jenkins release version mới.

Và nếu một workspace lớn đến mức cần tách ra thành repo riêng hoàn toàn, cấu trúc này cũng cho phép làm điều đó mà không cần refactor quá nhiều - vì workspace đã được thiết kế để portable từ đầu.

1community-plugins/
2├── workspaces/
3│   ├── catalog/
4│   │   ├── plugins/
5│   │   │   ├── catalog-backend-module-xxx/
6│   │   │   └── catalog-frontend-xxx/
7│   │   └── package.json
8│   ├── kubernetes/
9│   │   ├── plugins/
10│   │   └── package.json
11│   └── techdocs/
12│       ├── plugins/
13│       └── package.json
14├── scripts/
15├── docs/
16└── package.json

Các plugin trong cùng một workspace phụ thuộc vào nhau qua npm dependencies bình thường - không có magic gì đặc biệt ở đây, rất transparent và dễ hiểu.

Contribute plugin vào đây thì sao?

Nếu bạn đã build một plugin Backstage cho internal use và muốn share với cộng đồng, đây là nơi phù hợp. Quy trình khá rõ ràng:

Bước 1: Tạo workspace mới

Repo có sẵn script để scaffold workspace:

1yarn create-workspace

Script này sẽ hỏi bạn tên workspace, rồi tự tạo cấu trúc thư mục chuẩn.

Bước 2: Develop plugin trong workspace

Mỗi workspace dùng Yarn workspaces, nên bạn có thể chạy dev server, test, build độc lập:

1# Từ root của repo
2yarn workspace @backstage-community/plugin-your-plugin start
3
4# Hoặc cd vào workspace
5cd workspaces/your-workspace
6yarn start

Bước 3: Dùng changesets để version

Repo này dùng Changesets để quản lý versioning. Mỗi khi bạn có thay đổi đáng kể:

1yarn changeset

Nó sẽ hỏi bạn loại thay đổi (patch/minor/major) và tạo một changeset file. Khi merge vào main, CI sẽ tự động tạo release PR.

Bước 4: Submit PR và follow review process

Khi contribute, bạn đồng ý follow guidelines của repo - bao gồm coding standards, testing requirements, và release process. Đổi lại, bạn được leverage toàn bộ infrastructure CI/CD, tooling, và community support mà repo đã setup sẵn.

Self-host vs Contribute - Nên chọn cái nào?

Đây là câu hỏi mình hay thấy anh em băn khoăn. Câu trả lời phụ thuộc vào use case:

Theo mình thì: nếu plugin của bạn là generic - ví dụ integrate với một tool phổ biến như Grafana, PagerDuty, hay một cloud provider - thì contribute vào community-plugins là win-win. Bạn không phải tự maintain infrastructure, và cộng đồng được hưởng lợi.

Nhưng nếu plugin chứa business logic đặc thù của công ty, hoặc bạn cần release rất nhanh mà không muốn đợi review, thì self-host là hợp lý hơn.

Dùng plugin từ repo này như thế nào?

Các plugin trong community-plugins được publish lên npm dưới scope @backstage-community. Install bình thường thôi:

1# Ví dụ install plugin kubernetes
2yarn workspace app add @backstage-community/plugin-kubernetes
3yarn workspace backend add @backstage-community/plugin-kubernetes-backend

Rồi config trong app-config.yaml và wire vào app theo docs của từng plugin. Không có gì khác so với cách bạn install plugin Backstage thông thường.

Anh em lưu ý một điều: vì mỗi workspace có release cycle riêng, version của các plugin trong community-plugins không đồng bộ với nhau. Plugin A có thể đang ở v1.5.0 trong khi plugin B mới ở v0.3.0. Check changelog của từng plugin riêng trước khi upgrade.

Tình trạng hiện tại của repo

Tính đến thời điểm mình viết bài này, repo có:

• 8,651 commits - cho thấy activity khá cao
• 627 forks và 384 stars
• 90 open issues và 272 open PRs - cộng đồng đang active

Có một file ARCHIVED_WORKSPACES.md trong repo - đây là danh sách các workspace đã bị archive. Nếu bạn đang dùng một plugin nào đó từ community-plugins mà không thấy update lâu rồi, check file này xem nó có bị archive không. Archived workspace thường có nghĩa là plugin đó không còn được maintain tích cực nữa.

Mình thấy cái này hay ở chỗ họ không xóa hẳn mà archive - vẫn còn code để reference, nhưng rõ ràng về trạng thái maintenance. Transparent hơn nhiều so với việc để plugin chết âm thầm.

Tooling và Developer Experience

Repo setup khá professional. Có .devcontainer config nên bạn có thể mở bằng GitHub Codespaces hoặc VS Code Dev Container mà không cần setup local environment. Với repo có nhiều workspace như này, cái .devcontainer tiết kiệm khá nhiều thời gian onboarding.

ESLint config được share ở root level, Husky hooks cho pre-commit checks, và Yarn Berry (v4) với PnP. Nếu bạn chưa quen với Yarn Berry, có thể mất một chút thời gian để quen với cách nó resolve dependencies khác với Yarn classic, nhưng nhìn chung không có gì quá phức tạp.

Có thêm một điểm thú vị: repo có folder .claude/skills/ với một migration script mui-to-bui-migration - đây là script hỗ trợ AI (Claude) để tự động migrate từ Material UI sang Backstage UI components. Backstage đang dần move sang component library riêng của họ (BUI), và cái này cho thấy họ đang dùng AI để hỗ trợ quá trình migration đó. Khá forward-thinking.

Nếu team bạn đang build hoặc evaluate Backstage, backstage/community-plugins là repo nên bookmark ngay. Trước khi bắt đầu build plugin mới, check ở đây trước - rất có thể đã có người build rồi và bạn chỉ cần install và config là xong.