Home > Mobile >  Is there a performance deficit not splitting endpoints in Flask?
Is there a performance deficit not splitting endpoints in Flask?

Time:08-24

Just a question as to whether, for example, the following code would be faster in the second format rather than the first. Currently I am using the first example (with around 10 different options) and am wondering whether it would improve performance to split up the end point as in the second example.

First example:

from flask import Flask, request

app = Flask(__name__)

def function_one():
    return 1

def function_two():
    return 2

@app.route("/")
def home():
    if request.args.get("function_to_call") == "1":
        _ = function_one():
    elif request.args.get("function_to_call") == "2":
        _ = function_two()

Second Example

from flask import Flask, request

app = Flask(__name__)

def function_one():
    return 1

def function_two():
    return 2

@app.route("/one")
def one():
    _ = function_one()

@app.route("/two")
def two():
    _ = function_two()
    

CodePudding user response:

The second approach is definitely more legible, maintainable and scalable. If the two functions share some code procedures you could call the same function inside your endpoints.

Another thing i suggest you is to take a look at Flask blueprints to better structure your application into modules.

CodePudding user response:

Depends if your function_one/function_two go by fast or slow. Since you can configure if Flask will handle endpoints multithreaded or not, it would make sense to split the endpoints so that each thread can handle each function(s) for each endpoint.

Speaking purely from a standpoint "which code will execute faster regardless of threading and blocking operations", I don't think there would be a significant difference between either approach (unless you have thousands of endpoints in a single method...)

Speaking about readability and maintanance, the second approach is better.

  • Related