A video game modification that allows Minecraft players to make paintings in game, (including multiplayer drawing, and all related to that problems), which has an add-on that enables online features to submit player-made paintings through in-game interface to the backend.

Backend is NestJS mono repo made of 5 services duct taped together with AMQP broker, an API gateway that logs players in with Microsoft and customized oAuth API, gets validation and storing, queues paintings for processing (checks that there are no similars with LSH), and queues them for moderation (PEGI-like tag system).

Moderation is done by community managers with Discord bot, which is another backend service, and then finally another service combines those paintings into feeds using several algorithms (that quite popular in early social networks half-life algorithm with some seeded random and my attempts to math).

Final part is the NextJS front-end that has a wiki, shows paintings based on player preferences and allows player to get through authentication process when redirected from game.

Total it’s 4 repos, 3 open sourced (I don’t open backend source for several concerns)

Among Us inspired party drinking game. Every 5-10 minutes two random registered persons got an emergency call to run to the huge red button.

Button stands in front of ton of Bloody Mary shots (implementation varies). Folks have to drink together quickly, and press button with no more than 3 second delay.

If they fail, they have to repeat.

Magento ↔ Trello board integration. Allows sales managers to see order states from Magento website at glance with simplicity of Kanban board.

Integration works both ways, allowing to change order state from Trello board, adding order comments on behalf of Magento user, mark specific products for shipments and customize order state mapping.

When building .

Because ETag was not good or reliable enough.

Caches crc8 hash sums of static resources (styles and scripts) and adds those hashes to the file names of the resources like following

script.89acbd.js

Also contains rules for your reverse-proxy to ignore that hash sum to always deliver the latest files to the user, reliably bypassing browser cache.

This was needed when we did continuous deployment and had to update static resources on the fly without waiting for cache to expire.

Optionally cache could be disabled or enabled for specific resources, but generally we relied on Redis flush on deployment to re-build cache. That allowed us to have minimal overhead for the static content delivery, so there's no need to open static file location file handle for every resource until new deployment or manual cache flush.

To be described.