Deployment: The Next Big Batch of Knowledge After Flask

Deployment: The Next Big Batch of Knowledge After Flask

I’ve begun thinking about how to deploy my app. It would have been easy as a one-pager, but my app has a PostgreSQL database, and it is a social networking site, which means I should prepare for lots and lots of users (assuming people pick it up at all).

Rooting around in this direction turned up this helpful video that tells you about different ways to host your app. It also turned up the idea of “workers”. Heroku and DigitalOcean use workers. What are these? I don’t know yet. Of course there are definitions, as usual. But definitions try to be one-stop shops and catch-all solutions, and in catering to everyone, they cater to no one at all. Ok, I exaggerate. They cater to some. Dictionaries do a pretty decent job although they don’t tell you about nuances, connotations, and other baggage that comes with words.

While researching workers and deployment, I realised that I have to look at sharding, and possibly logical sharding in particular. Also connection pools, database caching, clustering, cloud formation, load balancing, docker/virtualisation, and batching writes to the database. In short, it seems, I have to learn some devops.

We meet again, prong of epistemology. To go from Flask to deployment means learning a whole critical bunch of things.

The bad thing is, I don’t know how much I should know about devops, so I’m groping around in the dark, and groping around for all kinds of different things. To mix two idioms, I’m a drowning man in the dark clutching at straws. The good thing, I suppose, is that I think I know the primary question here: how many requests can a worker handle? It’s a surprisingly hard question to answer, and I have to answer it so I know if the cheapest plan on DigitalOcean is suitable for a starting social networking web app. I’ll root around some more.

Deployment also made me think about marketing, which led me to this video, which reminded me that I have to cite open source code, which means I have to review all my code and try to remember where each part of it came from if I didn’t write it myself.

At the same time, I’ve learnt and exercised enough Flask to know that I should pick up Django and rebuild the entire app in it, and that I should also learn JavaScript, because a lot of interactions, like socketio, depends on it.

Does the prong of epistemology become larger and larger as knowledge increments? At this point, I should be working in a team with proper front end and back end developers and designers, right? But with only basic Python, Flask, and SQL under my belt, what team roughing it out in the savage wilderness of live business operations would want me? “Not good enough”, that old refrain.

But, hey, the only way forward is forward.