Low-code programming represents underlying code and functionality visually in a graphical user interface. In a low-code API integration tool, users manipulate the visual elements in the graphical user interface to specify the functionality they want the integration to achieve. In the case of Canonic, the user interacts with the graph interface and builds a backend setup that they can deploy.
Usually, with low-code APIs, the problem comes when changes are required in the API. Whenever any changes are made to the graphical user interface, in order for them to be tested they need to be deployed. When these APIs are deployed, all the frontend applications relying on them become vulnerable to any bugs that could've been shipped with the changes to the API. This could potentially result in downtime and is not ideal for a production setup.
To solve this problem of not being able to test changes before they are deployed, Canonic came up with the environment set up on their platform.
Environments in terms of software engineering can be simply explained with the example of an isolated sandbox. Each environment is an isolated instance where you can run your software and consume APIs.
Here are some of the keywords about environment setup and what they usually mean:
- Deployment : All the activities that make software available for use
- Environment : The Operating System, API calls, and databases used by the software
- Development Environment : The environment catering to developers for building software
- Staging Environment : A replica of production environment where changes are tested before production deployment.
- Production Environment : The environment catering to the end-user of your software
For now, we know we only have one environment available to us where if we deploy any new changes they are reflected in the APIs. Let's call this environment "production" (as seen in canonic).
To solve the problem of not having a medium to test APIs for the project, Canonic allows you to set up multiple environments for your project.
Setting up an additional environment gives us a lot of leverage in terms of experimentation and pushing code changes to APIs without actually worrying about the side effects on production APIs and their consumers.
To add an environment, you simply need to go to your project's settings and go to the environments tab. As you can see we only have one environment existing in our current setup which is production
Now we click on the
+ sign right next to environments, and we will see a new environment popup. As seen below, you can name this env
staging or you can also name it development alternatively based on your preference.
Once you are done with the naming, click on
+ CREATE button as you can see in the attached screenshot.
Once the env creation is successful you will see a popup saying "Environment Created" as shown in the screenshot below.
This means now our project has a new environment that we can use to test our changes.
Till this point, we have created a new env, but we have not deployed it yet. To deploy it, we need to go to the Deploy button on the top right of the page and deploy the project again. As you can see in the below screenshot, we now have Staging in our list of environments, and it is not deployed, so we simply select staging and then click on the deploy CTA.
When the new env is deployed, you will see a deployment successful message along with the URL for your new environment.
And Voila! we have a staging environment setup to test our changes before they go live on production.
Thanks for reading! If you find this story helpful, please click the 👏 button and share it to help others find it! Feel free to leave a comment 💬 below.