Just an update on progress. You may not have noticed any major updates/features, but over the past few weeks I’ve made a lot of backend changes to Gamocosm. Hopefully, this will set the foundation for future development (e.g. learn a better way of doing things, refactor or redo old code) and also make Gamocosm more reliable.
Firstly, the tests have been overhauled.
The tests nolonger make real API requests, which does mean those aren’t fully tested, but on the plus side, the tests are much faster now and also deterministic.
I’ve also added a Docker image and server side implementation of the Minecraft Query protocol so
Minecraft::Querier can be better tested.
As of 2015 February 14, coverage is at 90%, and these tests have certainly saved me a lot of time and from a lot of bugs, especially when I have been doing major refactorings (like I did today/this past week).
A minor change has been loading some Digital Ocean data asynchronously (client side AJAX), and caching those responses (list droplets, list images, list ssh keys). This has largely reduced the load time on certain pages. In addition, a lot of refactoring in the routes and controllers went along with this.
Thirdly, error handling improvement is in progress, hopefully almost done (have yet to carefully scan through everything). Along with this, I’ve reduced several dependencies for finer control over behavior. Now, Gamocosm only uses Faraday for making HTTP requests. Gamocosm interacts with 3 APIs:
- Digital Ocean for creating/destroying/etc. your servers
- CloudFlare for DNS (user server domains)
- MCSW on each user server to start/stop/etc. Minecraft
Each of the wrapper classes catch and (broadly) handle network exceptions, as well as silencing any other exceptions. I wanted to silence exceptions in these classes because I can’t fully rely on API responses; the structure might change, I could have random, non-deterministic failures, etc. So, if anything goes wrong, I don’t want a 500 crash page, but rather for Gamocosm to log, email me, and try to show something to the user.
Finally, today I’ve massively refactored everything related to Digital Ocean API requests. Problems before include:
- depending on the structure of Digital Ocean’s response; I used the Barge gem which returned a
Hashie::Mashified version of the response, and I directly/randomly used it
- strewn all over the place; e.g. the Digital Ocean gem client is used in
DigitalOcean::Regionwhich really were classes that returned arrays of hashes of the actual sizes or regions
So that’s all been redone:
- no more Barge gem, and no more Hashie
- if Digital Ocean changes their API (currently in v2 beta), I can update it ASAP
- Hashie is easy to use, but slow and unecessary
- actual classes (inheriting from Struct) representing Digital Ocean objects
- Size and Region actually are what their name implies
- the rest of the application uses these classes; if Digital Ocean changes their API, I only have to update
- hopefully cleaner handling of missing or invalid API tokens
I’m not entirely sure what’s coming in the future. Firstly, I want to give a heads up that real life/other things are geting much busier, though I’ll continue to try to respond and update frequently. I definitely want to get test coverage as close to 100% as possible (sooner better). I’ll likely be working on that in the near future.
As for other improvements or features, I have these in mind:
- refactoring so it would be easier to support different server hosting backends
- actually, the recent refactorings have untangled Gamocosm a lot from Digital Ocean, although a lot remains to be done
- I’m not convinced Gamocosm really should support other providers (it’s nice, but how necessary?), but decoupling is always good
- finer friend permissions on servers (GitHub issue 17)
- better landing page
- support for non-Minecraft servers
- initially, this will just be an option to have Gamocosm only start, stop, backup, and delete a server (don’t try to setup or update)
If you have any suggestions, please let me know by submitting an issue on GitHub. Thanks!
PS: To better support MCServer I am planning to work on a plugin for the query protocol. I’ve done a basic Lua implementation using LuaSocket, but ideally it should use MCServer’s network APIs. The MCServer team has actually recently overhauled that, but unfortunately, it only does TCP. I plan to try to help with adding UDP support, but haven’t got a chance to start on it because I’ve been extremely busy this past week (and will be busy in the near future too). Definitely hope to get some progress on that this week, and you can follow progress at GitHub issue 797. Be sure to check them out if you haven’t already!