Multiple containers, same application, behind a caddy reverse-proxy routing to container 1 or 2 in function of the path

[xmontero (Xavi Montero)]

Hi, friends, loving caddy, although a bit newbie yet. First post here.

Newbie question

I have a question that maybe is basic for you, but worries me a lot:

I maintain a monolythic dashboard published at some URL like for example https://admin.example.com/

It has multiple features gruped by routing, like for example those:

* https://admin.example.com/feature-1
* https://admin.example.com/feature-2
* https://admin.example.com/feature-3

I run a caddy inside a docker container.

Currently the dashboard runs in another container behind the caddy, who maps all the internet traffic to https://admin.example.com into the internal container with something like this:

admin.example.com {
    reverse_proxy * dashboard:80
}

where dashboard is the container name reachable from the caddy container.

The dashboard container serves the web from its internal root /.

Up to here, all works perfect.

Problem

The dashboard has been growing and we have approx 30 features. This reduces mantinainability of the code.

I want to split it into separated containers, something similar to a microservices approach but in the frontend. This will be a progressive splitting. Spring off feature-1 then next month feature-2 and so on.

Wondering

Say I start by stripping feature-2 out into another container:

• dashboard-old will serve all the features including the obsolete ones from /
• dashboard-new will serve only the feature #2.

I’m wonder if caddy can help me to route:

• https://admin.example.com/feature-2/* into http://dashboard-new/*
• https://admin.example.com/* into http://dashboard-old/*

Well in fact I already know that technically speaking it can. But there are 2 nuances I’m not sure how to handle: a) Path conversion and b) sessions.

My fear #1 - Path conversions

My fear #1 is about the “path conversion” back and forth from the outside and inside.

For example say the browser requests https://dashboard.example.com/feature-2/something-cool and it is routed to http://dashboard-new/something-cool

Until here, perfect.

But, what if this page contains links, AJAX requests, websockets, or whatever pointing to http://dashboard-new/tracking/id?

Reconverting this link from http://dashboard-new/tracking/nice to add again the stripped part feature-2 and rebuilding to https://dashboard.example.com/feature-2/tracking/nice seems something inside the HTML part and not the HTTP part.

As a context: I’m going to work with a dynamic frontend which is plenty of back-and-forth requests in the background (probably I’ll use React, not decided yet).

The intuition

I feel I should split the links into 2 groups: intra-feature and cross-feature.

1. If I work ALL intra-feature links with relative paths I guess I should be done: Have the page render always tracking/id without the leading / I feel I should be okey here.

2. And then use full hardcoded paths including the SSL schema for “jumping” to other features. If feature-2 has a global menu that allows to go to feature-1 and feature-3 that should be coded as the “externally accessible path” like https://admin.example.com/feature-1

I have silly wonderings as: Would it be easier if I configure the internal feature-2 container to respond the document-root into the same path than the extenal call?

Ie: I wonder if this is needed or not needed but is better or it’s is a silly dumb hypothesis:

• https://admin.example.com/feature-2/* into http://dashboard-new/feature-2/*
  instead of
• https://admin.example.com/feature-2/* into http://dashboard-new/*

Fear #2 - Sessions

Appart from paths, there’s a huge problem with the sessions here… container dashboard-new needs to share session with dashboard-old.

I’ve no clue on if caddy plays a role here or not and where to start reading documentation about multi-container mono-session behind a caddy reverse proxy.

The help needed

Before going ahead, before spending days doing the feature segregation into another container, I want to ask you guys:

• if any of you has any experience in placing “separated features” of the “same application” into splitted containers behind a caddy routing different paths
• what are your good and bad experiences
• and what are the things I should consider yes-or-yes before going ahead
• session issues you have found

All your real-world experience in implementing all this is more than welcome!

[francislavoie]

I think your questions are more-or-less covered by this article:

The "subfolder problem", OR, "why can't I reverse proxy my app into a subfolder?"

Have you ever tried to reverse proxy an app into its own little subfolder of your domain name? Makes things neat, doesn’t it? Using example.com/foo/ for one app, example.com/bar/ for another. If you’re coming here from one of the selfhosted communities, you might be thinking along the lines of example.com/sonarr/, example.com/radarr/ etc. Chances are, you’ve tried some configuration along these lines: example.com { redir /sonarr /sonarr/ handle_path /sonarr/* { reverse_proxy localhost…

I’d recommend that you use subdomains for each “feature”, so like feature1.admin.example.com or something similar.

That said, I’d say that microservice architectures… are a dangerous idea. You end up doing a lot of the same things in each one. Performance can suffer significantly because of added overhead.

Monolithic apps are fine.