Dev blog 29/06/2018

As mentioned in the previous dev blog, we have also not been working on much visual stuff lately and therefore we have waited a while with creating another dev blog.

Release of version 3 is not that far off in terms of what needs to be done for it to be release ready.

The development of a free to use DRM based on SecureGMod but heavily improved has been going on for a while now and we said we would release this before v3 of the site. Most of that DRM has already been made and it's just missing one final component that we hopefully will have finished soon.

The scope of this dev-blog however will be what's left before v3 can finally release and what we have been working on the past month.

Josh's work

Team-wide sales

Josh started off the month working on sales that aren't only global, but also within the scope of a team.

You can now create sales for addons in a specific team, this completely replaced the discount field when editing an addon. That field no longer exists.

Event logs

Next up Josh has been working on an event log service based on my work with the event logs where I last left off. This system doesn't mean much to anyone who isn't a moderator but your own event log will be displayed to you somewhere on the website in accordance to our Privacy Policy & GDPR.

v2 of the API

The API has been completely re-worked from the ground up to fit a REST standard for APIs, if you're curious about what the new api will look like you can find the full work-in-progress documentation here.

As I mentioned, the API is still a work-in-progress and so is the documentation related to the API. We're thinking about moving the api to an api.gmodstore.com subdomain to ensure up time if the main app goes down, so any endpoints in the current documentation may not be final.

The old API will continue to function at www.gmodstore.com/api/* for a month after release until it's removed

Marcuz's work

During this month I've been moving between the download server and the ipn server. This means I've essentially done no visual changes or new interesting pages.

Download server

I started off fixing the download server up for version 2 of the site while also implementing an addon.json config that will supplement addons in terms of auto updating, applying various levels of protection(DRM VM, obfuscation, minifying) and last but not least, the addon tracker some of us remember from CoderHire.

If the DRM launches with v2 the DRM part of the addon.json config format will be useable to protect your addons already in v2. However if the DRM is not done at the point of v3 release it will come a bit later. This depends on whether or not Matt has enough time to finish the remaining part that I depend on.

I've also prepared the download server for eventual use with both v2 and v3 if we do roll out the DRM as planned before v3 release. This was a technical pain due to the structural database differences between v2 and v3. I've prepared the v2 application for use with the download server as well.

Essentially, all the download server does is generate a one-time-use token that allows you to download an addon. It invalidates instantly as you request the page and you can't generate it without instantly using it.

IPN Application

The IPN (instant payment notification) application, is as the name suggests, a micro-service that handles the communication with payment gateways. Currently just PayPal.

This application's sole purpose is to validate and queue payments for processing on the main web app. In an ideal world we shouldn't have to do the processing on the web app at all, and let the IPN micro-service deal with it itself. However, this would require us to split our application into a wide array of micro-services which we are also trying to avoid. Micro-services should never share databases, and at the very least never share database tables.

Both our micro-services break this rule of thumb currently. The download micro-service will be able to operate without database access as soon as v3 has launched, but the IPN micro-service will not be able to work without access to the database or at the very least redis unless we were to abstract the entire application into a whole lot more micro-services as previously mentioned.

This means that if the main web app goes down, payments will not go through until it's up again, but they will however have been queued for processing already. As soon as the main web app is back up and running after an eventual downtime for whatever reason, all payments get instantly processed. This is a much needed improvement from v2 of the site because as you all know, if v2 goes down any payments that were made right before it happened may lose a race condition and be continously delayed by PayPal depending on how long the down-time is.

So what's actually remaining?

The list of what's remaining may be longer than this as things come up all the time.

1. The IPN micro-service is still not finished, it's gonna take a little bit longer to finish
2. Jobs are not entirely finished because they depend on the IPN micro-service (primarily the middle-man system)
3. Some statistics namely on a specific addon's dashboard are not finished
4. A bunch of lists (job list, applications list)
5. Popular addons
6. Moderator actions on the forums
7. Per subforum or forum category permissions
8. *Addon bundles/Addon bundle list
9. *Freelancers

*not required for release, and we could release without

And last but not least, we need to go through absolutely everything and check for bugs and various security vulnerabilities after the list above is done, we may bring in content developers to help us with this. More info right below.

Will there be a "beta" for content creators?

That depends on what you mean with beta, due to the technical differences between v2 and v3 there's no way to keep a "v3 beta" version up to date with the live website. It would simply be a testing ground for finding bugs, and not a live replication of the website.

In less technical speak, yes, but the database would not be the same as the live version of the website.

What happens when release is upon us?

When we are ready to deploy version 3.0 the website will be put in a read only mode while we convert the database into the new format and set up new servers. This entire process will likely take 6 hours. The read APIs will remain up while the migration is taking place to avoid disruption in any DRM you guys may be running.

Purchasing and any interaction with the website will be disabled during this time as we will only migrate the data one time.

After v3.0 is live, you should expect some bugs and we will have a dedicated area to report these.

As usual, keep replies and discussions civil.

If you want to keep up with development you may join our discord and keep an eye on the #commits channel.