Racetrack: exclude web UIs for human clients? A proposal to tighten scope

[JosefAssadERST]

I have a proposal for which I'd like to take a temperature reading from RT developers and users.

In the spirit of "don't try to be something for everyone, be everything for someone", I propose that RT be scoped more narrowly to focus exclusively on HTTP services and not web UIs. So, machine clients not human clients.

The reason is, I suspect that having to accomodate serving interfaces to web browsers has a complexity cost outweighing its utility.

Consequences if we agree

We have a Hugo jobtype, and a Drupal jobtype. Both are examples of functionality which would get killed off by this tighter scope. The good news is, no one's using them, they're PoC so far. I think internally in ERST we have a few jobs with fairly straightforward web UIs; if we agree on the principle they don't need to be reworked right away, the capability can be deprecated until such time as they can have their web interfaces moved outside of RT.

Benefits

• Simpler system architecture, tighter scope.

Disadvantages

• Some of ERST internal models will be using deprecated functionality
• Some of the "pie in the sky" ideas we've had over the years are excluded, but then again none of them have come down to earth since

Thoughts? @iszulcdeepsense @mariushart @anders314159 @LookACastle @ahnsn

(to tag: Martin Clausen, who was invited but allowed his invite to expire)

[LookACastle]

Do we save anything in software complexity here? If I remember correctly - and do bear in mind that I'm not the most active on Racetrack lately - these web UI's don't really have a lot of specialized scaffolding or anything.

Regardless of whether this is useful from a dev perspective or not, I do agree think it's a nicer, tighter description of Racetrack from an architectural view. I also think it doesn't lose any real usefulness - hosting Doom or Drupal on Racetrack was never going to be anything but a proof of concept if you ask me.

If we chose to not support UI's and such in the future, we could consider just changing a few lines of documentation here and there. If I'm right that there's no real overhead to allowing jobtypes to host HTML pages and serve them, then there's no reason to forcefully deprecate anything. Just let it be a niche "technically you could, but ask yourself if you should" type usecase.

[JosefAssadERST]

Do we save anything in software complexity here?

I'm in the same boat as you, @iszulcdeepsense knows better. But I seem to recall snags in PUB back when we were working on Drupal/Wordpress PoCs.

If I'm right that there's no real overhead to allowing jobtypes to host HTML pages and serve them, then there's no reason to forcefully deprecate anything

Maybe, yeah. If there's some overhead though, a tighter scoping means when someone comes and says their Adobe Coldfusion job type doesn't work, we can point at the scope. If it works for some, it's a happy accident we aren't going to shoot them for.

[iszulcdeepsense]

the capability can be deprecated until such time as they can have their web interfaces moved outside of RT.

The functionality of web interfaces is in fact moved outside of Racetrack core, it sits in the plugins. Like support for Drupal, Quake 3, it's handled by plugins.

Do we save anything in software complexity here?

Not really in the Racetrack core, but in the plugins - yes. Due to URL rewriting, there are weird things going on in https://github.com/TheRacetrack/plugin-docker-proxy-job-type?tab=readme-ov-file#how-it-works. Take a look at https://github.com/TheRacetrack/racetrack/issues/282#issuecomment-1803848321 to see why Path rewriting breaks front-end apps in Racetrack. Turns out that it's very problematic to serve some apps on Racetrack. Thus, it might make things simpler and less surprising in some places.

So I'd say Racetrack core already focuses on non-UI interfaces at this moment, and when it's used otherwise, it needs a bit of hacking. In most places, Racetrack doesn't care what's inside the HTTP request, whether it's JSON or HTML, that's why it's up to plugins to provide web UI or not. If we decide not to do it in Racetrack, most of all we'll need to just stop doing web UI plugins, outside of Racetrack.

[JosefAssadERST]

And this works with no funny business?

[iszulcdeepsense]

Disclaimer: My opinion may be biased. If you ask a back-end engineer about web UIs, you should already know the answer.

[iszulcdeepsense]

And this works with no funny business?

Yes, it's a bit different story (that's why I think it's confusing to outsiders). It works fine if you follow the Racetrack standards from the very beginning. But it's a nightmare, if you want to turn some random Docker image into a Racetrack job with web UI.

[LookACastle]

So, should this proposal go through, we stop supporting UI plugins of our own, and that's more or less it?

[iszulcdeepsense]

Surprisingly, I liked this idea

[JosefAssadERST]

But it's a nightmare, if you want to turn some random Docker image into a Racetrack job with web UI

That's probably worth avoiding.

So, should this proposal go through, we stop supporting UI plugins of our own, and that's more or less it?

Looks like it. It's mostly pre-emptive scoping at this stage, no one's running facebook.com in Racetrack just yet. I am thinking a bit ahead when people get good ideas about how to use RT, that we try to nudge them to do easy things not hard things.

[JosefAssadERST]

Surprisingly, I liked this idea

You're surprised you liked one of my ideas?

[mariushart]

Better late than never, I like the idea too..