devkat Progress Report: Webserver & Front-end

Since my last article about things going slightly wrong (PR 1900), things have already improved. First off, an immense thank you to everyone who decided to support us. It’s thanks to your support that we can keep working on what we love, in the way that we do things best.

To jump right into it, here are the first two major points we’re already working on:

  1. We’re replacing RocketMap’s Flask dev webserver (runs on Python).
  2. We’re building an entirely new modular front-end that will replace all current webpages with a much faster alternative.

1. We’re replacing RocketMap’s Flask dev webserver.

Flask is a development webserver that runs on Python – it’s not fast, it’s not particularly good either, and it’s even recommended to use only for development and never for production. Using it during RocketMap’s development was fine, as it was only used by developers, but ever since a community was built around RocketMap that has changed and it’s time to move forward to a proper webserver.

We’re replacing Flask with a fully asynchronous Node.js webserver on Express.js that uses Handlebars for templating (with enabled view caching), Sequelize for ORM, and that supports gzip compression and load limiting with toobusy-js.

In short, your webserver will support much more concurrent connections (Node.js’ asynchronous design is perfect for it), it will be able to scale up properly (and can easily be used with load balancing behind nginx) and the load limiter will automatically refuse requests when it notices the load on your server is too high, so instead of queuing up more requests waiting to be handled and further increasing the load, it will handle the requests it can handle and tell the rest to try again later.

Using nginx as a reverse proxy for Flask already helped support more users, but this new webserver will give you a codebase that can support concurrency on a much bigger scale. You no longer need to fiddle around to “get it to work”: it will now work properly by default and you can further scale up/optimize with other technologies such as nginx reverse proxy w/ caching.

2. We’re building an entirely new modular front-end (with additional JS abstraction layer) that will replace all webpages.

Yup, it’s happening.

Gone bootstrap, gone the finicky switches and nearly non-existent mobile support, gone the never-ending lag when too many Pokémon are on the map.

With a focus on responsive design, mobile support, minimal file size and performance, we’ve changed the old way of developing the front-end. With an entire new stack (Bourbon, Neat, npm and other modules), we’re writing responsive SCSS code to convert to minimal CSS (the file size is a fraction of what it used to be).

And what does the “modular” in the title mean? Well, we’ve built several optional customizable blocks into the front-end code, meaning you get a few blocks in which you can put your own HTML/CSS/JS code without having to edit our files. You can customize the front-end while still being able to update your codebase (git pull) without conflicts. For now, there is a customizable header title & icon, two customizable header content blocks (top left and top right corners of the screen), and optional customizable menu items.

This includes an additional abstraction layer in our JavaScript code to make it easier to control/manage the map and its markers from code outside of the repository’s code.

Besides the entire UI rework, it also includes a rewrite from scratch of all front-end JavaScript code with a focus on performance. Something that used to be very lacking has now become the main focus. The most important steps involve stepping away from slow libraries (e.g. jQuery) and using native JS, and rewriting the Google Maps markers to be rendered via WebGL.

If you’re not sure what this all means, just know that it’ll support millions of active markers without lagging; you’ll be able to zoom out to see the world map without having to hide Pokémon markers. Even on mobile.

(While right now it can’t even support a few tens of thousands without lagging on a desktop…)

303: It's Compiling

source: https://xkcd.com/303/

And as usual, there’s more coming.

The two points we’re working on are already massive changes compared to what has been changed in RocketMap’s history, and we’re going to need a fair bit of time to complete it, but these are the first steps towards an immensely more stable and more efficient RocketMap.

We have much more on our list of to-dos, some of which are smaller ones that we’ll work on during development of the above two points (e.g. the auto-verification mailserver we’ve recently released for all of our Patrons), and we’ll continue to keep you updated.

Remember that you can find us on our Discord, and that we’d love to hear your thoughts on these changes. ♥

 

…to boldly go where no man has gone before.

Leave a Reply

Your email address will not be published. Required fields are marked *