The 12-Factor App: A Swift Developer’s Perspective

We can use many dependencies in application so it should be contain the isolated dependencies because the app is a standalone and needs to install dependencies so we can use the useful dependencies in code.

Application code should be in one repository. A one codebase can be used for different version of app, you don’t need to create the different repo. And you can deploy it to any number of other environments. Just you need to put your code on live repository.

A backing service is required a network connection to run. It’s about treating these services that your application depends on equally. Backing services is like databases that are managed by the same system administrators. This factor is focus on each backing service calling through an API, with credentials that are stored in a configuration file. That means it makes no distinction between local and third party services, all that’s as attached resources.

The Configuration factor focuses on way of storing the data, API keys, services, and database hardcoded credentials. The code of saving the data will be same so it will be better and good concept to keep all data storing thinks in configuration files.

Application running on many servers and it has many processes, so these processes should be stateless process. That means if failure comes at any dependency then complete app does not become a failure. We know that a single point of failure it create difficulties but we can avoid a single failure instead of failure of whole app.

Build, release and run works in a lifecycle but it takes time and resources to set it up. The build stage convert the code into an executable bundle and release stage takes the executable bundle from build stages and combine it with configuration file and get it ready to immediate execution. And at last the run stage run the app in execution environment. You can’t make any changes to the code at runtime, so these build, release and run stages should be in separated.

App must be completely self-contained and bind to a port specified as an environment variable. It’s about make application as standalone instead of relying on a running instance of an application server, where you deployed. If you exporting services via port binding then it allows your internal customers to access your endpoints without traversing any security.

When an app program run, it represented by many processes. These each process should be able to scale, restart, or clone itself independently when needed. This approach will improve the scalability of the application.

It’s about to minimize start up and take down time of process. A process takes a few seconds from the time to launch command is executed until the process is up and ready to receive requests or jobs. Short startup time provides more agility for the release process and scaling up and it gives the robustness to the app.

It’s about to keeping development, production and staging same as possible. If we take development and production environment as same then it will be easier to understand and anyone release it and it also limit deviation and errors.

Logs are the stream of time ordered events collected from the output streams of all running processes. Logs have no fixed beginning and ending but it flow continuously as long as app is operating. Logging is important for debugging and checking up on the general information of your application. The developer will view this stream in the foreground of their terminal to observe and analyze the app’s behavior.

An admin process is a essentially data collection job which is mostly used to collect the key information about the application. This information is needed in state of production environment, so it’s important to ensure these one-off processes occur in your production environment.