Almost three years ago I wrote an article on this blog titled Video Streaming with Flask, in which I presented a very modest streaming server that used a Flask generator view function to stream a Motion-JPEG stream to web browsers. My intention with that article was to show a simple, yet practical use of streaming responses, a not very well known feature in Flask.

That article is extremely popular, but not because it teaches how to implement streaming responses, but because a lot of people want to implement streaming video servers. Unfortunately, my focus when I wrote the article was not on creating a robust video server, so I frequently get questions and requests for advice from those who want to use the video server for a real application and quickly find its limitations. So today I'm going to revisit my streaming video server and describe a few improvements I've made to it.

While working on the second edition of my flask book, I was reviewing my Selenium tests, which allow me to automate a web browser and do end-to-end testing. In the current version of the book I recommend running these tests against Firefox. I thought this was a great opportunity to see how Headless Chrome works, as that eliminates the annoying browser window that pops out every time you run the tests.

The results are encouraging. This super short article describes what you need to do to set up Selenium to use the Headless Chrome browser.

Cookies are the most common attack vector for applications that run on web browsers, yet the topic of how to make cookies secure is frequently overlooked. I touched upon this topic in a few past articles, but today I want to specifically go over all the options Flask and extensions such as Flask-Login and Flask-WTF give you in terms of securing your application against web browser attacks.

Chances are, you were introduced to my blog through the Flask Mega-Tutorial, which is by far, the most popular topic on this blog. If you are doing the tutorial now, I'm sure you noticed that a number of things aren't quite as easy anymore. This is unfortunate, but several of the areas the tutorial touches on have seen significant changes since I published the articles.

The tutorial is now five years old, and embarking on a rewrite to bring it to Python 3.6 and current versions of all other technologies is going to require a considerable amount of time and effort. So I have decided to try a little experiment with a Kckstarter. If you haven't seen this yet, have a look at this video:

The way user sessions are handled in my Flask-SocketIO extension has always been a pain point for me. I tried to make sessions work almost the same as they work on regular Flask routes, but the "almost" part is what makes it confusing for most people.

In this short article and its companion video, I will try to explain why this is not trivial, and also will go over some improvements I just released that I hope will improve the use cases on which users seem to always trip.

In release 0.11, Flask introduced new command-line functionality based on Click, which includes the flask command. Before then, Flask did not provide any support for building command-line interfaces (CLIs), but Flask-Script provided similar functionality as a third party extension.

It's been more than a year since the Flask CLI has been released, and I still see a lot of projects out there based on Flask-Script. My guess is that there aren't really any important reasons that motivate people to migrate, since Flask-Script worked well, or at least well enough. But the reality is that Flask-Script hasn't had an official release since 2014 and appears to be unmaintained. In this article I want to show you how I migrated the Flasky application from my Flask book from Flask-Script to Click (one of the changes that are coming in the second edition of the book!), so that you can learn what the differences are, and decide if it is time to migrate your applications.

While you work on your Flask application, you normally run the development web server, which provides a basic, yet functional WSGI complaint HTTP server. But eventually you will want to deploy your application for production use, and at that time, one of the many things you will need to decide is if you should require clients to use encrypted connections for added security.

People ask me all the time about this, in particular how to expose a Flask server on HTTPS. In this article I'm going to present several options for adding encryption to a Flask application, going from an extremely simple one that you can implement in just five seconds, to a robust solution that should give you an A+ rating like my site gets from this exhaustive SSL analysis service.

In this short article I'm going to give you an overview of Visual Studio Code, a free and open source IDE for Windows, Mac OS X and Linux, from Microsoft. This IDE is highly configurable and extensible with plugins, including a very good one for Python.

Click on this and any of the following screenshots to see a larger image.

I'm currently in the process of adding asyncio support to my Socket.IO server. Being experienced in the eventlet and gevent way of doing async, this has been a very interesting project, and a great learning experience. At some point I reached a head scratching moment, when I tried to write some unit tests to exercise the new code I was writing, but found that the Python unittest and mock libraries do not offer any facilities specifically tailored to testing asyncio.

One of the aspects I'm most proud of regarding my Socket.IO server is how complete the unit test suite is, in spite of being a highly networked project that runs under multiple asynchronous and networking frameworks. Given the high complexity of this project, I considered it a requirement to properly test all this new asyncio code, so I spent some time thinking about ways to implement asyncio testing. In this article I want to share the solutions I came up with, which helped me reach 100% coverage of my asyncio code.

Highly distributed applications that consist of lots of small services talking among themselves are getting more and more popular, and that, in my opinion, is a good thing. But this architectural style brings with it a new class of problems that are less common in monolithic applications. Consider what happens when a service needs to send a request to another service, and this second service happens to be temporarily offline, or too busy to respond. If one little service goes offline at the wrong time, that can create a domino effect that can, potentially, take your entire application down.

In this article I'm going to show you techniques that can give your application some degree of tolerance for failures in dependent services. The basic concept is simple: we make the assumption that in most cases these failures are transient, so then when an operation fails, we just repeat it a few times, until it hopefully succeeds. Sounds easy, right? But as with most things, the devil is in the details, so keep reading if you want to learn how to implement a robust retry strategy.