Is this architecture sane?

I’m brand new to fly.io and also to Phoenix/Elixir. I’m designing an application and have a basic architecture in mind that would be reasonable in a more traditional cloud environment but I’m not sure if it makes sense when using fly.io. The system will include:

  • a Postgres database
  • a Phoenix backend
  • a React web client app
  • a static site

In a traditional environment I’d have an Nginx instance that does something like route / to the static site, /app to the React app, and /api to the Phoenix server. I think a straight-forward translation to the fly environment would be 3 fly apps:

  • frontend – Nginx container with the static site and static React assets bundled
  • backend – Phoenix cluster
  • db – Postgres cluster

So my question I guess is whether the Nginx app makes sense in the fly environment? Would a couple of [[statics]] mappings in the fly.toml for the backend app be better? I’m not trying to ask so much about certain standard tradeoffs, like not being able to deploy the client and backend separately if they’re bundled, but more about whether including the Nginx app is in some way in violation of best practices when it comes to fly apps specifically.

I apologize if my question is too vague to answer properly, I’m happy to provide more info if needed! Thanks ahead of time!

Hi @achilles thanks for putting down that much detail. I don’t think there’s a “right” or “best” way to do this, but I can tell you what I do:

  • When I do a full stack Rails (or Phoenix) app that serves HTML and has CSS and JS bundled in the app itself, I use the [[statics]] feature to handle all the CC/JS assets and public folder requests. This frees up the app to do the actual work instead of static file service. Offloading this would have otherwise required nginx, but the [[statics]] section handles that just fine.

  • When the backed is purely an API deployed on Fly and serves no static files, and I have my frontend as a purely static site like a React app or the output of a static site generator, I usually use a specialised JAM stack service like Netlify, Vercel or AWS Amplify Console. I could just deploy it to Fly with an nginx container or the static builtin, or just a dummy echo server with requests offloaded to [[statics]] if I wanted to, but personally I prefer the purpose-built systems that don’t have containers running just for serving static files.

That said, if you have any reason to want to serve your frontend static files on Fly you always can. The [[statics]] feature copies over your directories to the proxy server to serve them quickly and efficiently, or you can run the static builtin if you want to customise the container in any way, or you can run nginx for complete control over every aspect of the responses, including URL rewrites, caching, cookies, etc.

Thanks, that really helps! I think I know what I’m going to do!