Skip to content

Guided tour

FabrCore 2.0 · Release and package availability

These guides track the current 2.0 source. Stable 2.0.0 publication is pending; package commands show the release target. Until it is published, follow the source quick start or use a matching available prerelease set. Release migration · Runtime modes

MODULE 11 · LESSON 11.3

Build an addon or embed FabrCore in another product

Embed FabrCore behind an application-owned API or addon.

Lesson 67 of 86 · FabrCore 2.0

Overview

The Host and SDK are reusable application infrastructure. An addon can contribute services, endpoints, settings and blueprint expansion without creating a private replacement protocol. Discovery should describe what is actually available in this host.

An addon contributes a bounded capability

An addon can register services, endpoints, configuration consumers or blueprint expansion. Keep those contributions behind the Host's existing extension contracts rather than inventing a parallel hidden runtime. A client should discover which optional capability is installed and learn the corresponding request schema before using it.

A setting needs a real consumer

Publishing a setting in a catalog or Cloud Server editor does not implement its behavior. The addon must validate/read it and declare whether changes can apply live or require a restart. Its API must also use the appropriate authentication and principal scope. Keep unknown extension fields intact when a generic editor round-trips configuration.

Extend the Host through supported contracts

  1. Register the addon through a focused DI/builder extension with clearly owned options. Use the public file, storage, embeddings, discovery and agent APIs where appropriate.
  2. Implement a settings-catalog contributor for cloud-visible options and mark live/restart behavior conservatively.
  3. Keep custom-provider contracts separate from internal classes. Test standalone and SQL capability differences when the addon depends on optional services.
Custom Providers · reference snippet 
builder.AddFabrCoreServer(new FabrCoreServerOptions()
.UseAgentManagementProvider<SqlAgentManagementProvider>()
.UseAclEvaluator<MyAclEvaluator>()      // custom access-control decisions (see fabrcore-acl)
.UseAuditProvider<MySiemAuditProvider>());  // durable security audit sink (see fabrcore-acl)

Install, discover and remove the addon

  1. Register a small test addon/provider and start the Host. Confirm its capability/endpoint appears only when the registration is present.
  2. Invoke one observable operation and change one supported setting through its documented apply path. Verify the consumer's actual behavior matches its claimed live/restart timing.
  3. Start without the addon and verify a capability-aware client disables the feature rather than showing an empty successful result or calling an assumed endpoint.

This proves that discovery, registration, configuration and behavior agree. An optional feature should not look permanently available simply because a UI knows its name.

If the result is different

Do not turn an unregistered optional feature into an apparent always-on capability. Unknown cloud settings must not be advertised as live-applied without a live consumer.

Go deeper

Explore the related documentation.