Better Support for External Integrations

Oct 13, 2025 by miodeya.com 97 views

Introduction

In the pursuit of creating a more scalable and flexible architecture, it has become essential to separate the core API from integrations. This approach will not only improve the overall performance but also provide better support for external integrations. In this article, we will delve into the details of this approach, exploring the benefits, methodology, and components involved.

Benefits of Splitting Core API from Integrations

Splitting the core API from integrations offers numerous benefits, including:

Improved Scalability: By separating the core API from integrations, we can create a more modular and scalable architecture. This will enable us to add or remove integrations without affecting the core API, making it easier to maintain and update.
Better Support for External Integrations: With a separate core API, we can provide better support for external integrations. This will enable developers to create custom integrations using the core API, making it easier to integrate with other systems.
Enhanced Flexibility: By separating the core API from integrations, we can create a more flexible architecture. This will enable us to add or remove integrations without affecting the core API, making it easier to adapt to changing requirements.

Methodology for Splitting Core API from Integrations

To split the core API from integrations, we will follow a structured methodology:

Identify Core API Components: We will identify the core API components that will remain unchanged, including the Backplane, Metric, MetricCollection, InputAdapter, OutputAdapter, and Middleware.
Identify Included Modules: We will identify the modules that will be included in the core API, such as generic input adapters, generic output adapters, and generic middleware.
Identify Tentative Modules: We will identify the tentative modules that may be included in the future, such as plotter charts.
Identify Excluded Modules: We will identify the modules that will be excluded from the core API, such as mod-specific integrations and vendor-specific outputs.
Create a Separate Repository for Core API: We will create a separate repository for the core API, which will include the core API components, included modules, and tentative modules.
Create a Separate Repository for Integrations: We will create a separate repository for integrations, which will include the excluded modules and any other integrations that are not part of the core API.

Core API Components

The core API components will include:

Backplane: The backplane is the core component of the API, responsible for managing data and providing a unified interface for integrations.
Metric: The metric component is responsible for collecting and processing data, providing a standardized interface for integrations.
MetricCollection: The metric collection component is responsible for collecting and aggregating data from multiple sources, providing a unified interface for integrations.
InputAdapter: The input adapter component is responsible for receiving data from external sources, providing a standardized interface for integrations.
OutputAdapter: The output adapter component is responsible for sending data to external destinations, providing a standardized interface for integrations.
Middleware: The middleware component is responsible for processing data in real-time, providing a standardized interface for integrations.

Included Modules

The included modules will include:

Generic Input Adapters: The generic input adapters will include item/fluid storage, secure modem, and custom input adapters.
Generic Output Adapters: The generic output adapters will include secure modem and custom output adapters.
Generic Middleware: The generic middleware will include sort, average, delta, and custom middleware.

Tentative Modules

The tentative modules will include:

Plotter Charts: The plotter charts module will provide a graphical representation of data, enabling users to visualize trends and patterns.

Excluded Modules

The excluded modules will include:

Mod-Specific Integrations: The mod-specific integrations will include AP, Bigger Reactors, Mekanism, and Powah integrations.
Vendor-Specific Outputs: The vendor-specific outputs will include Grafana and Basalt outputs.

Designing Methodology for First-Party Modules

To design a methodology for first-party modules, we will create a telem-modules repository that publishes to a CDN for installer use, and to GH releases as a changelog and backup release target. This will enable us to manage and distribute first-party modules efficiently.

Module Loader Documentation

The module loader will be fully documented to allow third-party modules outside of the standard offerings. This will enable developers to create custom modules using the module loader, making it easier to integrate with other systems.

Custom Luz Encapsulation

We will include support for a custom Luz encapsulation to save significant disk space. This will enable us to reduce the size of the installer and improve performance.

Conclusion

Introduction

In our previous article, we discussed the benefits and methodology of splitting the core API from integrations. In this article, we will address some of the frequently asked questions (FAQs) related to this approach.

Q: What are the benefits of splitting the core API from integrations?

A: Splitting the core API from integrations offers numerous benefits, including improved scalability, better support for external integrations, and enhanced flexibility.

Q: How will the core API be affected by the separation from integrations?

A: The core API will remain unchanged, with the same components and functionality. The separation from integrations will only affect the way the core API is used and integrated with other systems.

Q: What will happen to the existing integrations?

A: The existing integrations will be moved to a separate repository, where they will be maintained and updated independently of the core API.

Q: How will the module loader be affected by the separation from integrations?

A: The module loader will be fully documented to allow third-party modules outside of the standard offerings. This will enable developers to create custom modules using the module loader, making it easier to integrate with other systems.

Q: What is the purpose of the `telem-modules` repository?

A: The telem-modules repository will be used to publish first-party modules to a CDN for installer use, and to GH releases as a changelog and backup release target. This will enable us to manage and distribute first-party modules efficiently.

Q: How will the custom Luz encapsulation affect the installer?

A: The custom Luz encapsulation will enable us to save significant disk space by reducing the size of the installer. This will improve performance and make the installer more efficient.

Q: What is the timeline for implementing the split core API from integrations?

A: The timeline for implementing the split core API from integrations will depend on the complexity of the project and the resources available. However, we anticipate that the implementation will take several months to complete.

Q: How will the separation from integrations affect the support and maintenance of the core API?

A: The separation from integrations will not affect the support and maintenance of the core API. The core API will continue to be supported and maintained as usual, with the same level of quality and reliability.

Q: What are the next steps in implementing the split core API from integrations?

A: The next steps in implementing the split core API from integrations will include:

Creating a separate repository for the core API
Moving the existing integrations to a separate repository
Documenting the module loader
Implementing the custom Luz encapsulation
Testing and validating the implementation

Q: How can I get involved in the implementation of the split core API from integrations?

A: If you are interested in getting involved in the implementation of the split core API from integrations, please contact us at [insert contact information]. We welcome contributions and feedback from the community.

Conclusion

Splitting the core API from integrations is a complex process that requires careful planning and execution. By addressing the FAQs related to this approach, we hope to provide a better understanding of the benefits and methodology of this approach. If you have any further questions or concerns, please do not hesitate to contact us.