# Twelve-Factors in practice - Part IV - Backing services

## Treat backing services as attached resources

The forth of a 12 part series on how to use Twelve-Factor App in practice. This entry is, again, written in collaboration with my good friend and (twice/double) former coworker Mycha de Vrees.

We will be implementing https://12factor.net/backing-services based on my/our combined experience on how to deal with resources/services although is is going to be a short one.

## Resource?

So let’s start with what a resource is, in short it is a service; Someone else their app which we use, i.e. the cloud is just someone else’s computer.

Take MySQL for example; * it runs somewhere, doesn’t matter where * it is out of our control (from our application point of view) * it may be not be available

## Internal vs External

The code for a twelve-factor app makes no distinction between local and third party services.

Treat it as external, it’s as simple as that.

### Uri

Let’s take MySQL as a resource, it should not matter where it is, your app should handle the url all the same.

• mysql://root:toor@localhost:3306/my_db
• mysql://root:toor@some.host.local:3306/my_db
• mysql://root:toor@mysql.example.com:3306/my_db

### Security

Even if it’s localhost, it’s still a service somewhere so treat it as such, use authentication and, where possible, SSL.

### Availability

Since we don’t control the service, regardless of what service, we need to consider it may not be available, the reasons are irrelevant. In practice this means it comes down to wrapping it in a try/catch/except.