mistercrunch commented on issue #33441: URL: https://github.com/apache/superset/issues/33441#issuecomment-2895800118
About all this and the recent community meeting, I worked with GPT at producing this -> ## On Shared Primitives and API Boundaries Following a recent community meeting, an important question came up around how we structure our frontend packages — specifically, which packages should exist, how they depend on each other, and what should be labeled as **public vs private**. One of the key debates was around the **bucket of shared primitives** — a collection of utility functions, components, types, and hooks that are used across the Superset app and SDKs. Here, I’ll make the case that this shared primitives package should be treated as **private**, and that **each SDK should be in charge of deciding**: - which primitives it wants to use internally, and - which it chooses to expose publicly as part of its API. --- ### Why shared ≠ public Just because a function or component is reused doesn't mean it should be exposed. Making all shared primitives public: - **Bloats the API surface** — every internal helper becomes part of the public contract. - **Creates upgrade friction** — a breaking change in a low-level primitive could break all SDKs that import it directly. - **Encourages misuse** — consumers may depend on primitives not meant for external use. - **Makes versioning harder** — users can't easily tell which version of the primitives is compatible with which version of the SDK. --- ### A better model: SDKs as curators - Each SDK should act as a **curated public interface**, exposing only what it wants to support and maintain. - Internally, SDKs are free to use any primitive from the shared package. - Each SDK declares which **version** of the primitives it depends on. - In the case of the extension SDK, it can also declare which app version(s) it’s compatible with. This keeps each SDK **self-standing**, with clear boundaries and better long-term maintainability. --- ### Examples of shared-but-private code These are good candidates to share internally, but not expose: - Utility functions like `formatTimeRange`, `parseSqlExpression`, `isFeatureEnabled` - Low-level UI components like `<Space />`, `<Timer />`, `<PermissionGate />` - Internal hooks like `useDebouncedValue`, `usePrevious` These are useful building blocks for the app and SDKs, but they’re not meant to be part of the public API surface. --- ### Final Thoughts Let’s make sure we’re building **modular, maintainable** packages — not a sprawling framework. Shared primitives should power our ecosystem, but **SDKs should be the ones deciding what’s public**. Keep the internals flexible. Keep the public APIs tight. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
