Forums

Using Flask and have some API endpoints that return JSON. I believe my Flask app is "monolithic". This is convenient since Flask has the session "global" variable to pass along session info. However, to make this architecture microservices-oriented, I'd need to run as many apps as I have microservices, right? Then find some other way to maintain the session info? This seems highly inconvenient unless I have a very specific microservice to run as another app for some very specific reason. Does that sound correct? Thanks for any advice.

The normal split for microservices, at least as I understand them, is that only one would be public-facing (and thus need sessions) while others would provide back-end services that aren't session-aware.

For example, almost all of the PythonAnywhere site that you see is one Django website. (The exception is the in-browser consoles, which I'll ignore for this example.) However, we have a fairly large number of microservices that provide certain kinds of back-end functionality. If your disk quota changes (say, if you've upgraded or downgraded your account) then the file server associated with your account needs to be notified so that it can apply the new quota at the OS level. So the code that has changed the quota looks up which file server it needs to talk to, then connects to a Flask app that's running on that server (over HTTPS, using authentication) and hits an "update quota" endpoint passing in the user ID and the new quota, and the file server does its thing. The access to the microservice is stateless, so no session is needed.

Ah, thanks, Giles. That makes sense. I'm thinking I need a "monolithic" app (see my reply about Jinja2 templates) so that Flask/Angular are more seamless, especially with regard to session info. However, some isolated microservices (as needed) makes a lot of sense. Much easier to develop and test some isolated bit without affecting the main app. In theory, that should be better overall, but in practice it's not so appealing for convenience reasons, I believe. I am thinking I'll only do this for certain portions.

Yes, that sounds like the right direction -- start off monolithic and then separate things out if and when you want/need to. In general, we've found that it's pretty much impossible to work out exactly how you'll want to separate your code out into different services until it's been up and running in the real world for a while.

The very first version of PythonAnywhere (quite a long time ago) was just one Django server and one Tornado server running on one machine. As time went by and we discovered (by careful monitoring) what exactly needed to be changed in order to scale up, we split it up.

Thanks a lot Giles. This makes sense to me. I don't see a need to transfer state (REST) on every API call because I don't plan for millions of users type of scale (would tackle that later, anyway). For what I'm thinking, Flask session dictionary is perfect for the moment.