Stand-alone web server

[KairuByte]

A stand-alone web server would likely make more sense for large networks, than putting the web server on the proxy or choosing a random back end server.

Exporting data is quite expensive, so the current external web server option is not a good option for large sets of data.

Ideally, such a change would grant the ability to simply run plan directly within Java, stripping out the need for a minecraft server completely.

[cody-quinn]

I agree. Being able to host Plan on a dedicated web server would be nice.

[rymiel]

Realistically, should #1623 and #1965 be solved before tackling this thing? Perhaps even #1987

[AuroraLS3]

@rymiel The features of the linked 3 tickets are independent from the runtime environment.

While I haven't refined this issue to write down what needs to be done, I think the easiest approach is to have a standalone Plan instance take a read-only identity of a server in the MySQL database - be that the proxy or a game server. ServerInfoFile.yml could be used as a way to choose what the standalone Plan instance reads.

The abstraction level is sufficient to replace where Plan is running on, so it should be possible to run Plan with a Main class as long as all the things have implementations - even if no-op (ListenerSystem for example won't have anything to do but it's still expected by Dagger).

A lot of assumptions break down during this and can cause unexpected things, since two Plan instances identifying as the same one is not something anticipated when coding. I'll try to include those when I eventually refine what needs to be done for this.

[AuroraLS3]

TODO

• [x] Implement standalone platform abstraction
  • [ ] Implement Platform Abstraction Layer code for standalone
    • [x] Copy ScheduledExecutorService based RunnableFactory and tasks etc implementation from fabric module
    • [x] Implement console logging (Optional: Chat colors)
      • [ ] Implement to-file logging as well after implementing commands so that std.in is placed there too. <date>.txt is fine.
    • [x] Implement PluginInformation
      • [ ] Make sure to place the config directory in the jar start-up location - JVM by default places files to user directory on linux if not careful (Might be able to use System.getProperty("user.dir"))
    • [x] No-op Listeners is fine since there won't be any listeners.
    • [x] Add a stop command that stops the program
  • [x] Create standalone dagger component
    • [x] initialize dagger component in https://github.com/plan-player-analytics/Plan/blob/standalone-mode/Plan/standalone/src/main/java/net/playeranalytics/plan/PlanStandalone.java
    • [x] Enable PlanSystem in there as well
    • [ ] Bind following tasks: LogsFolderCleanTask, JSONFileStorage.CleanTask, ResourceWriteTask
• [ ] Standalone run environment specific things
  • [x] Run PlanSystem stuff on a separate thread from Main so that Main thread can be used for Std.in (System.in) wait loop (Scanner can be used for this)
  • [ ] Implement Std.in based command stuff - no need for fancy stuff (tab completion is very optional since that might be difficult.)
  • [ ] Listen for Command Interrupt and disable PlanSystem before exit.
  • [x] Add gradle configuration that starts the java application when jar is run directly (I think it needs specifying main class)
  • [ ] Detect if Java application started without console window and exit if necessary (To prevent double clicking the jar from starting Plan in the background)
  • [ ] If enable fails, Wait for 30 seconds before exit to give time for user to read why the enable failed.
• [x] Implement standalone specific Plan code
  • [ ] ServerInfo - should read the database for the server specified in ServerInfoFile.yml - Don't enable if the file is not present. Create the configuration folder with a Install instructions that say to copy ServerInfoFile.yml and config.yml from the other server.
  • [x] Config - Attempt to enable webserver every time by setting the webserver enable setting to true in ConfigSystem implementation if it's false
• [x] Shadow the standalone module in plugin-module and make sure it starts with java -jar Plan.jar

If lucky, that's all that's needed and Plan will just chug along as if it was the specified server without writing any data. It is important that the Server comes from database, expecially the Server#proxy since that is used for determining whether to show network or server page.

[AnttiMK]

A couple of additional ideas for implementation:

ServerInfo - should read the database for the server specified in ServerInfoFile.yml - Don't enable if the file is not present. Create the configuration folder with a Install instructions that say to copy ServerInfoFile.yml and config.yml from the other server.

On first start, we could query the user for MySQL connection details directly in the console, and when (if) the connection succeeds, query the user about choosing a server, maybe with the following message:

Please choose the ID of the server you'd like Plan to show data for. 
A proxy server (Bungee etc.) is preferred when running in a network
environment with Plan installed on the proxy AND the backend servers.
----------------------------------
ID - Server type - Server name - UUID

1 (preferred) - Bungeecord - Awesome Minecraft Network - a33361f4-4338-4921-b127-7f36c5f35504
2 - Spigot - Survival - 9cb34504-8e47-4c09-b924-76d57ea848b4
3 - etc...

ID of server to show data for: <wait for input>

This would lessen the need to touch config files, and would make for a smoother a) "install" experience b) console application.

[AuroraLS3]

Did some work on this on standalone-mode branch, but it is still pretty unusable since it thinks it's a game server. Enables fine though :)

[RareScrap]

Any progress on this? This feature would be really sweet when it comes to deal with multiple server analytics hidden by Velocity.

[AuroraLS3]

Haven't had the time to progress this. It's pretty high up though since I don't want too many in-progress branches

[TobiasGrether]

Yeah this would be a lovely feature. Just a docker image with a REST API to post the data points to, plus a database to connect it to would be optimal.

[TobiasGrether]

Note from discord: It would make sense to add support for environment variable configuration. Standalone versions of plan might often be run in a docker container where a config by env variables will be easier than by file.