when i was learning code one of my teachers, who obviously used to be an English teacher, would always asked "wherefore X"?
that is, not only do you need to know HOW to use a technology, but you need to know WHY you should use it, in what cases, and when you should probably stop using it
i wish that more tech articles included this because, frankly, i don't know how you even get off the ground if you don't know why you're using a particular technology
this question brought to you by my deep confusion about Python servers. wherefore Flask? wherefore Nginx? damned if i know either
@melissasage also i can give my intuition about flask! it's for small servers, hobbyist servers, and things where you wanna throw something together quickly, imo
@melissasage Would you like me to take a run at those particular questions here?
@Nentuaby yes go for it
@melissasage Ok, so.
Flask-- It's the simplest framework for turning Python code into answering web requests, without doing a lot of repetitive stuff that just implements the shared guts of all web servers.
Best if: you have a medium-to-heavy weight app you want to implement, particularly one that isn't organized like a typical web site.
Maybe don't use it if: your site is very small and doesn't need much customization OR very large and needs much organisational support
@melissasage (the first implies you'd do better with the other major Python web framework, Django. The second also implies Django, but with a different set of plugins)
@melissasage NGinx is primarily a web proxy, a server that handles all the messy business of talking to the public internet and relays it all to the servers doing the real work. Not strictly anything to do with Python, it shows up in front of virtually all web apps these days.
It serves a few purposes:
* Hardening-- makes sure that any code you wrote will only handle web requests from a server you trust (their content can still be evil, of course, but it still cuts many attacks)
* SSL termination-- takes care of the hard work of encryption so your app servers don't have to, relays requests by HTTP once safely inside your network
* Implementation detail hiding-- provides a regularized face of your site you can switch out app servers/ have multiple app servers behind
@melissasage i quite like this
@melissasage YES. this is why runyourown.social is a guide primarily focused on "why" and even has a "why NOT to run a small social network site" section
@melissasage I think the technical term for this is cargo cult programming.
@melissasage I love this! I've been using a similar philosophy in my lessons. Often when I'm teaching a new thing (e.g. servers with Express.js), I try to construct a list of motivations and build up some imaginary code to come to a solution _before_ we even take a look at the actual real code.
A cool and chill place for cool and chill people.