Before we start digging into Flask, there's one question we should answer. What Python version should be used at this point with Flask, since it supports both?

We're now in 2017, and as we've seen in the previous chapter, Python 3 has made some incredible progress. Packages that don't support Python 3 are now less common. Unless you're building something very specific, you should not have any problem with Python 3.

And building microservices means each app will run in isolation, so it would be entirely imaginable to run some in Python 2 and some in Python 3 depending on your constraints. You can even using PyPy.

Despite the initial pushbacks the Flask creator had on some of the Python 3 language decisions, the documentation explicitly says at this point that new projects should start using Python 3; refer to http://flask.pocoo.org/docs/latest...

The framework entry point is the Flask class in the flask.app module. Running a Flask application means running one single instance of this class, which will take care of handling incoming Web Server Gateway Interface (WSGI) requests, dispatch them to the right code, and then return a response.

The class offers a route method, which can decorate your functions. When you decorate a function with it, it becomes a view, and it's registered into Werkzeug's routing system. That system uses a small rule engine to match views with incoming requests, and will be described later in this chapter.

Here's a very basic...

The previous section gave us a good understanding of how Flask processes a request, and that's good enough to get you started.

But Flask comes with more helpers, which are quite useful. We'll discover the following main ones in this section:

• The session object: Cookie-based data
• Globals: Storing data in the request context
• Signals: Sending and intercepting events
• Extensions and middlewares: Adding features
• Templates: Building text-based content
• Configuring: Grouping your running options in a config file
• Blueprints: Organizing your code in namespaces
• Error handling and debugging: Dealing with errors in your app

Like the request object, Flask creates a session object, which...

So far in this chapter, we've looked at how Flask works, and at most of the built-in features it provides--and we will be using them throughout this book.

One topic we have not covered yet is how to organize the code in your projects, and how to instantiate your Flask app. Every example so far used a single Python module and the app.run() call to run the service.

Having everything in a module is, of course, a terrible idea unless your code is just a few lines. And since we will want to release and deploy the code, it's better to have it inside a Python package so that we can use standard packaging tools like Pip and Setuptools.

It's also a good idea to organize views into blueprints, and have one module per blueprint.

Lastly, the run() call can be removed from the code, since Flask provides a generic runner that looks for an app variable...

This chapter gave us a pretty detailed overview of the Flask framework, and how it can be used to build microservices.

The main takeaways are as follows:

• Flask wraps a simple request-response mechanism around the WSGI protocol, which lets you write your applications in almost vanilla Python.

• Flask is easy to extend, and it works with Python 3.

• Flask comes with nice built-in features: blueprints, globals, signals, a template engine, error handlers, and a debugger.

• The microservice project is a Flask skeleton, which will be used to write microservices throughout this book. It's a simple app that uses an INI file for its configuration, and makes sure everything produced by the app is JSON.

The next chapter will focus on development methodology: how to continuously code, test, and, document your microservices.