Defining every Query in one file. Flask & SQLAlchemy.
Hey there! Welcome to my blog where I post about my journey as a self-taught developer. You can find my GitHub by clicking HERE.
As an application grows, sometimes it is difficult to determine where you should be putting your code. In this post I will share some ideas I have used lately to store my SQL queries in one location within my codebase. We will be importing functions, and using parameters to represent models.
Let’s check out an example file tree. Take a look below!
Alright, a straightforward file tree representing one blueprint in flask, and a queries directory containing three different python files. Each of which will contain queries based off their naming convention. The users.py file will house all of the queries related to the User Table in our models.py, so on and so forth.
Great! Now, how can we return a query from a function? Let’s make a query in our queries/users.py and import it into our blueprints/main.py! Code below.
Well done, we have now made a function called grab_user and passed in two parameters representing the model we want and the id of the model we want.
Now, in our blueprints/main.py file we can import this function and provide it with a specific name! Check it out below.
We import our query and provide it a name we can remember / recognize. Then the blueprint is created, and in the route itself you’ll notice <int:id>. This is Flasks’ way of passing parameters in different routes. In our case, it happens to be an integer (int). The function within the route has been assigned the name, get_user and we pass it the id from the url above!
Now…the magic happens here. The variable userQuery now becomes the return value of “data” from our original query that we had made. We can pass userQuery to a template and display that specific user.
userQuery = user(User, id)userQuery is a variable we can pass to a jinja html template.
user is the imported function that returns a value
User is the model we have imported above
id is the parameter in the url of our route!
userQuery just became the result of our query data! And now, your code is more modular.
Okay, maybe at this point you may start to see a benefit to separating our queries into individual files based off of models. Imagine if we had 100+ queries in our codebase, this way of modularizing our code suddenly becomes extremely helpful as we just need to make changes in one directory!
Although this example is small, and simple. The concept is powerful and it may benefit you and your team as well!
As always, I love learning and sharing my knowledge within the web development world. I hope this post helped someone and shed some light on a new strategy to help improve readability of your code.
Happy Coding!
