Open jdpage opened 9 years ago
After several false starts, I think the best approach for this is going to be in Symfony. Using anything other than PHP defeats the purpose of making this useful to run on commodity shared hosting, and making it a single-page Javascript app, on examination, might actually be worse than using PHP, since I'd have to write a bunch of PHP anyway in order to make it secure.
Hey @leafstorm, do you have any good resources for getting started with Symfony?
It's been a good while since I had to get started with Symfony, and I'm not really plugged in to the local PHP community. I'm also not sure exactly what this project is. So I'm not sure exactly how useful I can be here.
Symfony just recently released a nice demo application, though: http://symfony.com/blog/introducing-the-symfony-demo-application. And here's the getting started guide: http://symfony.com/doc/current/quick_tour/the_big_picture.html.
What's the functionality that you want the Web UI to have, though?
Thanks, I appreciate the links; that was pretty much what I wanted. Mostly the app is just going to have a login and some buttons that trigger some server-side code that consumes some REST APIs.
I made the mistake of rereading eevee's PHP screed yesterday, so now I'm re-debating between writing this in PHP or maybe having another go with Python/Flask? On the one hand, it's a pretty simple PHP application, so it'd be nice to have the ability to deploy wherever, and I don't want to write a bunch of Python 2.x code. On the other hand, I'm not entirely sure I want to maintain a PHP application either.
Well, first question is, why do you want to have two separate Web apps running? Is there a reason you can't just plug the UI into the Python daemon that provides the REST API's?
Second question, if you assume that the admin can deploy a Python Web application and wire it up to their Minecraft server to provide the API, why would they not be able to deploy a UI written in Python?
The only explanation I can think of right now is that the UI is meant to be deployed by someone other than the Minecraft server admin...and I don't know what use that could be. But I might be missing something.
(Also I'm pretty sure Flask supports 3.4+ now. The extensions I wrote for it sure don't though...)
So the point of it is that the Python daemon is running on a VPS/Droplet/EC2 or something else relatively expensive and high-powered, while the UI is running on commodity shared hosting and allows for server users to safely spin up the server instance, and then automatically shut it down if nobody's been on it a while. It's basically a very very overengineered cost-saving measure.
very very overengineered cost-saving measure
Quite. Especially since I don't think it would actually save you any cost. DigitalOcean still charges you even when the droplet's shut down -- unless you want to snapshot, destroy, restore, and change IP every time you stop and start the server. I'm guessing EC2 works the same way.
That said, if you do want to keep this separate API/control panel approach, the control panel should definitely be multitenant. So you could have one control panel that works for all your Minecraft, Starbound, etc. servers. Maybe even allow the user to connect a DigitalOcean account, and deploy the server image for them automatically.
unless you want to snapshot, destroy, restore, and change IP every time you stop and start the server. I'm guessing EC2 works the same way.
That's exactly what it will be doing.
You'll probably want to create a completely separate repo for the control panel, then. And integrate DNS update support so the user doesn't have to change the server IP address every time.
(This actually seems like a pretty fun project now... Is the idea behind this basically "DIY Realms?")
You'll probably want to create a completely separate repo for the control panel, then.
Why? That was how I was originally going to do it, but they're essentially two parts of the same project, so I dunno.
And integrate DNS update support so the user doesn't have to change the server IP address every time.
Probably a 0.2 feature. 0.1 is about getting this working well enough for me to deploy to use to play with my siblings, which basically means it needs to work well enough for me to use it and well enough for Sam to use it without him getting P.O.'d at it, so for now just showing the IP in GUI somewhere is probably enough.
Meta-issue for UI completion.