Single Page Application deployment

I make heavy use of a similar stack and here are some solutions I’ve come across:

Backend options (option to store frontend with backend):

Gigalixir
A platform-as-a-service for Elixir. Very easy to use and I believe they have a free tier.
Their docs point to this helpful sample repo that includes assets that are compiled with Webpack. You can choose to store frontend here or not. I didn’t end up using them as I didn’t like the Python dependency.

Render.com
A sort of platform-as-a-service for all frameworks. No free tier, but the prices are reasonable. You basically just need to provide a build.sh file in your repo which handles building your app. If you wanted to store your frontend here, you would just need to add build instructions to the build.sh file. I tried their service and had no complaints, but in the end I found Kubernetes more flexible and easier for my use-case. I believe they use AWS or Google Cloud themselves.

Kubernetes on Google and Digital Ocean
This is what I use these days for all my projects (all are Vue 3 + Vite + Elixir apps). It’s the most productive recipe for me at the moment. I prefer keeping frontend and backend together as it simplifies deployment and testing. This approach is more complicated, but more flexible. I use Nginx in this setup. I maintain the details of this recipe in this repo.

Frontend options
If you want to host your frontend separately there many many options for that.

Free options
Render.com and now Digital Ocean let you host a few static frontends for free. The prices are very low even after the free tier.

Otherwise, there’s obviously Vercel, Netlify and soon Cloudflare Pages and probably a bunch of others.

Additional notes on storing frontend with backend
When storing the frontend with the backend, the Phoenix app serves the frontend content and assets. This Phoenix app may optionally also be behind something like Nginx. When storing the frontend separately with one of the providers listed above, the different services handle the serving of frontend assets for you mostly.

Thanks for your reply! Some really good tips and links in there.

One question that is still not clear to me is how a project structure looks like that say has an API component and a fully-fletched single page app as part of the same project.

In that sense, I’m still asking myself:

• Would I keep two projects, Phoenix backend and Gatsby frontend, independent? I have full control over the front-end but it comes with an overhead of configuration (nginx, e2e tests become harder…)
• Would I keep both backend and frontend together? If so how can you configure client-side routing, CDNs, and the webserver.

From a developer experience as well as a deployment point of view, what is an established pattern for developing backends and frontends?

Does this make any sense? Sorry, these must be very dumb questions

I have tried a few different structures and the one I like best is the one seen in this [folder](https://github.com/PotionApps/potionx/tree/main/packages/templates/src/project/potionx). Basically I keep all my Javascript apps in a folder called frontend in the same repository as the Elixir code and I serve the correct one based on the request’s domain or path. All requests go through the backend which routes the request to the right Javascript app. (Request → Elixir Backend → Controller → View → index.html containing the assets to a single page app)

I don’t think there is an established way of separating the two sides. At least if there is one, I haven’t found it yet. It all comes down to productivity. I’ve found that keeping the frontend apps and the backend together is the most productive for me in terms of ease of testing and speed of deployments.

In terms of configuring the client-side routing, I usually have Phoenix serve the right assets through a view like the one here. You can then use something like Cloudflare to serve the assets via CDN automatically if you’re worried about performance.

Your questions are definitely not dumb and I think many of us are still trying to find the best approach. There’s probaby no setup is going to suit everyone perfectly. I think you have to choose something that is most productive and least error-prone for you. In my case, I found managing only one project much much more productive than managing two projects.

Super helpful, thank you. I completely agree regarding the benefits of a “mono-project” for e2e tests and deployment.

In addition to what you’re describing, I found this article also very helpful:
https://medium.com/@resir014/a-phoenix-react-initial-setup-that-actually-works-c943e48f1e9e

It was incredibly helpful tuning the webpack configuration.

I ended up creating an umbrella project and serving my single page application through Phoenix (as you described).

I moved from Webpack to Vite myself (build times are too painful with Webpack), but thank you for sharing.

Glad to hear it all worked out!