Front-end/back-end service with ports


I’m just trying to understand the architecture of fly for an application that has a backend and a front end service.

They each have their own docker image and ports, and they need to talk to each other.

Does this mean 1 “app” with process groups, or 2 different “apps” in 1 org that communicate with each other over the private network?


either approach works.

at scale you’d often (but not always) want different numbers of replicas between the front end apps and backend so having them be separate apps makes sense. but if you’re very early in development or it’s a toy, using process groups is simple and should work

Awesome, thanks!

I would rather scale frontend/backend together as they are 1 to 1 pairing, and I can still size the “processes” separately.

Follow up, how do I specify the different images. The docs make no mention on how to specify different images for different processes. And none of my guesses worked.

Trying something like

  image = 'ceramicnetwork/js-ceramic:develop'
  processes = ['js-ceramic']

  image = 'ceramicnetwork/rust-ceramic:develop'
  processes = ['rust-ceramic']

  js-ceramic = ''
  rust-ceramic = ''

different images require different machines (apps). a quick glance at ceramic… I honestly can’t tell what the expectation is for deployment.

it looks, to me, like the front end component does expect to be colocated with the go ipfs bridge thing, one approach would be to build a new docker image with both. that said, two apps would work fine

1 Like

From How To to Questions / Help

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.