Migrating DRTS Game to Kalmit

Following is a writeup of current work to simplify the DRTS online game server by migrating the implementation to a single Elm app.

This week, I migrated the client-side part of the DRTS game implementation from Elm 0.18 to Elm 0.19. On the server side, only the core game mechanics had been coded in Elm so far, as those need to be consistent with the client implementation. Other server parts, like the exchange of text messages between players, were not implemented in Elm but C#, closer to the hosting .NET core app. The version still running in production instantiates an Elm app for each online game, and when that game is over, the server removes that Elm app too.

To reduce development and operation expenses, the server design will be simplified to use a single Elm app, processing all games and other activities like chatting. This makes development easier, for example for features like matchmaking and player profiles.

What priorities in Kalmit result from this application? What functionality needs to be added on the Kalmit side to support this use-case and make for a pleasant experience? Since the server now becomes a single Elm app, it looks like I can cover automated tests mostly with elm-test, so reaching for Kalmit seems not necessary for this part. For manual testing though, it would be nice to support quickly starting a new server instance after a change in the source code. How could this work? Following is a course idea, after skimming over the current implementation of DRTS, before starting with the implementation to support this scenario:

• Implement a CLI for Kalmit to support starting an instance of the web host, given a client Elm app and a server Elm app. To specify the client app, a file path might be sufficient. As long as the generation of app state serialization functions is not automated, we need to supply the elm-app.map.json for the server app or replace it by a convention for naming the entry points. I have not yet looked into the implementation of the serializer code generation, the effort needed there is unknown to me. I prefer to not block DRTS on this and instead manually supply those functions for now.
• How to solve user authentication? The current implementation uses Auth0 to authenticate users. The flow includes sending an HTTP request to the Auth0 API. It seems porting this functionality will need a new feature in the interface between Kalmit host and Elm app, to support requests from the Elm app to send HTTP requests.
• To support navigation with URLs, we need a way to specify the set of URLs from which the server should return the client app HTML document. This could be done by specifying a map.json to include in the web app config, assuming a convention for the path in which the CLI tool places the compiled client HTML document static file.
• [Bonus, Future?] [Optional, depending on CLI argument] File watching: Offer an option to automatically start a new instance of the server when the server code has changed. (We could compare the outputs from Elm make to know if this happened)
• [Bonus, Future?] [Optional, depending on CLI argument] Offer to reuse the server app state from a previous instance when starting a new server instance. This would not (yet) include a migration, only reuse the app state if the state type remains the same.

I am updating the backlog to include the essential items identified above. Not including the optional ones for now, as I am not even sure if I will miss those for the current iteration of DRTS.