Question

App Platform component to component requests

I’m interested in hosting an Nginx reverse proxy on App Platform via Docker which will be used to proxy requests to other components in the same app and enforce rate limits.

I’ve seen a few references to internal communication via App Platform:

  1. How to call an App from another service / app?
  2. How to run single nginx and multiple Laravel instances in the App Platform
  3. How should I implement proxying and redirects on the app platform?

I can’t find any official documentation about the App Platform internal routing feature, but the consensus seems to be a component in App Platform can send requests to other components within the same app via http://component-name.

For example, consider an App Platform app with the following components:

  1. Nginx reverse proxy named nginx (Web Service)
  2. Rails server named rails-server (Web Service)
  3. Go server named go-server (Web Service)

It appears as though Nginx can proxy requests to the other components by listing http://rails-server and http://go-server in a proxy_pass rule.

My questions are as follows:

  1. Where can I find App Platform documentation for this feature?
  2. Do components in an App Platform application exist within a VPC?
  3. Are component to component requests such as http://${component-name} routed on the public Internet?

The internal routing functionality seems like quite a feature but I’m concerned about the fact that I can’t seem to find documentation for it.

Submit an answer

This textbox defaults to using Markdown to format your answer.

You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!

Sign In or Sign Up to Answer

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

Bojan D • December 29, 2020
Accepted Answer

Hello, Thanks for your interest in DigitalOcean App Platform.

  1. All service components in the same app can communicate over a local network using the component name as the address. Additionally services can be configured to be “internal services” by specifying “internal_ports” property in the app spec. Here is an example repository utilizing this feature. I agree the documentation for this feature is lacking, and we are working on enhancing it with more details and examples.

  2. No. We are exploring VPC for our roadmap potentially, but nothing to share publicly.

  3. No, services within the same application share a private network, and these internal requests should not go over public internet, and don’t count against the bandwidth utilization for an app.

Cody Baker • December 29, 2020

It looks like @bojand beat me to this. I’ve left mine below as it adds some additional details. Sorry for the sparse documentation. I’ve made an internal ticket to prioritize official documentation of this functionality.

Each App Platform App has a private network, though at present these are separate from customer managed VPCs. Workers, jobs, and services may connect locally (not over the public internet) by component name to services within the same app.

The app spec document for service components may include a list of internal_ports, and/or an http_port. http_port is required unless at least one port is specified in the components internal_ports list. If an http_port is specified, the service will be expressed both internally within the same app AND publicly at the apps ingress domains. Services with at least one internal_ports port and no http_port are only accessible locally within the same app.

The component name of each service resolves (via the app’s default DNS server) to a load-balancer which balances new connections (layer 4) across each healthy service instance. If you’re using the internal_ports, the load-balancer will be available at each listed port.

For example, a service web with a spec {"services": [{"name": "web", "internal_ports": [8080, 3000]}]} would be available at http://web:8080 and http://web:3000. If a the service specifies an http_port, it’s available at that port and port 80, unless it’s otherwise overridden in the service’s internal_port.

For example, {"services": [{"name": "web", "http_port": 8080}]}) would be available at http://web:8080, http://web:80). A port specified as http_port MUST implement the HTTP protocol, but internal_ports can facilitate any TCP protocol.