All Serialized configuration and data is available via our APIs. We recommend all changes are deployed as source code as part of your CI/CD pipeline or your application initialization.
We promote a code-first approach.
Our platform provides a web-based user interface where you manage your account for billing and create projects. After you have created your project(s) you perform all configuration through our APIs using the API keys created for your project.
This page describes some of the most significant benefits of this approach. We also bring up a few recommendations related to commonly asked questions around configuration and deployment.
Why you should keep configuration as code?
Keeping your configuration as code means instead of configuring your project by point-and-click operations in a user interface somewhere, you store the configuration in your version control system (such as Git) together with your source code.
- Reproducible environment configurations
- Simplified testing
- Configuration and code kept together
Configure Serialized during application startup
When building an application using Serialized you need to provide some configuration to your projects, such as projections and reactions. Since all features in the platform are API-driven you should version control the configuration files (projection definitions and reaction definitions) in your VCS (such as Git).
If you package your configuration with your application you can update your Serialized configuration during the startup phase of your application.
Our configuration APIs are idempotent. This means that we provide endpoints for optionally update the configuration if the configuration is different from the current configuration for the project.
The APIs that are used for project configuration are the following: