Principle:Langgenius Dify Plugin Discovery
| Knowledge Sources | Dify |
|---|---|
| Domains | Plugin_System, Marketplace, Frontend |
| Last Updated | 2026-02-12 00:00 GMT |
Overview
Description
Plugin Discovery governs how the Dify frontend locates, searches, and browses available plugins and bundles from the Dify Marketplace. The principle mandates a contract-first API design using oRPC (typed RPC contracts), ensuring that every marketplace interaction is statically typed at compile time. Three discrete contracts define the entire discovery surface: listing curated collections, retrieving plugins within a specific collection, and performing advanced searches across plugins or bundles. By encoding route paths, HTTP methods, input shapes, and output shapes directly in TypeScript contract definitions, the system eliminates runtime type mismatches between the frontend and the marketplace API.
The contract-first approach means that the API shape is declared once in a shared contract module (web/contract/marketplace.ts) and consumed by both the query layer and any generated client code. This prevents drift between what the frontend expects and what the marketplace actually returns.
Usage
Plugin Discovery is used whenever a user opens the Dify Marketplace interface, browses curated collections of plugins, navigates into a specific collection to see its plugins, or performs a keyword/category/tag search. The three contracts cover these scenarios:
- collectionsContract -- retrieves paginated lists of curated marketplace collections (e.g., "Recommended Tools", "Popular Models").
- collectionPluginsContract -- fetches all plugins belonging to a specific collection, identified by
collectionId. - searchAdvancedContract -- powers the advanced search with sorting, category filtering, tag filtering, and pagination, supporting both
pluginsandbundlesas search targets.
Theoretical Basis
The contract-first pattern is rooted in the Design by Contract principle (Bertrand Meyer, 1986), adapted for HTTP APIs. By expressing the full API surface as typed contracts, the system achieves:
- Static verification -- TypeScript's type system catches mismatches between expected and actual request/response shapes at compile time rather than runtime.
- Single source of truth -- The contract file serves as both documentation and enforcement. Developers consult one file to understand the full marketplace discovery API.
- Separation of concerns -- The contract layer is decoupled from the transport layer. The same contract can drive different HTTP clients, mock servers, or test fixtures.
- Parametric polymorphism -- The
searchAdvancedContractuses a union type ('plugins' | 'bundles') for thekindpath parameter, allowing a single contract to serve two distinct resource types without duplication.
The oRPC library's type<T>() utility leverages TypeScript's generic inference to produce zero-runtime-overhead type constraints, meaning contracts add no bundle size cost.