Future of Dice Servers

[RoiEXLab]

Now that #5091 is done I want to discuss the future of dice servers in general.

What we're all agreeing on

The PHP code of the dice server is something no one really wants to maintain for various reasons.

1. I don't think anyone here is an active PHP developer, so nobody really knows what the best practices are etc.
2. There are no tests at all, no CI, no CD, if we ever have to maintain this code for some reason (like migrating away from some domain) we have to hope it still works on the respective server.
3. And obviously the general PHP hate 😋

What we have

triplea-game/dice-server-js is a 99% functional replacement. It has linting, and automated tests in place, CI runs on every PR and commit. So changes can be made in a relatively safe manner. However Problem 1) might still exist in some form. AFAIK only myself (and maybe @ssoloff ?) are active JS developers, but on the other hand it's not that different from other C-style languages.

Current Problems

There are quite some tests there, it should have a somewhat decent coverage, but the test quality is lacking in some areas. Also there's an XSS vulnerability as well as a missing feature to customize subjects on mails. However if I invested a weekend of my time into it, I could easily fix the vulnerability and implement the missing feature.

Future Problems & Open Questions

In order to make this new software an actual replacement, we'd still need some sort of convenient way to deploy it. Could ansible be the solution here? @DanVanAtta The situation we have with the current dice server is really not bearable.

Also who is gonna maintain it? Me, anyone else?

Also we'd still need a REST client to actually make use of the server, but this is really the easy part. The JSON makes it real easy to parse everything.

Also some time back the question came up if sending emails as confirmation is still a good enough concept. Maybe having a simple web interface that shows rolled dice for unique "session ids" for everyone to have a look at is far more convenient? This approach has the drawback that all of the sudden the server becomes a data dump for everything, so we'd need some sort of cleanup mechanism (remove all games without any rolls for more than one year maybe?), but I could really imagine this to be a better - and modern - approach in general.

But all of those ideas would require extra work, which would require more than one person to actively work on it, at least someone that reviews some implementation steps.

This is why maybe a change of technology might be the right choice here. If we want to change the backend to java, to align more with the HTTP server (or even incorporate it into it) then this Problem would go away. The existing code structure could more or less be re-used, so no need to come up with an entirely new concept. The only thing that would need a lot of consideration is how to re-do the frontend: The current "frontend" is really just some plain HTML that uses liquid (the backend of jekyll), so no need to learn something new there. An implementation in java exists, so we could easily just copy the templates and re-use them.

Another possibility would be to TripleA itself as only client, but I don't think this is a good idea if we ever want to move away from sending emails, because building UIs in swing isn't really fun at all.

What seems like a good idea to me as well (mainly because I'm used to it) is to create a separate frontend using react. I have used a lot of react in the past, and I feel like it makes it really easy to create good looking UIs for simple data. (If the data has circular references etc. it gets really annoying, but that's a different story). Also because building UIs is more or less like writing HTML just with a linter, it should be really easy to use for the core developers here? In case you're wondering, the "new linode interface" is written using react as well: https://cloud.linode.com Instantly noticed the familiar look when it was first introduced.

I really like to hear your thoughts about this, any ideas, any concerns?

[DanVanAtta]

There's a good bit to consider here, thanks @RoiEXLab for raising it.

How many front-ends do we need?

It sounds like we need a front-end for registering to the dice server and a second for viewing results. My impression is the previous registration page was a quick-and-dirty PHP page because it was not super-easy at that time to integrate that process into the game. I suspect it'll be a good improvement to bring dice server registration in-game.

We need some consideration for how to view dice rolls. I think I see three options:

• A) in-game results, a menu where you can request to see dice roll results
• B) a webpage
• C) emails

A+C avoid us having to build a front-end. There is a big question of how/when users would want to verify dice rolls. It might be nice for it to be in-game and have verification be automatic. IE: user requests dice rolls to be verified, the game fetches rolls from the server and then verifies those rolls against what is in the history.

Some additional considerations:

• I'm not sure if we save the game UUID with the game today, we'd need a way to associate a game save with a game that is on the server
• In the future I'd like for game-saves to be "cloud" enabled. Essentially have a PUT interface on HTTP so that games can be sent to the sever. We might be able to bundle that capability with verified dice since the server will be keeping track of game saves anyways.

JS Server vs HTTP

The reduction of components is nice, I might be leaning towards an HTTP endpoint., particularly given that we have HTTPS coming online. On HTTP we can re-use DB logic for persistence, setting up the endpoint is pretty straight forward.

Are there any additional advantages to a JS-backed component that are not being considered beyond the fact it's pretty much built?

Overall Design

I'm glad to have this issue be brought up, we have quite a bit to design here. I think our first focus should be on UX, stay a bit forward looking so we can merge dice rolling into future capabilities. With luck that'll give us a pretty good picture to know what technologies/stack/system components we'll need.

[ssoloff]

Sorry, I don't really have much to offer to the overall design discussion. The only thing I can contribute is what I remember talking about when the dice-server-js project was first proposed several years ago. That is, that the short-term goal was to get a functionally-equivalent replacement that devs were more comfortable with and not afraid to change (due to PHP inexperience, lack of tests, and deployment complexity). From there, it should be easy (or, at least, much easier) to build all the other design proposals above on top of it.

[ron-murhammer]

My general thoughts are:

1. Ideally we eventually convert it to Java so its easier to maintain and so we can look to use the same dice generation algorithm for the dice server, lobby, and local games.
2. IMO, email results are enough for now or at least in-game or webpage for results isn't super high priority.
3. Dice email registration is important and ideally we'd make that part of in-game rather than a separate webpage.

[beelee1]

Recommended for PHP hate in general :)

[DanVanAtta]

@RoiEXLab, it's a good overview in the OP. We have a couple questions, I would suggest we first focus on deciding if we want to migrate the backend dice server to spitfire or keep it as a standalone JS app.

Pros:

• one less technology and system component
• existing deployment/infrastructure would exist, no need to build deployment tooling for dice server
• potential to re-use dice rolling in other code without service calls
• can skip fixing the XSS issue

Cons:

• we have the dice-server.js mostly built, we'd see some code churn redoing it in java
• we'd have to fix any of the issues in the java stack
• we'd have to build new tests to verify the service in java

Let's make a concrete decision on the backend component.

[DanVanAtta]

@RoiEXLab any updated thoughts on this topic?

[prastle]

@beelee1 PHP runs the ladders thus I bought the program from Tournamatch. Sadly they either need to build their own as they said they were going to... or learn to love it :)

[RoiEXLab]

The Pros are intriguing, but I think incorporating it into Spitfire would only work if we have a concept for email registration or drop the email concept all together. Obviously it's easy to create a dialog for this, but where exactly should we put a button for it, or should we send the registration request automatically whenever the API notices that the email is not registered?

[DanVanAtta]

The HTML registration page could be hosted on nginx. Adding a Java UI component somewhere would likely not be a problem either. It's probably better IMO to first determine the system/architecture design, then we can work out the details of the UI after that decision.

[RoiEXLab]

In this case I think trying to integrate it into Spitfire seems like a reasonable thing to do.

[RoiEXLab]

I'd keep the current repository in an archived state though.

[DanVanAtta]

It's a shame we didn't get the dice-server.js deployed sooner. I think we are decided we'll consolidate techs to the java stack. Is there any urgency to answer the UI question? Can we answer the questions on UI, when or after the new backend is in place?

[RoiEXLab]

I think we should at least think of a concept on how to confirm your email registration. We'd have to either create an HTML page just for confirmation (how are we currently doing this for normal registration?) or just create link that directly points at the rest api. Alternatively we could make use of the triplea url handling, but that might not be supported on all systems

[RoiEXLab]

But once we agree how to handle this on an abstract level, we can start with the backend and handle the details later.

[DanVanAtta]

Are we decided to migrate dice server to http instead of a node.js app?

[RoiEXLab]

@DanVanAtta I think so