diff --git a/website/docs/components/cli.md b/website/docs/building/cli.md similarity index 99% rename from website/docs/components/cli.md rename to website/docs/building/cli.md index fd92f8d..ea1b972 100644 --- a/website/docs/components/cli.md +++ b/website/docs/building/cli.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 2 ---- - # Command Line Tool ## Prerequisites diff --git a/website/docs/building/debugging.md b/website/docs/building/debugging.md index 62f633a..8e02ed9 100644 --- a/website/docs/building/debugging.md +++ b/website/docs/building/debugging.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 3 ---- - # Debugging ## General Debugging Principles diff --git a/website/docs/components/getting-started.md b/website/docs/building/getting-started.md similarity index 95% rename from website/docs/components/getting-started.md rename to website/docs/building/getting-started.md index 9383fa4..1316825 100644 --- a/website/docs/components/getting-started.md +++ b/website/docs/building/getting-started.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 1 ---- - # Getting Started ## Prerequisites @@ -152,7 +148,7 @@ Explore these example repositories to see OpenComponents in action: ## Troubleshooting Common Issues -- For installation problems, component creation errors, or dev-server hiccups, refer to the in-depth [CLI guide](cli.md#troubleshooting) which contains up-to-date solutions. +- For installation problems, component creation errors, or dev-server hiccups, refer to the in-depth [CLI guide](cli#installation-troubleshooting) which contains up-to-date solutions. ## Next Steps @@ -161,7 +157,7 @@ Once you've created your first component: 1. **[Learn the CLI](cli)** - Master all available commands 2. **[Understand package.json structure](package.json-structure)** - Configure your component properly 3. **[Add server-side logic](the-server.js)** - Make your component dynamic -4. **[Publish to a registry](publishing-to-a-registry)** - Share your component +4. **[Publish to a registry](../registry/publishing-to-a-registry)** - Share your component 5. **[Explore client-side operations](../consumers/rendering-lifecycle)** - Advanced browser integration For a complete hands-on tutorial, see our [Quick Start Tutorial](../quick-start-tutorial). diff --git a/website/docs/building/index.md b/website/docs/building/index.md index 69161ee..ba09098 100644 --- a/website/docs/building/index.md +++ b/website/docs/building/index.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 0 ---- - # Building Components Everything you need to create production-ready micro-frontends. diff --git a/website/docs/components/package.json-structure.md b/website/docs/building/package.json-structure.md similarity index 99% rename from website/docs/components/package.json-structure.md rename to website/docs/building/package.json-structure.md index e4cf8b4..15fee19 100644 --- a/website/docs/components/package.json-structure.md +++ b/website/docs/building/package.json-structure.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 3 ---- - # Structure of package.json ## Overview @@ -316,5 +312,5 @@ ls -la public/ - **[Learn server.js structure](the-server.js)** - Add dynamic data to your components - **[Understand CLI commands](cli)** - Master component development workflow -- **[Publishing guide](publishing-to-a-registry)** - Deploy your components +- **[Publishing guide](../registry/publishing-to-a-registry)** - Deploy your components - **[Template system](../building/template-system)** - Choose the right template type diff --git a/website/docs/building/template-system.md b/website/docs/building/template-system.md index 0f3acb5..c713361 100644 --- a/website/docs/building/template-system.md +++ b/website/docs/building/template-system.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 2 ---- - # Template System ## Introduction @@ -42,7 +38,7 @@ Usage: $ oc init myComponent oc-template-jade # Legacy template - ES6 recommended for new components ``` -Check the [CLI documentation](/docs/components/cli) for more details. +Check the [CLI documentation](/docs/building/cli) for more details. ### On the Registry @@ -56,7 +52,7 @@ templates: [require('oc-template-extra'), require('oc-template-plus')] } ``` -Check the [registry configuration guide](/docs/registry/registry-configuration#registry-configuration) for more details. +Check the [registry configuration guide](/docs/registry/registry-configuration#configuration-reference) for more details. ### Client-side rendering diff --git a/website/docs/components/the-server.js.md b/website/docs/building/the-server.js.md similarity index 98% rename from website/docs/components/the-server.js.md rename to website/docs/building/the-server.js.md index 3ab9cc5..2205d3e 100644 --- a/website/docs/components/the-server.js.md +++ b/website/docs/building/the-server.js.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 4 ---- - # Server-side Logic (server.js / entry.server.ts) This guide covers how to add server-side logic to your components. Modern components use `src/entry.server.ts` with the `Server` API, while the legacy `server.js` with callbacks is still supported for backwards compatibility. @@ -288,9 +284,9 @@ Context aggregates request data, and the registry's context. It consists of the | ------------------ | -------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `acceptLanguage` | `array of objects` | represents parsed `accept-language` part of the request header sorted by quality. More details [here](https://github.com/opentable/accept-language-parser) | | `baseUrl` | `string` | represents public registry base url. This is required when we want to nest components that are hosted in the same registry for client-side rendering | -| `env` | `object` | represents the registry environment variables. The registry's admin [can share here arbitrary data](/docs/registry/registry-configuration#registry-configuration) | +| `env` | `object` | represents the registry environment variables. The registry's admin [can share here arbitrary data](/docs/registry/registry-configuration#configuration-reference) | | `params` | `object` | represents parameters extracted from the query string | -| `plugins` | `array of functions` | [custom functionalities that extend the registry](/docs/registry/registry-configuration#plugins). Note: if a component needs a plugin, [it needs to be declared in the component's package.json](/docs/components/getting-started#structure-of-the-package) | +| `plugins` | `array of functions` | [custom functionalities that extend the registry](/docs/registry/registry-configuration#plugins). Note: if a component needs a plugin, [it needs to be declared in the component's package.json](/docs/building/getting-started#structure-of-the-package) | | `renderComponent` | `function` | Needed to do server-side nested renderings. [renderComponent API](#rendercomponent-api) | | `renderComponents` | `function` | Needed to do server-side nested renderings. [renderComponents API](#rendercomponents-api) | | `requestHeaders` | `object` | represents the original request headers. When component is rendered client side this will be what is sent from the browser, when rendered server side, using oc-client, this will contain whatever the client has been configured to forward | @@ -523,5 +519,5 @@ module.exports.data = function (context, callback) { - **[Learn package.json structure](package.json-structure)** - Configure your component properly - **[Master the CLI](cli)** - Efficient development workflow -- **[Publishing guide](publishing-to-a-registry)** - Deploy your components +- **[Publishing guide](../registry/publishing-to-a-registry)** - Deploy your components - **[Client-side operations](../consumers/rendering-lifecycle)** - Browser integration patterns diff --git a/website/docs/components/_category_.json b/website/docs/components/_category_.json deleted file mode 100644 index 32d855a..0000000 --- a/website/docs/components/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Components", - "position": 1 -} diff --git a/website/docs/concepts/architecture-overview.md b/website/docs/concepts/architecture-overview.md index d118099..09d4d5f 100644 --- a/website/docs/concepts/architecture-overview.md +++ b/website/docs/concepts/architecture-overview.md @@ -1,104 +1,20 @@ ---- -sidebar_position: 3 ---- - # Architecture Overview -
- -## How OpenComponents Works - -OpenComponents is a **micro frontend architecture** that breaks down monolithic applications into independently deployable, reusable components that teams can own and maintain autonomously. - -
- -## Conceptual Overview - -
- -### πŸ›’ **Real-World Example: E-commerce Platform** - -Instead of building one massive application, imagine decomposing it into independent components: - -
- -**🏠 Header Component** β†’ Platform Team -- Navigation, search, user menu -- Deployed independently -- Shared across all pages - -**πŸ“¦ Product Listing** β†’ Catalog Team -- Product cards, filters, pagination -- A/B test new layouts -- Optimized for performance - -**πŸ›’ Shopping Cart** β†’ Commerce Team -- Cart state, checkout flow -- Payment integrations -- Independent scaling - -**πŸ‘€ User Profile** β†’ Identity Team -- Authentication, preferences -- Privacy controls -- Account management - -
- -**The Result:** Each team develops, tests, and deploys independently while users see a seamless, integrated experience. - -
- -## Benefits of This Approach - -
- -### πŸš€ **Team Independence** -- **Autonomous development** - No coordination bottlenecks -- **Technology flexibility** - React, Vue, ES6, or any framework per component -- **Independent deployments** - Release on your own schedule -- **Clear ownership** - Teams own components end-to-end - -### πŸ“ˆ **Scalability & Performance** -- **Component-level scaling** - Scale based on actual usage patterns -- **CDN optimization** - Automatic asset distribution globally -- **Server-side rendering** - SEO and performance without Node.js requirements -- **Caching strategies** - Intelligent caching at multiple levels - -### πŸ”„ **Gradual Migration** -- **Start small** - Begin with one component, expand gradually -- **No big bang** - Migrate from monolith incrementally -- **Risk mitigation** - Test architecture with non-critical components -- **Backward compatibility** - Existing applications continue working - -
- -## Why Choose OpenComponents? - -### Team Independence +OpenComponents breaks down monolithic frontends into independently deployable, reusable components that teams can own and maintain autonomously. For the motivation behind this, see [Why OpenComponents?](why-opencomponents). -- **Autonomous development**: Teams work on their components without blocking each other -- **Technology flexibility**: Use React, Vue, ES6, or any framework per component -- **Independent deployments**: Release updates without coordinating with other teams -- **Clear ownership**: Each team owns their components end-to-end +## Example decomposition -### Gradual Migration +A typical e-commerce page could be decomposed into independent components, each owned by a different team: -- **Start small**: Begin with one component and gradually expand -- **No big bang**: Migrate from monolith to micro frontends incrementally -- **Risk mitigation**: Test the architecture with non-critical components first -- **Backward compatibility**: Existing applications continue working during migration +- **Header** (Platform team) – navigation, search, user menu; deployed independently, shared across pages. +- **Product listing** (Catalog team) – product cards, filters, pagination. +- **Shopping cart** (Commerce team) – cart state, checkout flow, payment integrations. +- **User profile** (Identity team) – authentication, preferences, account management. -### A/B Testing and Experimentation - -- **Component-level testing**: Test different versions of individual components -- **Isolated experiments**: Changes to one component don't affect others -- **Faster iteration**: Deploy and test new features quickly -- **Data-driven decisions**: Measure impact of component changes independently +Each team develops, tests, and deploys independently, while users see one seamless, integrated page. ## System Architecture -
- ```mermaid graph TB subgraph "Development" @@ -140,53 +56,12 @@ graph TB style CLI fill:#9C27B0 ``` -
- -### πŸ—οΈ **Core Components** - -
- -
- -#### **πŸ› οΈ CLI & Development Tools** -- Component scaffolding and development -- Local testing with hot reload -- Publishing and version management -- Built-in preview and debugging tools - -
- -
- -#### **🌐 Registry (REST API)** -- Central component catalog and metadata -- Version management and resolution -- Authentication and access control -- Component rendering and serving - -
- -
- -#### **πŸ“¦ Component Library** -- Immutable component storage -- Version history and artifacts -- Dependency management -- Backup and disaster recovery +### Core components -
- -
- -#### **πŸš€ CDN & Asset Distribution** -- Global static asset delivery -- Automatic optimization and compression -- Edge caching for performance -- Bandwidth cost optimization - -
- -
+- **CLI & development tools** – component scaffolding, local dev server with hot reload, publishing, preview and debugging. +- **Registry (REST API)** – component catalog and metadata, version resolution, authentication, rendering. +- **Component library** – immutable storage of published component versions and artifacts. +- **CDN & asset distribution** – static assets (JS, CSS, images) served from CDN with edge caching. ## Publishing Workflow @@ -293,27 +168,7 @@ Results: **Best Practices**: -- βœ… **Use semantic versioning**: `~1.2.0` instead of `1.2.4` -- βœ… **Short polling intervals**: 5-second sync reduces inconsistency window -- βœ… **Monitoring & alerting**: Track registry sync health -- βœ… **Graceful degradation**: Serve cached versions during outages - -### Advanced Distribution Features - -**πŸ”„ Automatic Failover** - -- Registry instances automatically retry failed CDN connections -- Components remain available from memory cache during outages -- Health checks detect and route around unhealthy instances - -**πŸ“Š Monitoring Integration** - -- Registry publishes events for sync failures and recoveries -- Metrics tracking for component usage and performance -- Alerting for version inconsistencies across regions - -**πŸš€ Performance Optimization** - -- Template deduplication across component versions -- Intelligent caching based on usage patterns -- CDN edge caching for global distribution +- **Use semantic versioning**: prefer `~1.2.0` over pinning `1.2.4`, so consumers tolerate a registry serving a slightly older patch during the sync window +- **Short polling intervals**: the default 5-second `pollingInterval` keeps the inconsistency window small +- **Monitoring**: subscribe to the [registry's events](../registry/registry-configuration#registryoneventname-callback) to track sync health +- **Fallback registries**: configure [`fallbackRegistryUrl`](../registry/registry-configuration#configuration-reference) so requests can be served by a secondary registry if a component isn't found locally diff --git a/website/docs/concepts/index.md b/website/docs/concepts/index.md index f5500a4..51cf633 100644 --- a/website/docs/concepts/index.md +++ b/website/docs/concepts/index.md @@ -1,76 +1,6 @@ ---- -sidebar_position: 1 ---- - # Core Concepts -Learn about the fundamental concepts that make OpenComponents a powerful solution for micro frontend architecture. - -
- -
- -## πŸ€” **Why OpenComponents?** - -Understand the problems OpenComponents solves and when to choose it over other micro frontend solutions. - -**Key topics:** -- Team independence and autonomy -- Server-side rendering without Node.js -- Immutable, versioned deployments -- Language-agnostic consumption - -[**Learn Why β†’**](why-opencomponents) - -
- -
- -## πŸ—οΈ **Architecture Overview** - -Deep dive into how OpenComponents works under the hood and how all the pieces fit together. - -**Key topics:** -- Component lifecycle and publishing -- Registry and library architecture -- Distribution and replication -- Performance optimization - -[**Explore Architecture β†’**](architecture-overview) - -
- -
- -## Quick Concept Reference - -
- -### **Components** -Independent, reusable UI pieces with their own HTML, CSS, JavaScript, and optional server-side logic. - -### **Registry** -REST API that manages component publishing, versioning, and consumption across your organization. - -### **Library & CDN** -Storage system for published components with automatic static asset distribution via CDN. - -### **CLI** -Command-line tools for component development, testing, and publishing workflows. - -### **Consumers** -Applications, websites, or services that render and display OpenComponents in their user interfaces. - -
- -## Understanding the Ecosystem - -OpenComponents creates an ecosystem where: - -1. **πŸ‘₯ Teams develop independently** - Each team owns their components end-to-end -2. **πŸ”„ Components are versioned** - Semantic versioning enables safe updates and rollbacks -3. **🌐 Consumption is universal** - Any backend can render components via HTTP -4. **⚑ Performance is optimized** - CDN distribution and caching maximize speed -5. **πŸ”’ Deployments are safe** - Immutable artifacts prevent breaking changes +Learn about the fundamental concepts that make OpenComponents a micro frontend solution. -Ready to dive deeper? Choose a concept above to explore in detail. +- [**Why OpenComponents?**](why-opencomponents) – the problem it solves, its key benefits, and how it compares to alternatives like Module Federation, SPAs, and iframes. +- [**Architecture Overview**](architecture-overview) – how components, the registry, storage, and CDN fit together, including the publishing and distribution flow. diff --git a/website/docs/concepts/why-opencomponents.md b/website/docs/concepts/why-opencomponents.md index f99f146..d6abf65 100644 --- a/website/docs/concepts/why-opencomponents.md +++ b/website/docs/concepts/why-opencomponents.md @@ -1,189 +1,66 @@ ---- -sidebar_position: 2 ---- - # Why OpenComponents? -
- ## A Pragmatic, Language-Agnostic Approach to Micro Frontends -OpenComponents enables **multiple autonomous teams** to own different parts of the UI while maintaining seamless integration across diverse technology stacks. - -
- -## The Problem We Solve - -
- -### 🚫 **The Monolith Problem** - -- **Coordination overhead** - All teams must align on releases -- **Technology lock-in** - Everyone uses the same framework and build tools -- **Deployment bottlenecks** - One team's issues block everyone else -- **Scaling challenges** - Codebase becomes unwieldy as teams grow - -### βœ… **The OpenComponents Solution** - -- **Independent development** - Teams work autonomously with their preferred tools -- **Flexible deployment** - Release components on your own schedule -- **Technology freedom** - Mix React, Vue, vanilla JS, or any framework -- **Scalable architecture** - Add teams and components without complexity overhead - -
- -## Key Benefits - -
- -
- -### πŸ–₯️ **Server-Side Rendering Without Node.js** - -The OpenComponents Registry renders components server-side and returns ready-to-inject HTML to **any host technology**β€”C#, PHP, Java, Go, Python, Ruby. - -**Benefits:** -- βœ… SEO optimization and fast first paint -- βœ… No JavaScript runtime required on your edge servers -- βœ… Works with existing backend infrastructure -- βœ… Graceful degradation when registry is unavailable - -
- -
- -### πŸ”’ **Immutable, Semantically Versioned Artifacts** - -Each component publish creates a new, immutable version (e.g., `my-header/1.4.2`). Consumers can specify version ranges (`1.x.x`, `~1.4.0`) for automatic updates within safe boundaries. - -**Benefits:** -- βœ… Safe rollbacks to any previous version -- βœ… Deterministic builds and deployments -- βœ… Gradual rollout of new component versions -- βœ… Zero-downtime updates with fallback support - -
- -
- -### πŸ‘₯ **True Team Autonomy** - -Components live in **separate repositories** with independent pipelines and deployment schedules. The registry serves as the only integration contract. - -**Benefits:** -- βœ… No shared monorepo or build configuration -- βœ… Teams choose their own development workflows -- βœ… Independent scaling and resource allocation -- βœ… Clear ownership and responsibility boundaries - -
- -
- -### πŸš€ **Built-in CDN Distribution** - -Static assets (JavaScript, CSS, images) are automatically uploaded to your configured storage (S3, Google Cloud, Azure) and served via CDN. - -**Benefits:** -- βœ… Global performance optimization -- βœ… Automatic asset versioning and caching -- βœ… Reduced server load and bandwidth costs -- βœ… Edge caching for maximum speed - -
- -
- -### πŸ› οΈ **Framework-Agnostic Templates** - -Use **ES6 templates by default**, with first-class support for React, Vue, Svelte, or build custom renderers for any framework. - -**Benefits:** -- βœ… Teams can use their preferred technology -- βœ… Gradual migration between frameworks -- βœ… Future-proof architecture -- βœ… Consistent integration regardless of underlying tech - -
- -
- -### 🌐 **Language-Agnostic Consumption** - -The contract is simple **HTTP + HTML**, so any backend, CMS, or application can consume OpenComponents without JavaScript dependencies. - -**Benefits:** -- βœ… Perfect for brownfield applications -- βœ… Works with legacy systems -- βœ… No vendor lock-in -- βœ… Universal compatibility - -
- -
- -## Detailed Feature Comparison - -
- -| **Capability** | **OpenComponents** | **Module Federation** | **Single-Page Apps** | **iFrames** | -|---|---|---|---|---| -| **SSR on non-Node hosts** | βœ… Via Registry | ❌ Node required | ❌ Client-side only | ❌ Client-side only | -| **Runtime version control** | βœ… Semantic versioning | ⚠️ Build-time bundling | ❌ Monolithic deploys | ⚠️ Manual coordination | -| **Team independence** | βœ… Separate repos & pipelines | ⚠️ Shared build config | ❌ Coordinated releases | βœ… Full isolation | -| **Technology flexibility** | βœ… Any framework per component | ⚠️ Webpack ecosystem | ❌ Single framework | βœ… Any technology | -| **Performance optimization** | βœ… CDN + caching + SSR | ⚠️ Bundle optimization | ⚠️ Client-side loading | ❌ Multiple page loads | -| **SEO compatibility** | βœ… Server-rendered HTML | ⚠️ With SSR setup | ❌ Poor SEO | ❌ Poor SEO | -| **Integration complexity** | βœ… Simple HTTP + HTML | ⚠️ Complex build setup | ⚠️ Framework coupling | βœ… Simple embedding | -| **Shared state management** | ⚠️ Via props/events | βœ… Shared modules | βœ… Global state | ❌ PostMessage only | - -
- -## When to Choose OpenComponents +OpenComponents enables multiple autonomous teams to own different parts of the UI while maintaining seamless integration across diverse technology stacks. -
+## The problem it solves -### βœ… **Perfect For:** +**The monolith problem:** -- **🏒 Mixed technology organizations** - .NET, Java, PHP backends with JavaScript frontends -- **πŸ“ˆ Large-scale applications** - Multiple teams, complex deployment requirements -- **🎯 SEO-critical applications** - E-commerce, content sites, marketing pages -- **πŸ”„ Gradual modernization** - Migrating from legacy systems without big-bang rewrites -- **🌐 Multi-brand platforms** - Shared components across different properties -- **⚑ Performance-critical applications** - Need for server-side rendering and CDN optimization +- Coordination overhead – all teams must align on releases +- Technology lock-in – everyone uses the same framework and build tools +- Deployment bottlenecks – one team's issues block everyone else +- Scaling challenges – the codebase becomes unwieldy as teams grow -### ❌ **Not Ideal For:** +**The OpenComponents approach:** -- **πŸ‘€ Solo developers or small teams** - Overhead may not be justified -- **πŸš€ Simple applications** - Single-page apps with minimal complexity -- **πŸ”’ Highly secure environments** - Where external registries aren't permitted -- **πŸ“± Mobile-first applications** - Native mobile development patterns may be better +- Independent development – teams work autonomously with their preferred tools +- Flexible deployment – release components on your own schedule +- Technology freedom – mix React, Vue, vanilla JS, or any framework +- Scalable architecture – add teams and components without a shared build -
+## Key benefits -## Real-World Success Stories +- **Server-side rendering without Node.js** – the registry renders components server-side and returns ready-to-inject HTML to any host technology (C#, PHP, Java, Go, Python, Ruby), with graceful client-side fallback if it's unavailable. +- **Immutable, semantically versioned artifacts** – each publish creates a new immutable version (e.g. `my-header/1.4.2`). Consumers can pin exact versions or use ranges (`1.x.x`, `~1.4.0`) for safe automatic updates, and roll back instantly. +- **True team autonomy** – components live in separate repositories with independent pipelines. The registry is the only integration contract, so there's no shared monorepo or build configuration. +- **Built-in CDN distribution** – static assets (JS, CSS, images) are uploaded to your configured storage (S3, Google Cloud, Azure, ...) and served via CDN automatically. +- **Framework-agnostic templates** – ES6 templates are the default, with support for React, Vue, and other frameworks, or custom renderers. +- **Language-agnostic consumption** – the contract is plain HTTP + HTML, so any backend, CMS, or application can consume components without a JavaScript runtime. -
+## How it compares -### **E-commerce Platform** -*"We reduced deployment coordination from weeks to hours. Each team can now ship features independently while maintaining a consistent user experience."* +| Capability | OpenComponents | Module Federation | Single-Page Apps | iFrames | +| --- | --- | --- | --- | --- | +| SSR on non-Node hosts | Via Registry | Node required | Client-side only | Client-side only | +| Runtime version control | Semantic versioning | Build-time bundling | Monolithic deploys | Manual coordination | +| Team independence | Separate repos & pipelines | Shared build config | Coordinated releases | Full isolation | +| Technology flexibility | Any framework per component | Webpack ecosystem | Single framework | Any technology | +| SEO compatibility | Server-rendered HTML | Needs SSR setup | Poor by default | Poor | +| Integration complexity | Simple HTTP + HTML | Complex build setup | Framework coupling | Simple embedding | +| Shared state management | Via props/events | Shared modules | Global state | postMessage only | -### **Media Company** -*"OpenComponents enabled us to modernize our CMS gradually. We now serve React components from our PHP backend without any JavaScript runtime requirements."* +This is a general comparison, not a benchmark β€” the right tool depends on your constraints. -### **Financial Services** -*"The immutable versioning gives us the confidence to deploy frequently. We can roll back any component instantly if issues arise."* +## When to choose OpenComponents -
+**Good fit:** -## Next Steps +- Mixed-technology organizations (.NET, Java, PHP backends with JS frontends) +- Large-scale applications with multiple teams and complex deployment requirements +- SEO-critical applications (e-commerce, content sites, marketing pages) +- Gradual modernization away from a legacy system +- Multi-brand platforms sharing components across properties -
+**Probably not a fit:** -Ready to get started? Choose your path: +- Solo developers or small teams, where the operational overhead isn't justified +- Simple, single-team applications +- Environments where running/hosting a registry isn't permitted -- **πŸš€ [Quick Start Tutorial](../quick-start-tutorial)** - Build your first component in 10 minutes -- **πŸ—οΈ [Architecture Overview](architecture-overview)** - Understand how everything works together -- **πŸ’‘ [See Examples](../components/getting-started)** - Explore real component implementations +## Next steps -
+- [Quick Start Tutorial](../quick-start-tutorial) – build your first component +- [Architecture Overview](architecture-overview) – how the pieces fit together +- [Getting Started with components](../building/getting-started) diff --git a/website/docs/consumers/_category_.json b/website/docs/consumers/_category_.json deleted file mode 100644 index f33a69d..0000000 --- a/website/docs/consumers/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Consumers", - "position": 2 -} diff --git a/website/docs/consumers/batch-endpoint.md b/website/docs/consumers/batch-endpoint.md index 2f32f7d..a395420 100644 --- a/website/docs/consumers/batch-endpoint.md +++ b/website/docs/consumers/batch-endpoint.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 7 ---- - # Batch Endpoint It allows to retrieve a set of components with a single request to the API. While this should be convenient during the server-side rendering, it is not a good practice for client-side rendering. diff --git a/website/docs/consumers/client-api.md b/website/docs/consumers/client-api.md index 10f30cf..85e43c9 100644 --- a/website/docs/consumers/client-api.md +++ b/website/docs/consumers/client-api.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 2 ---- - # OC Client API & Advanced Usage This page documents the JavaScript API exposed by the OC browser client and shows how to leverage advanced features such as global parameters, headers, custom templates and actions. diff --git a/website/docs/consumers/client-setup.md b/website/docs/consumers/client-setup.md index 6ef90ad..36b613a 100644 --- a/website/docs/consumers/client-setup.md +++ b/website/docs/consumers/client-setup.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 1 ---- - # OC Client - Installation & Setup `oc-client` is the browser runtime that discovers `` tags and renders them. This page explains how to include the script, initialise it safely, and configure global settings. diff --git a/website/docs/consumers/client-side-rendering.md b/website/docs/consumers/client-side-rendering.md index a1aebbe..241da05 100644 --- a/website/docs/consumers/client-side-rendering.md +++ b/website/docs/consumers/client-side-rendering.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 5 ---- - # Client-side Rendering ## Integration diff --git a/website/docs/consumers/events-hooks.md b/website/docs/consumers/events-hooks.md index 5e69fb0..c4b238b 100644 --- a/website/docs/consumers/events-hooks.md +++ b/website/docs/consumers/events-hooks.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 4 ---- - # Events & Hooks The OC client fires a series of lifecycle events you can hook into to orchestrate complex user-flows, perform logging, or show custom loading states. This page lists the available events and shows how to subscribe, unsubscribe, and fire custom ones. diff --git a/website/docs/consumers/rendering-lifecycle.md b/website/docs/consumers/rendering-lifecycle.md index f0c0e48..6a8873a 100644 --- a/website/docs/consumers/rendering-lifecycle.md +++ b/website/docs/consumers/rendering-lifecycle.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 3 ---- - # Rendering Lifecycle Learn how the OC client discovers and renders components on the page – including synchronous, asynchronous and nested rendering, plus support for ES modules. If you’re looking for an architectural birds-eye view of what happens in the browser, you’re in the right place. diff --git a/website/docs/consumers/server-side-rendering.md b/website/docs/consumers/server-side-rendering.md index 1ef0306..624b6d2 100644 --- a/website/docs/consumers/server-side-rendering.md +++ b/website/docs/consumers/server-side-rendering.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 6 ---- - # Server-side Rendering You can get rendered components via the registry rest api. diff --git a/website/docs/intro.md b/website/docs/intro.md index 81b6ec0..480d5e8 100644 --- a/website/docs/intro.md +++ b/website/docs/intro.md @@ -1,66 +1,17 @@ ---- -sidebar_position: 1 ---- - # Introduction -
- -## Build, Deploy, and Scale Micro Frontends with Independent Teams - -OpenComponents is a **powerful, language-agnostic micro frontend framework** that enables teams to develop, test, and deploy UI components independently while composing them into cohesive applications. - -**Break free from monolithic frontends.** - -
- -
- -
- πŸš€ -
-
Team Independence
-
Develop components with your preferred tech stack while maintaining seamless integration across your organization.
-
-
- -
- ⚑ -
-
Server-Side Rendering Anywhere
-
Get SSR benefits without Node.js on your edge - works with C#, PHP, Java, Go, and any backend stack.
-
-
- -
- πŸ”’ -
-
Immutable & Versioned
-
Semantic versioning with immutable artifacts ensures safe rollbacks and deterministic deployments.
-
-
+OpenComponents is a language-agnostic micro frontend framework: it lets independent teams build, publish, and version UI components as isomorphic HTML/CSS/JS bundles, and lets *any* backend (Node.js, .NET, PHP, Java, Go, ...) render and consume them over a simple HTTP + HTML contract. -
- 🌐 -
-
Language Agnostic
-
Consume components from any backend or CMS using simple HTTP + HTML contracts.
-
-
+New to the project? Read [Why OpenComponents?](concepts/why-opencomponents) for the motivation, or jump straight into the [Quick Start Tutorial](quick-start-tutorial) to build your first component. -
+## The pieces -## Quick Start +- **Component** – a small, versioned bundle of view + optional server logic. See [Building Components](building/getting-started). +- **Registry** – the REST API that stores, versions, and serves components. See [Registry Configuration](registry/registry-configuration). +- **Library** – the storage backend (S3, Google Cloud Storage, Azure, ...) the registry uses to persist published components. +- **Client** – the browser/Node.js/PHP/Ruby runtime that discovers and renders components. See [Consuming Components](consumers/client-setup). -
- -### πŸ†• **New to OpenComponents?** - -Start with our [**Quick Start Tutorial**](quick-start-tutorial) for a complete hands-on introduction. - -### ⚑ **Ready to dive in?** - -Get up and running in 30 seconds: +## 30-second start ```bash # Install the CLI @@ -69,363 +20,20 @@ npm install -g oc # Create your first component oc init my-component -# Start local development +# Start a local dev registry and preview it oc dev . 3030 - -# View your component open http://localhost:3030/my-component/~preview ``` -
- -## Core Concepts - -
- -
- -### 🧩 **Components** - -Small units of isomorphic code consisting of HTML, JavaScript, and CSS. Components can include server-side logic for data fetching and model composition, rendering to pure HTML for injection into any page. - -[Learn about Components β†’](components/getting-started) - -
- -
- -### 🌐 **Registry** - -A REST API that handles component consumption, retrieval, and publishing. The registry manages immutable, versioned components and serves as the central contract between producers and consumers. - -[Explore Registry Setup β†’](registry/registry-configuration) - -
- -
- -### πŸ“¦ **Library & CDN** - -Centralized storage for published components with automatic CDN distribution for static assets (images, CSS, JavaScript). Ensures fast, global delivery of component resources. - -[Setup Library β†’](registry/registry-configuration#s3) - -
- -
- -### πŸ› οΈ **CLI Tools** - -Powerful command-line interface for creating, developing, testing, and publishing components. Includes local development server with hot reloading and component preview capabilities. - -[CLI Reference β†’](components/cli) - -
- -
- -## Why Choose OpenComponents? - -
-
- βœ… Perfect For: -
- -
-
-
- ❌ Not Ideal For: -
- -
- -## Components management - -A component is a directory composed by - -| File | Description | -| ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | -| `package.json` | The component definition, dependencies, and more. | -| `view` | The view in charge to output the final markup. OC uses `ES6` templates by default and comes with a powerful template system to support components built with any javascript UI framework like `React`, `SolidJS`, `Vue`. Legacy `Handlebars` and `Jade` templates are still supported for backwards compatibility. | -| `server` (optional) | If the component needs logic, including consuming services, this is the entity that will produce the view-model to compile the view. | -| static assets (optional) | Images, JavaScript, and files to be uploaded to the CDN and referenced in the HTML markup. | -| \* | Any other files that will be useful for the development such as tests, docs, etc. | - -After publishing, components are immutable and semantic versioned. - -[Getting started with components](/docs/components/getting-started) - -[Working on the server](/docs/components/the-server.js) - -## Creation - -To create a folder containing the component: - -```bash -npm install oc -g -oc init hello-world -``` - -## Editing, debugging, testing - -To start a local test registry using a components' folder as a library with a watcher: - -```bash -oc dev . 3030 -``` - -To see how the component looks like when consuming it: - -```bash -oc preview http://localhost:3030/hello-world -``` - -As soon as you make changes on the component, you will be able to refresh this page and see how it looks. - -## Publishing to a registry - -You will need an online registry connected to a library. A component with the same name and version cannot already exist on that registry. - -```bash -# you have to do the registry config first, just once -oc registry add http://my-components-registry.mydomain.com - -# then, ship it -oc publish hello-world/ -``` - -Now, it should be available at `http://my-components-registry.mydomain.com/hello-world`. - -## Consuming Components - -From a consumer's perspective, a component is an HTML fragment. You can render components **client-side, server-side, or fall back to client-side rendering** when server-side rendering fails (for example, if the registry is slow or unavailable). - -You don't need Node.js to consume components on the server-side. The registry can provide you rendered components so that you can consume them using any tech stack. - -When published, components are immutable and semantic versioned. The registry allows consumers to get any version of the component: the latest patch, or minor version, etc. - -**When to use OpenComponents:** - -- Building micro frontends with multiple teams -- Need for independent deployment of UI components -- Sharing components across different applications -- Gradual migration from monolithic frontends - -## Client-side rendering - -To make this happen, your components registry has to be publicly available. -This is all you need: - -```html - - - - - - - -``` - -For more information about client-side operations, look at [this page](/docs/consumers/rendering-lifecycle). - -## Server-side rendering - -You can get rendered components via the registry REST API. - -```bash -curl http://my-components-registry.mydomain.com/hello-world -``` - -```json -{ - "href": "https://my-components-registry.mydomain.com/hello-world", - "version": "1.0.0", - "requestVersion": "", - "html": "Hello John doe!", - "type": "oc-component", - "renderMode": "rendered" -} -``` - -Nevertheless, for improving caching and response size, when using the `node.js` client or any language capable of executing server-side JavaScript the request will look more like: - -```bash -curl http://my-components-registry.mydomain.com/hello-world/~1.0.0 -H Accept:application/vnd.oc.unrendered+json -``` - -```json -{ - "href": "https://my-components-registry.mydomain.com/hello-world/~1.0.0", - "version": "1.0.0", - "requestVersion": "~1.0.0", - "data": { - "name": "John doe" - }, - "template": { - "src": "https://s3.amazonaws.com/your-s3-bucket/components/hello-world/1.0.0/template.js", - "type": "es6", - "key": "cad2a9671257d5033d2abfd739b1660993021d02" - }, - "type": "oc-component", - "renderMode": "unrendered" -} -``` - -In this case you get the compiled view + the data, and you can do the rendering, eventually, interpolating the view-model data and rendering the compiled view with it. - -When retrieving multiple components, a [batch POST endpoint](/docs/consumers/batch-endpoint) allows to make a single request to the API. - -- [Javascript browser client](https://github.com/opencomponents/oc-client-browser) -- [Javascript Node.js client](https://github.com/opencomponents/oc-client-node) -- [PHP client](https://github.com/opencomponents/oc-client-php) -- [Ruby client](https://github.com/opencomponents/ruby-oc) -- [Rails client](https://github.com/opencomponents/opencomponents-rails) -- [Sinatra client](https://github.com/opencomponents/sinatra-opencomponents) - -### Install the CLI - -See the dedicated [CLI guide](components/cli#install-the-cli) for installation, shell-autocomplete, and update instructions. - -## Setup a library - -See detailed guides for: - -- [S3 library adapter](registry/registry-configuration#s3) -- [Google Cloud Storage adapter](registry/registry-using-google-storage) - -## Setup a registry - -A full configuration reference and production-ready examples live in [Registry Configuration](registry/registry-configuration). Start there when you need to spin up your first registry. - -## What Should I Read Next? - -
- -
- -### πŸš€ **I'm new to OpenComponents** - -Get started with a complete hands-on introduction that covers all the basics. - -[**Start Tutorial β†’**](quick-start-tutorial) - -
- -
- -### 🧠 **Understand the Concepts** - -Learn why OpenComponents exists and how it compares to other solutions. - -[**Core Concepts β†’**](concepts/why-opencomponents) - -
- -
- -### πŸ”§ **Build Components** - -Create your first component and learn development workflows. - -**Start here:** - -- [Getting Started](components/getting-started) -- [CLI Reference](components/cli) -- [Server Logic](components/the-server.js) - -
- -
- -### 🌐 **Consume Components** - -Integrate components into your applications and websites. - -**Integration guides:** - -- [Client-side Rendering](consumers/client-side-rendering) -- [Server-side Rendering](consumers/server-side-rendering) -- [Batch Loading](consumers/batch-endpoint) - -
- -
- -### βš™οΈ **Setup Infrastructure** - -Deploy registries and configure production environments. - -**Infrastructure:** - -- [Registry Configuration](registry/registry-configuration) -- [Architecture Overview](concepts/architecture-overview) - -
- -
- -### πŸ” **Get Help** - -Find answers to common questions and troubleshooting guides. - -**Support resources:** - -- [FAQ](reference/faq) -- [Debugging Guide](building/debugging) -- [Template System](building/template-system) +For the full walkthrough β€” creating, developing, publishing, and consuming a component β€” see the [Quick Start Tutorial](quick-start-tutorial). -
+## Where to go next -
+| I want to... | Go to | +| --- | --- | +| Understand why OC exists and when to use it | [Why OpenComponents?](concepts/why-opencomponents) | +| See how the pieces fit together | [Architecture Overview](concepts/architecture-overview) | +| Build a component | [Building Components](building/getting-started) | +| Consume components in an app | [Consuming Components](consumers/client-setup) | +| Set up a registry | [Registry Configuration](registry/registry-configuration) | +| Find answers to common questions | [FAQ](reference/faq) | diff --git a/website/docs/quick-start-tutorial.md b/website/docs/quick-start-tutorial.md index 92902df..1ce0a7d 100644 --- a/website/docs/quick-start-tutorial.md +++ b/website/docs/quick-start-tutorial.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 2 ---- - # Quick Start Tutorial
@@ -52,7 +48,7 @@ npm install -g oc oc --version ``` -You should see the version number. If not, check the [CLI installation guide](components/cli#install-the-cli) for troubleshooting. +You should see the version number. If not, check the [CLI installation guide](building/cli#install-the-cli) for troubleshooting.
@@ -520,8 +516,8 @@ The generated component demonstrates several OpenComponents features: Now that you've created your first component, explore these advanced topics: -1. **[Component Structure](components/getting-started)** - Learn about advanced component patterns -2. **[Server-side Logic](components/the-server.js)** - Add complex data processing +1. **[Component Structure](building/getting-started)** - Learn about advanced component patterns +2. **[Server-side Logic](building/the-server.js)** - Add complex data processing 3. **[Client-side Operations](consumers/rendering-lifecycle)** - Advanced browser integration 4. **[Registry Configuration](registry/registry-configuration)** - Production registry setup 5. **[Template System](building/template-system)** - Use React, Vue, or other frameworks diff --git a/website/docs/reference/faq.md b/website/docs/reference/faq.md index a5f9ce2..f827a4a 100644 --- a/website/docs/reference/faq.md +++ b/website/docs/reference/faq.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 4 ---- - # Frequently Asked Questions (FAQ) ## Beginner Questions @@ -68,7 +64,7 @@ See the [Architecture Overview](../concepts/architecture-overview#distribution-- ## Can I link a CDN on top of the S3 bucket? -Yes! Either you use Cloudfront or any other vendor's on top of the S3, you will get a url, for instance `https://123456789.cloudfront.org/...` or `https://my-cdn.my-company.com`. Then set the `s3.path` property in the [registry configuration](/docs/registry/registry-configuration#registry-configuration). +Yes! Either you use Cloudfront or any other vendor's on top of the S3, you will get a url, for instance `https://123456789.cloudfront.org/...` or `https://my-cdn.my-company.com`. Then set the `s3.path` property in the [registry configuration](/docs/registry/registry-configuration#configuration-reference). ## Can I avoid using S3? diff --git a/website/docs/reference/index.md b/website/docs/reference/index.md deleted file mode 100644 index 1f96aa4..0000000 --- a/website/docs/reference/index.md +++ /dev/null @@ -1,10 +0,0 @@ ---- -sidebar_position: 0 ---- - -# Reference & FAQ - -Looking for concrete answers or deep dives? This area collects reference material and common questions that don’t fit into tutorials. - -- **FAQ** – quick answers to frequent queries. -- Command and configuration cheat-sheets (coming soon). diff --git a/website/docs/registry/_category_.json b/website/docs/registry/_category_.json deleted file mode 100644 index 9553a4f..0000000 --- a/website/docs/registry/_category_.json +++ /dev/null @@ -1,4 +0,0 @@ -{ - "label": "Registry", - "position": 3 -} diff --git a/website/docs/components/publishing-to-a-registry.md b/website/docs/registry/publishing-to-a-registry.md similarity index 97% rename from website/docs/components/publishing-to-a-registry.md rename to website/docs/registry/publishing-to-a-registry.md index 1f3875d..a697755 100644 --- a/website/docs/components/publishing-to-a-registry.md +++ b/website/docs/registry/publishing-to-a-registry.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 5 ---- - # Publishing to a registry Publishing components to an OpenComponents registry makes them available for consumption across your applications. This guide covers the complete publishing workflow, from basic commands to advanced scenarios and troubleshooting. @@ -21,7 +17,7 @@ Publishing assumes: 1. A reachable registry (see [Registry Configuration](../registry/registry-configuration)) 2. A component folder that passes `oc dev` validation -3. OC CLI installed (see [CLI install](cli.md#install-the-cli)) +3. OC CLI installed (see [CLI install](../building/cli#install-the-cli)) That's all you needβ€”no extra global setup. @@ -310,7 +306,7 @@ This validates your component and simulates the publish process without actually ## Troubleshooting -For error messages and advanced diagnostics, refer to the [CLI Troubleshooting Guide](cli.md#installation-troubleshooting). It covers authentication, versioning, validation failures, and more. +For error messages and advanced diagnostics, refer to the [CLI Troubleshooting Guide](../building/cli#installation-troubleshooting). It covers authentication, versioning, validation failures, and more. ### Debugging Tips diff --git a/website/docs/registry/registry-configuration.md b/website/docs/registry/registry-configuration.md index 520cdbc..693251d 100644 --- a/website/docs/registry/registry-configuration.md +++ b/website/docs/registry/registry-configuration.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 1 ---- - # Registry Configuration ## Introduction @@ -58,7 +54,7 @@ registry.start(function (err, app) { ### var registry = new oc.Registry(configuration); -Creates an instance of the registry. [Configuration](#registry-configuration) is an object that contains the registry configuration parameters. +Creates an instance of the registry. [Configuration](#configuration-reference) is an object that contains the registry configuration parameters. ### registry.start(callback) @@ -91,7 +87,7 @@ registry.register({ For unsuscribing to all [events](#registry-events). -## Registry configuration +## Configuration reference ### Core Configuration Options diff --git a/website/docs/registry/registry-metadata-stores.md b/website/docs/registry/registry-metadata-stores.md index 387a077..4c38cd9 100644 --- a/website/docs/registry/registry-metadata-stores.md +++ b/website/docs/registry/registry-metadata-stores.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 3 ---- - # Registry Metadata Stores :::info New feature diff --git a/website/docs/registry/registry-server-adapters.md b/website/docs/registry/registry-server-adapters.md index 2c8e74b..722a1dd 100644 --- a/website/docs/registry/registry-server-adapters.md +++ b/website/docs/registry/registry-server-adapters.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 4 ---- - # Registry Server Adapters :::info New feature diff --git a/website/docs/registry/registry-using-google-storage.md b/website/docs/registry/registry-using-google-storage.md index 7b62dd8..3d68132 100644 --- a/website/docs/registry/registry-using-google-storage.md +++ b/website/docs/registry/registry-using-google-storage.md @@ -1,7 +1,3 @@ ---- -sidebar_position: 2 ---- - # Registry using Google Storage To use Google Storage make sure you have an account and credentials. When running on a server don't forget to set your `GOOGLE_APPLICATION_CREDENTIALS` environment variable to the path of your authentication json. @@ -533,6 +529,6 @@ const configuration = { ## Next Steps - **[Registry Configuration](registry-configuration)** - Complete registry setup options -- **[Publishing Components](../components/publishing-to-a-registry)** - Deploy components to your registry +- **[Publishing Components](publishing-to-a-registry)** - Deploy components to your registry - **[Client-side Integration](../consumers/client-side-rendering)** - Consume components in applications - **[Architecture Overview](../concepts/architecture-overview)** - Understand the complete system diff --git a/website/sidebars.js b/website/sidebars.js index 2964828..1829314 100644 --- a/website/sidebars.js +++ b/website/sidebars.js @@ -39,11 +39,11 @@ const sidebars = { label: "Building Components", items: [ "building/index", - "components/getting-started", - "components/package.json-structure", - "components/the-server.js", + "building/getting-started", + "building/package.json-structure", + "building/the-server.js", "building/template-system", - "components/cli", + "building/cli", "building/debugging", ], }, @@ -64,7 +64,7 @@ const sidebars = { type: "category", label: "Registry & Infrastructure", items: [ - "components/publishing-to-a-registry", + "registry/publishing-to-a-registry", "registry/registry-configuration", { type: "doc", @@ -82,7 +82,7 @@ const sidebars = { { type: "category", label: "Reference", - items: ["reference/index", "reference/faq"], + items: ["reference/faq"], }, ], diff --git a/website/src/components/HomepageFeatures.tsx b/website/src/components/HomepageFeatures.tsx index 25a33dd..e1faf01 100644 --- a/website/src/components/HomepageFeatures.tsx +++ b/website/src/components/HomepageFeatures.tsx @@ -25,7 +25,7 @@ const FeatureList: FeatureItem[] = [ their own HTML, CSS, and JavaScript, making them easy to maintain and update without affecting other parts of your application.

- Learn more + Learn more ), }, @@ -69,7 +69,7 @@ const FeatureList: FeatureItem[] = [ locally.

It also allows publishing of components to your registry.

- Learn more + Learn more ), }, diff --git a/website/static/llms.txt b/website/static/llms.txt index cd91baf..6ae925d 100644 --- a/website/static/llms.txt +++ b/website/static/llms.txt @@ -14,11 +14,11 @@ The framework consists of four core components: CLI & Development Tools for comp ## Components -- [Getting Started with Components](https://opencomponents.github.io/docs/components/getting-started.md): Create, develop, and test your first component -- [CLI Reference](https://opencomponents.github.io/docs/components/cli.md): Complete command-line interface documentation -- [Server-side Logic](https://opencomponents.github.io/docs/components/the-server.js.md): Advanced server-side operations and data processing -- [Package.json Structure](https://opencomponents.github.io/docs/components/package.json-structure.md): Component configuration and metadata -- [Publishing to Registry](https://opencomponents.github.io/docs/components/publishing-to-a-registry.md): Deploy components to production +- [Getting Started with Components](https://opencomponents.github.io/docs/building/getting-started.md): Create, develop, and test your first component +- [CLI Reference](https://opencomponents.github.io/docs/building/cli.md): Complete command-line interface documentation +- [Server-side Logic](https://opencomponents.github.io/docs/building/the-server.js.md): Advanced server-side operations and data processing +- [Package.json Structure](https://opencomponents.github.io/docs/building/package.json-structure.md): Component configuration and metadata +- [Publishing to Registry](https://opencomponents.github.io/docs/registry/publishing-to-a-registry.md): Deploy components to production ## Architecture & Concepts @@ -39,6 +39,7 @@ The framework consists of four core components: CLI & Development Tools for comp - [Registry Configuration](https://opencomponents.github.io/docs/registry/registry-configuration.md): Production registry setup with S3, authentication, and advanced options - [Metadata Stores](https://opencomponents.github.io/docs/registry/registry-metadata-stores.md): Opt-in pluggable database as source of truth for the component index, plus migration steps for existing registries +- [Server Adapters](https://opencomponents.github.io/docs/registry/registry-server-adapters.md): Swap the registry's HTTP layer (e.g. Fastify instead of Express) - [Google Cloud Storage](https://opencomponents.github.io/docs/registry/registry-using-google-storage.md): Alternative storage configuration - [Client Setup](https://opencomponents.github.io/docs/consumers/client-setup.md): Consumer application configuration