Everyone and thanks for watching my talk at the Con 42 conference on JavaScript. I'm Peleg and I'm thrilled to explore the configurations as code approach with you today. Over the 15 to 20 minutes, we will uncover how configuration as code can revolutionize your approach to configuration management and software development. Before diving into configuration, let me introduce myself. My name is Peleg and I've been a software developer for more than 80 years. I mainly focused on cybersecurity and in the past three years I've been leading configu. My journey has led me to the exciting world of configuration management, where I've been explored the ascode approach and especially the configuration as code approach. So let me start by outlining what we will explore in this talk. Our journey will include understanding application configuration, tackling the challenges they present, and diving deep into these configuration as code approach. Great. Let's start our exploration. Begin with our software Bible, the twelve factory guide. I know some folks find this guide a bit old school, but it does a good job of explaining the basics. In particular, we'll focus on the config section and talk about application configuration. So every software is a combination of code that specify the logic and configuration that define the behavior of the software. Think of configuration as a bench of setting that tell our software how to act. It's like giving specific instruction to a video game so that it know how to start and what level difficulty to use. As developers, we keep configurations separate from our code and store them in separate locations or dedicated files. This includes configuration like environment variables, secrets to keep data safe, feature flag to turn certain functions on or off, and other such setting data. As we delve into the world of configuration and configuration management, it's essential to understand the versus formats available. One prevalent format you will encounter is the dot and file format it flavored for its simplicity and adaptability, making it a common choice among developers. But it's worth nothing that the need for effective configuration management extend beyond just n file. There are other formats like JSON, YaML, and more, each with its own set of advantages and disadvantages. In fact, the importance of configuration management has grown so much that even node js, starting from version 26, offers built in supports for dot and files, recognizing the significance of keeping configurations separate and secure. So whether you choose dot and files, explore alternative formats, or utilize built in support, remember that the quest for efficient and secure configuration management is a shared journey for all developers. Configuration are essential, but managing them bring challenges. This includes complexity, development slowdowns and scalability issues. At Configu we invested lot of time talking with developers and DevOps engineers from small startups to big corporates, and we found a major common problem in how they handle application configuration. Most of them say their configurations are fragment and distributed all over the place. They are saved as a simple raw text in many different locations like databases, files or even third party services. This mixup leads to internal friction, governance gaps, developer distractions. Yeah, and even data risks if not managed effectively. Wrong or outdated setting can cause problems making our software act up, which could lead to downtime and lost money. Managing this setting correctly is super important to keep our system stable and our team working smoothly. It's key to know what setting are being used and to have a way to keep them accurate, reliable and up to date. For example, a company we met told us about a developer they have who accidentally changed a single character in their database connection string. And yeah, connection string may seem humanly readable, but they often contain special characters, making it challenging to tell the difference between necessary components and potentials error. As a result, the application experienced a critical failure and it took them too much time to figure it out and fix the issue. Showing how important is to have a strong and reliable way to manage configurations. Understanding these challenges requires a transformative concept, and after looking into infrastructure as code and seeing the good stuff it bring to the table, we thought why not to build on these winning formula. And that's how configuration as code came to our life. Let's dive into the heart of our discussion. Configuration as code configuration as code is a powerful solution designed to streamline configuration management, making it a game changer for developers. These core of configurations as code appeal lies on its benefits and these include consistency and reproducibility. Configuration as code keeps configuration consistent across different settings because they are handled as code, versioning and tracking, changes to configurations are tracked over time, making it easy to see who change what and when. Automation and efficiency no more manual mess configuration as code automates configurations processes, making deployments faster and smoother. Scalability and agility. Configuration as code make it easy to adjust and scale configurations to meet changing needs more quickly. Collaboration and teamwork it helps developers, operations teams and stakeholders work together more harmoniously. Auditability and security all changes can be reviewed and audited, ensuring configurations remain secure simplifies configuration management. Configurations as code brings a clear structure to managing configurations, making them easier to understand and evolve. Eliminates manual errors by managing configuration as code, it reduce manual mistakes, leading to more reliable setup. Last but not least, enhances efficiency and productivity. So configuration as code frees up time for teams to focus on building a great applications and achieving their business goals. So now that we understand configuration as code, let me briefly introduce configu, an open source tool that brings configuration as code principles to life. Configure provides a structured approach to managing configuration across all different environments, systems, and technologies. It is built to provide a common, flexible and extensible process for storing, mutating, and orchestrating configuration data across different environments and systems. With configu, you can leverage the power of configuration as code ensure streamlined and efficient configuration management for your application. So, to gain better understanding of how configu works, I would like to introduce a few of Config's core concepts. The first concept is config, which is a data model that represents a single application configuration. On configu, it includes three parameters, a key, a value, and a context set. For example, imagine debug level equals error on a production set. Config store Config store is where those configu are saved and read from. It could be any storage engines and includes any type of configuration data, from text files and databases to secret managers and any configuration manager you use. Config set config set is the context of the configuration. It could be an environment like development or production, but it also can be a region, a customer, or basically any context you need to group configurations for. The last and most important concept is config schema. The config is implementation for the configuration as code approach. So basically it's a file that is part of your service code. It declare how the code looks and behave, and lets you to add useful metadata on each configu for collaboration, testing, local development, and many more. We called it a CFGU file, and we will see an example of it in a moment. And now let's move to the fun part and see some code examples. We will use the configured open source as our management interface and the CFGU format as our configuration as code. I'm going to use an hello word JavaScript app and describe its configurations on the schema file, and then I will manage it as I manage code. In this example, I will use a JSON file as my config store, but you can choose any config storage you want or need. So here's my super complex JavaScript application that prints any message that it gets from the environment variable. As you can see here, we will start with installing the configure CLI. In this case, I already have it installed on my computer. Sorry, configu, let's run it okay, so this is a configu CLI command and now that we have configu, let's create our first schema. We'll do that by running the configure init command and in this case we will use the get started flag so it will generate a premade hello world example. Awesome. As you can see here, our schema file contain three keys, greeting, subject and message over greeting. We are enforcing type rejects with greeting pattern and we gave it a default value of hello on subject. It's free string with a default of world and message is template which is additional feature of configu and it creates a value by templating other values. Very handy if you need to build string like connection string or endpoints. And in general there are many other capabilities that you can achieve with the CFDU file. It offers additional attributes like description, test restrictions and many others. So to be able to work with the JSON store as we mentioned before, I will need to add the details of the JSON file to the config file. I already have it here and I already insert all the relevant details, which is the JSON stored JSon. It's a stored from JSON file type and it's ready to use. As you can see here, it's empty for now, but we will generate configu very soon. Great. So everything is ready and we can insert some values. We will use the upset command and save values for my development environment. Let's start configure absurd. Observe. Let's sorry for all the junk, but we'll use my JSON store for set development. I will use the schema get started schema that we generated and we will start with the greeting. For example, let's add hey and also let's insert for subject the value conf 42 successfully. Note that in the background configure validating the type and all the restrictions you added to the CFG file. In this case, for greeting, it must meet the regex we defined. If you want to check it out, let's do the same thing, but instead of hey, let's just add blah and we will get an error that blah is not meet the regex. Now let's see how it's saved. Let's open our JSOn store and as you can see, we have two configs. Each one of them is built from key, set and value. For example, the first one, the key is greeting under development and the value is going to be hey great. Now let's add additional configs to a different set for example, let's use production and maybe we will do additional set that's going to be under production, a child set of production that can inherit the values from it and add a different one. Let's choose a specific customer for example under production and it's going to be look like this one. So as you can see, I'm doing multiple upset together. The first one is going to add welcome greeting to the production and the second one is going to be to add the user one subject to my customer, one set. Great. As you should see in live everything is saved to my JSON store for ending this process. Let's run our application with these configurations. First I will run it for my local environment, so let's run it using the default only. So I won't need anything except my schema will look like it will look like that and sorry, I'm missing space. Great. Yeah, so my Javascript is run and we got the hello word example. If you want to see how it looks like without the configure so node index it will get undefined. Running it with the defaults will get the hello word. And now instead of running it, let's generate a dot and file. Let's do it for the development environment it's going to look like that. So we have again exporting JSOn store development set and now instead of running it we'll export into a n format, it will look like that. So we got the dot and these. If I want, I can also pipe it into a n file and it will generate the dotten file. Let's see it. Here is the dotten file and for the finale let's do the same. But now we want to run it again and instead of development let's just export the production. Customer one yay. Welcome customer one. You can see how our team implemented and visit Configure's open source project on GitHub if you find it useful. We would appreciate your star and support. And better yet, if you want, join our team and contribute to the project for helping everyone to improve configurations. Thanks for watching my talk and feel free to reach out if you have any questions or thoughts.