Adam Wiggins
2.2 KiB
VII. Port binding
Services exported via port binding
Traditionally, web apps are executed inside some kind of runtime container. For example, PHP apps might run as a module inside Apache HTTPD, or Java apps might run inside Tomcat.
The twelve-factor app is completely self-contained and does not rely on runtime injection of a webserver into the execution environment to create a web-facing service. The web app exports HTTP as a service by binding to a port, and listening to requests coming in on that port.
In a local development environment, the developer visits a service URL like http://localhost:5000/ to access the service exported by their app. In deployment, a routing layer handles routing requests from a public-facing hostname to the port-bound web processes.
This is typically implemented by using dependency declaration to add a webserver library to the app, such as Tornado for Python, Thin for Ruby, or Jetty for Java and other JVM-based languages. This happens entirely in user space (within the app's code), and if the developers chose to, they could write app code to accept raw TCP requests and parse the HTTP without any supporting libraries. The contract with the execution environment is binding to a port to serve requests, leaving the implementation details of what webserver is being used up to the web framework and/or the app's developers.
HTTP is not the only service that can be exported by port binding. Nearly any kind of server software can be run via process-binds-to-a-port-to-receive-requests model. To examples include ejabberd (speaking XMPP), and Redis (speaking the Redis protocol).
Note also that the port-binding approach means that one app can become the backing service for another app, by providing the URL to the backing app as a resource handle in the config for the consuming app.