1.8 Broker Provider Abstraction.md

1.8 Standardized Provider Abstraction Libraries (SPAL)

This particular chapter will discuss the providers brokers may rely on to execute a certain operation. Most Brokers rely on external libraries or routines not owned by the engineers developing the system. These external libraries may or may not follow best practices regarding abstraction and testing.

The Standard mandates relying on standardized providers for systems design and development. These standardized providers must have the following characteristics:

1.8.0 Extensibility

Standardized provider abstraction libraries must be extensible to support more external providers. For example, a library that supports communicating with a database to SQL Server must be extensible enough to support communicating with MongoDB, MariaDB, or any other providers without any additional costs from the consumer of these libraries.

1.8.0.0 Configurability

For Standardized libraries to be usable with several providers, it must allow engineers to configure them to target a particular provider, local or remote. For instance, provider abstraction libraries can be configured in the following fashion:

public class StorageBroker
{
    private readonly IProviderAbstraction providerAbstraction;

    public StorageBroker()
    {
        this.providerAbstraction = new ProviderAbstraction();
        
        this.providerAbstraction.Configure(provider => 
            provider.UseSqlServer(connectionString: ....));
    }
}

Another example of using a different provider would be:

public class StorageBroker
{
    private readonly IProviderAbstraction providerAbstraction;

    public StorageBroker()
    {
        this.providerAbstraction = new ProviderAbstraction();
        
        this.providerAbstraction.Configure(provider =>
            provider.UseMariaDb(connectionString: ....));
    }
}

1.8.1 Distributability

Abstraction libraries must allow several engineers to publish their extensions of the library. The library does not need to have implementations of all providers in one binary. Instead, these libraries must provide an interface or a contract that all other extensions must implement to support a specific provider.

For instance, Let's assume we have the core standardized contract Standard.Storages.Core. We may publish a library called Standard.Storages.Sql. Anyone else can also publish Standard.Storages.MongoDb to support the same interface. An interface would look something like this:

public interface IStorageProvider
{
    ValueTask<T> Insert(T @object);
    ValueTask<IQueryable<T>> SelectAll();
    ...
    ...
    void Configure(Options options);
}

This contract's capabilities must be the bare minimum any provider can provide. However, the additional options in the provider extension may expose more capabilities that may or may not exist in other libraries.

1.8.2 External Mockability (Cloud-Foreign)

Standardized provider libraries must allow communications with mocked local phantom APIs. For instance, if a system requires communication with a queue or an event bus in the cloud, the provider library abstracts that technology must allow a local connection for Acceptance Testing and Airplane-Mode runs, which we discussed earlier as Cloud Foriegn Principle.

External Mockability may rely on other external libraries that implement patterns such as PACT to create phantom or fake external API instances running on the local machine or network. Here's an example:

public class EventBroker
{
    private readonly IEventAbstractProvider eventAbstractProvider;

    public EventBroker(IConfiguration configuration)
    {
        this.eventAbstractProvider = 
            new EventAbstractProvider(
                configuration.Connection,
                configuration.TargetServerType);
    }
}

In the above snippet, the TargetServerType can be either Remote or Local as mandatory options, but the engineers developing the library may add other options if they so choose.

Abstract provider libraries must mimic the exact behavior of their providers. For instance, in a queue-listening scenario, these libraries must expose an API that supports eventing for incoming messages, even if they are local and not from an external service such as the cloud.

It is also acceptable to have the option to support local intranet networks and governed networks that are not connected to the public internet in specific scenarios using these very same libraries.

Standardized provider abstraction libraries are subsystems that must have their own Brokers, Services, and Exposure layers according to The Standard. These libraries will further simplify the development of customer-facing systems with well-defined exceptions to handle expectations and simpler modifications since they are open-source and Standard-Compliant.

1.8.3 Local to Global

Engineers may develop their local provider abstraction libraries using the same solution, assuming they need help finding an existing effort to support their needs. By doing so, these engineers are encouraged to open-source and publish that abstraction project to support other engineers in The Standard Community who may have the exact needs.

This practice encourages engineers everywhere to create a collective effort and hive-mind patterns to solve a problem once and share it with the rest of The Standard Engineering Community for further enhancement and support.

Standard-compliant edge (customer-facing) systems should no longer add any non-standard libraries to their APIs, Desktop or Web Applications, or any other systems.