tips-and-tricks.md

Tips and tricks

This part is dedicated to some code organisation within your application.

The examples are more focused on the Esmerald as the author is the same but again, you can do the same in your favourite framework.

Placing your connection in a centralised place

This is probably what you would like to do in your application since you don't want to declare over and over again the same variables.

The main reason for that is the fact that every time you declare a registry or a database, in fact you are generating a new object and this is not great if you need to access the models used with the main registry, right?

Place the connection details inside a global settings file

This is probably the easiest way to place the connection details and particulary for Esmerald since it comes with a simple and easy way of accesing the settings anywhere in the code.

Something simple like this:

{!> ../docs_src/tips/settings.py !}

As you can see, now you have the db_connection in one place and easy to access from anywhere in your code. In the case of Esmerald:

from esmerald.conf import settings

registry = settings.db_connection

But is this enough?. No.

As mentioned before, when assigning or creating a variable, python itself generates a new object with a different id which can differ from each time you need to import the settings into the needed places.

We won't talk about this pythonic tricks as there are plenty of documentation on the web and better suited for that same purpose.

How do we solve this issue? Enters lru_cache.

The LRU cache

LRU extends for least recently used.

A very common technique that aims to help caching certain pieces of functionality within your codebase and making sure you do not generate extra objects and this is exactly what we need.

Use the example above, let us now create a new file called utils.py where we will be applying the lru_cache technique for our db_connection.

{!> ../docs_src/tips/lru.py !}

This will make sure that from now on you will always use the same connection and registry within your appliction by importing the get_db_connection() anywhere is needed.

Note, you cannot do that if get_db_connection() is in the same file like the application entrypoint. Here you can use a edgy.monkay.instance sandwich instead.

You can also read further the Practical Example.

Excurse: The edgy.monkay.instance sandwich

If you want to short down the code and concentrate in e.g. main.py you can also use manual post loads and do the initialization in get_application this way:

1. Creating registry.
2. Assigning the Instance to edgy.instance via set_instance() but without app and skip extensions.
3. Post loading models.
4. Creating the main app.
5. Assigning the Instance to edgy.instance via set_instance() but with app.

this looks like:

{!> ../docs_src/tips/sandwich_main.py !}

{!> ../docs_src/tips/sandwich_models.py !}

The sandwich way has the disadvantage of having just one registry, while with the lru_cache way you can have many registries in parallel and mix them.

Practical example

Let us now assemble everything and generate an application that will have:

• User model
• Ready to generate migrations
• Starts the database connections

For this example we will have the following structure (we won't be use using all of the files). We won't be creating views as this is not the purpose of the example.

.
└── myproject
    ├── __init__.py
    ├── apps
    │   ├── __init__.py
    │   └── accounts
    │       ├── __init__.py
    │       ├── tests.py
    │       └── v1
    │           ├── __init__.py
    │           ├── schemas.py
    │           ├── urls.py
    │           └── views.py
    ├── configs
    │   ├── __init__.py
    │   ├── development
    │   │   ├── __init__.py
    │   │   └── settings.py
    │   ├── settings.py
    │   └── testing
    │       ├── __init__.py
    │       └── settings.py
    ├── main.py
    ├── serve.py
    ├── utils.py
    ├── tests
    │   ├── __init__.py
    │   └── test_app.py
    └── urls.py

This structure is generated by using the Esmerald directives

The settings

As mentioned before we will have a settings file with database connection properties assembled. We have also edgy_settings defined (any name is possible). It will be used for the central configuration management

{!> ../docs_src/tips/settings.py !}

The utils

Now we create the utils.py where we appy the LRU technique.

{!> ../docs_src/tips/lru.py !}

Note: here we cannot just import settings. We should wait until build_path is called.

The models

We can now start creating our models and making sure we keep them always in the same registry

{!> ../docs_src/tips/models.py !}

Here applied the inheritance to make it clean and more readable in case we want even more models.

As you could also notice, we are importing the get_db_connection() previously created. This is now what we will be using everywhere.

Prepare the application to allow migrations

Now it is time to tell the application that your models and migrations are managed by Edgy. More information on migrations where explains how to use it.

{!> ../docs_src/tips/migrations.py !}

This will make sure that your application migrations are now managed by Edgy.

Hook the connection

As a final step we now need to make sure we hook the connection in our application. We use an approach for the central management of configuration via esmerald. For this we provide a settings forwarder. You can also remove the settings forward and manage edgy settings via environment variable too.

{!> ../docs_src/tips/connection.py !}

And this is it.

Notes

The above example shows how you could take leverage of a centralised place to manage your connections and then use it across your application keeping your code always clean not redundant and beautiful.

This example is applied to any of your favourite frameworks and you can use as many and different techniques as the ones you see fit for your own purposes.

Edgy is framework agnostic.