Sponsus was born from a conversation with my friend Leonard French about Patreon and what we could do to help those affected by the ongoing migration. Originally started in 2018, but revived in Jan 2019, Sponsus was my main platform to work on before ConstellationsDB. During the making of the platform, I learned a lot. So much that this story is going to be broken down into segments to better give context for the development, management, and maintenance processes.

Original 2018 build

The original 2018 UI & API were rough, however it featured all of the stable features I would eventually implement, including one-time donations, direct messaging, multi-media posts, pay-walled content. Built on-top of PayPal's payment system, it had a mediocre experience thanks to their really obtuse API, requiring a lot of complex steps from the creator to setup correctly. So I ended up scrapping it after a few months of work after figuring it not worth continuing the project. In the meantime, I had begun work on TVBot.

Version 2.0, the 2019 revival

One day while talking to an artist friend, the topic of Patreon once again came up. By the end, I had decided to try and revive the project. During the downtime, I had picked up Vue.JS from my time working on TVBot and QuartzBoard, allowing me to make this new version reactive and fast.

This was the first public showcase of Sponsus which shows the all new profile system and simplified experience. One of the biggest helping hands for making Sponsus easier to use was Stripe. They handle all of the information management and security, making it so we dont have to worry about compliance such as PCI DSS. All we need to do is point a payment towards a creator, and claim a fee. No sensitive information ever passes into the API meaning it doesnt need to be compliant to PCI DSS.

The all new API was built using Sanic, an AsyncIO powered Python HTTP framework. The big reason for using this was low-cost speed. By using faster event loops, it can process far more requests per second than traditional frameworks. Since threads require overhead for things such as memory, I went with this option as it allowed me to run the API for far less than a thread-based API would cost.

Personally, I think event loops are better than threads due to their ability to get around the GIL, preventing more than one thread from changing memory at once, since all the event loop is in a single thread. Obviously, they implement two different methods of async programming so ideally you should pick the best for the task. But if I had to choose, I would pick AsyncIO.

Realtime engine

One of the things that needed to be developed was a realtime engine to handle sending messages to each other without needing to reload the page. This would power the direct message page as well as the storefront's live update system so it was important to get the implementation right the first time. Originally, the API had been designed to follow a Pusher style, allowing me to reuse their JS client. However as development continued I realized it would be easier to make my own engine.

In the end, the engine functions in a pseudo-headless mode where it has no concept of users or accounts. How we authorize users is we give them a token that can be used to listen to a certain channel, the client would then pass this token to the engine and it would let them in. This design allows for a far more versatile usage than originally intended.