The Heroku add-on architecture
Add-ons are one way to extend the capabilities of a Heroku application. The user can add a new service such as caching or data storage to the app by provisioning an add-on and consuming the service offered. Heroku users have two ways to provision the add-ons:
- The add-on marketplace
- The Heroku toolbelt client
The entire process of add-on provisioning and consumption is shown in the following diagram:
The following steps describe how a new add-on is provisioned and consumed by the Heroku app:
- The Heroku user requests an add-on using either of the two ways indicated in the previous paragraph.
- Heroku sends a provisioning request for the current account to the service provider for the given service.
- The service provider validates the request and creates a private resource for the caller and returns a URL that specifies the exact location and the credential required to access the service.
For example, the Amazon RDS service provider might return:
MYSQL_URL=mysql://user:pass@mydbhost.com/database - At this point, Heroku adds the returned URL to the environment of the requesting app, rebuilds the app again, and restarts the related dynos for the app.
- The app is ready to consume the services of the new add-on.
- The app extracts the resource URL from the environment and issues a read/write request to the service, passing the necessary parameters.
- The invoked resource within the service provider validates the authenticity of the requests and grants a privilege to execute the operation if the request is valid and the user is authentic.
- The resource creates a response and sends it back to the app, which in turn uses the result to create a page or store the response in the app's memory for later use and continue.
Note that the request for service from the app could either be from the user making a request in the web browser or a worker dyno asking for some resource while performing a long running background job.