That’s how many people use ad-blockers or privacy-focused browsers. And if you’re using privacy-first analytics like Fathom, these tools still block the official tracking script from cdn.usefathom.com—even though you’re not collecting personally identifiable data.

I ran into this exact problem. My analytics dashboard showed decent traffic, but I knew the real numbers were higher. Ad-blockers were killing Fathom’s script before it could fire. Every blocked request meant lost data about site visits and how people actually use my site.

Here’s how I fixed it using Bunny.net’s CDN as a reverse proxy. The solution bypasses blockers completely, costs about $1/month (even for multiple sites), and takes about 10 minutes to set up.

The Problem: Domain-Based Blocking Kills Analytics

Ad-blockers work by maintaining lists of blocked domains. When your browser tries to load a script from cdn.usefathom.com, the blocker checks its list, finds a match, and blocks the request.

It doesn’t matter that Fathom is privacy-first or GDPR-compliant. The blocker sees “analytics domain” and kills it.

This affects more than just Fathom. Plausible, Umami, and any third-party analytics service face the same issue. Even if you’re doing everything right from a privacy perspective, your scripts get caught in the same net as invasive trackers.

The result? Your analytics dashboard becomes less useful. You can’t make informed decisions about content, UX improvements, or conversion optimization when you’re missing data from 42% of your visitors.

What Didn’t Work: DNS URL Forwarding

My first attempt seemed logical: use URL forwarding at my DNS registrar to point ana.mydomain.com to cdn.usefathom.com.

The idea was simple. If I could serve the script from my own domain, ad-blockers wouldn’t recognize it as a tracking script. First-party requests from your own domain don’t appear on blocklists.

I tried this with my DNS provider at the time (freedns.si). It didn’t work.

Here’s why URL forwarding failed for me:

URL forwarding only worked with root URLs. When I requested ana.mydomain.com/script.js, the path got forwarded—but the slash disappeared. The request ended up going to cdn.usefathom.comscript.js (notice the missing slash between the domain and filename).

There was no way to configure it as cdn.usefathom.com/{path} or anything similar. At least not with freedns.si. I don’t know if this is a limitation across all DNS providers, but it was a dealbreaker for me.

DNS forwarding simply doesn’t handle URL paths properly. I needed something smarter.

The Solution: Reverse Proxy Through Bunny.net CDN

The fix is to use a CDN as a reverse proxy. When someone requests ana.mydomain.com/script.js, the CDN fetches the file from cdn.usefathom.com/script.js and serves it under your domain.

This is proper proxying, not just URL forwarding. The full URL path is preserved correctly, and browsers only see your first-party domain.

I use Bunny.net for this. It’s a CDN provider with simple configuration at low cost.

Here’s what makes this work:

Bunny.net creates a “Pull Zone”—a CDN endpoint that fetches content from an origin server. You point the Pull Zone at cdn.usefathom.com, configure a custom hostname like ana.mydomain.com, and the CDN handles the rest.

When a visitor loads your page:

1. Their browser requests https://ana.mydomain.com/script.js
2. Bunny’s CDN receives the request
3. The CDN fetches the script from https://cdn.usefathom.com/script.js
4. The CDN serves it to the visitor under your domain
5. Ad-blockers see a first-party request and allow it

The visitor’s browser never directly contacts cdn.usefathom.com. All communication goes through your domain.

Step-by-Step Setup

Want to skip the manual setup? Jump to Automating the Entire Setup for a programmatic approach.

1. Create a Bunny.net Pull Zone

Sign up for Bunny.net (they have a 14-day free trial). Navigate to the Pull Zones section and create a new zone. Give it a descriptive name like ana-mydomain—this name determines your Bunny CDN hostname (ana-mydomain.b-cdn.net), which you’ll need in step 3.

Key settings:

• Origin URL: https://cdn.usefathom.com
• Origin Host Header: cdn.usefathom.com

That second setting is important. Bunny marks it as optional, and technically if you leave it blank, Bunny extracts the hostname from the Origin URL automatically.

Here’s why it matters: When Bunny fetches content from the origin server, it needs to send the right Host header in the HTTP request. If this is wrong or missing, Fathom’s servers might not respond correctly. Setting the Origin Host Header ensures Bunny sends Host: cdn.usefathom.com when fetching the script.

You don’t need special caching rules or edge rules. Default Pull Zone settings work fine.

2. Add a Custom Hostname

In your Pull Zone settings, add a custom hostname. This is the subdomain you’ll use—something like ana.mydomain.com or cdn.mydomain.com.

Choose something that makes sense for your setup. The subdomain name can be anything you want.

3. Configure DNS

Add a CNAME record in your DNS settings:

1
2
3

Type: CNAME
Name: ana
Value: ana-mydomain.b-cdn.net

The value follows the pattern <pull-zone-name>.b-cdn.net, where ana-mydomain is the name you gave your Pull Zone in step 1. You’ll also find this hostname in the Pull Zone settings after adding your custom hostname.

The subdomain name (ana) can be whatever you chose in the previous step—cdn, track, etc.

4. Enable SSL

Bunny automatically provisions a free Let’s Encrypt certificate once you add the custom hostname. This usually takes a few minutes to activate.

Check the SSL status in your Pull Zone settings. Once it shows “Active,” you’re good to go.

I recommend enabling “Force SSL” to redirect all HTTP requests to HTTPS. This is just good practice for any modern website.

5. Update Your Script Tag

Replace your existing Fathom script tag:

1
2

<!-- Old: blocked by ad-blockers -->
<script src="https://cdn.usefathom.com/script.js" data-site="YOUR-SITE-ID"></script>

With your proxied version:

1
2

<!-- New: served from your domain -->
<script src="https://ana.mydomain.com/script.js" data-site="YOUR-SITE-ID"></script>

That’s it. No changes needed in your Fathom dashboard. The data-site attribute still identifies your site. Fathom doesn’t care where the script loads from—the tracking calls use relative paths, so they go through the same proxy automatically.

Why This Works

Ad-blockers maintain blocklists of known tracking domains. These lists include cdn.usefathom.com, along with many other domains associated with analytics, advertising, and tracking.

When you serve the script from ana.mydomain.com, the blocker checks its list and finds nothing. Your domain isn’t on any blocklist. The request goes through.

This isn’t about sneaking past privacy protections. Fathom is still privacy-first analytics that doesn’t collect personal data. You’re just ensuring that your own first-party analytics actually work.

It’s the same principle as self-hosting the script on your own server—but using a CDN gives you better performance and easier updates.

Automating the Entire Setup

Clicking through Bunny.net’s dashboard to set up Pull Zones, DNS records, custom hostnames, and SSL certificates gets old fast when you’re managing multiple sites. I needed a better way.

I ended up building a tool that handles this entire process programmatically: bunny-dns-sync.

It’s an open-source Python tool that lets you define your Bunny.net DNS zones, Pull Zones, custom hostnames, and Edge Rules in a JSON configuration file. Use it from the command line or import it as a library in your own scripts. The tool syncs your desired state to Bunny’s API automatically — creating, updating, or deleting resources as needed.

Here’s what a config file looks like:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

{
    "domains": {
        "mydomain.com": {
            "dns_records": [
                {"type": "CNAME", "name": "ana", "value": "ana-mydomain.b-cdn.net", "ttl": 3600}
            ],
            "pull_zones": {
                "ana-mydomain": {
                    "origin_url": "https://cdn.usefathom.com",
                    "origin_host_header": "cdn.usefathom.com",
                    "type": "standard",
                    "enabled_regions": ["EU", "US"],
                    "hostnames": ["ana.mydomain.com"],
                    "edge_rules": []
                }
            }
        }
    }
}

Run the sync command, and it creates everything: DNS zones, Pull Zones, custom hostnames, and free SSL certificates. No manual clicking. Everything is version-controlled and reproducible.

This is completely optional — the manual setup works fine if you only have one or two sites. But if you’re managing infrastructure as code or running multiple sites, the tool saves a lot of time and prevents configuration drift.

Check out the https://github.com/mrpesho/bunny-dns-sync for installation instructions and full documentation.

Results and Performance

This approach bypasses all domain-based blockers:

• uBlock Origin
• AdGuard
• Pi-hole
• NextDNS
• Any blocker using EasyList or similar lists

Performance should be the same or slightly better than loading directly from Fathom’s CDN. Bunny.net has edge nodes globally, so the script loads from whichever server is closest to your visitor.

For a ~2KB gzipped script, latency differences are negligible. I haven’t noticed any performance degradation, and my analytics data is now complete.

What About Costs?

Bunny.net charges by bandwidth. For an analytics script that’s about 2KB gzipped, the cost is extremely low.

A site with 50,000 page views per month uses roughly 100MB of bandwidth for the script. At Bunny’s pricing, that’s well under $0.01/month for the actual bandwidth.

Bunny does have a minimum charge of $1/month if you use their services. But here’s the thing: this minimum is hard to reach even if you have multiple sites running analytics through Bunny. The bandwidth usage is just too low.

This pairs well with Fathom, which allows up to 50 sites per account. You can proxy analytics for all your sites through Bunny and still barely touch that $1/month minimum.

Could This Work for Other Analytics Tools?

I’ve only tested this setup with Fathom and Bunny.net, so I can confirm it works reliably for this combination.

The principle should work for other privacy-focused analytics tools like Plausible or Umami—they face the same ad-blocker issues and use similar script-based tracking. The setup would be identical: point the Pull Zone at their CDN, configure your custom hostname, update your script tag.

The Key Takeaway

Ad-blockers block by domain, not by functionality. Serving Fathom Analytics script from your own domain bypasses blocklists while preserving visitor privacy.

Using a CDN as a reverse proxy is cleaner than self-hosting (the script automatically updates when Fathom releases new versions) and more reliable than DNS-level URL forwarding (which didn’t handle URL paths correctly with my DNS provider). The proxy routes both the script file and all tracking API calls through your domain, so ad-blockers never see requests to cdn.usefathom.com.

The setup takes about 10 minutes. The cost is about $1/month even with multiple sites. And you get complete analytics data from all your visitors—not just the 58% who don’t use blockers.

If you’re losing analytics data to ad-blockers, try this approach. Your dashboards will thank you.

Disclaimers

Privacy and Ethical Use: This technique is for privacy-respecting, first-party analytics (like Fathom, which is cookieless and doesn’t collect personal data). Users have the right to control their browsing experience—bypassing ad-blockers doesn’t exempt you from privacy laws or consent requirements where applicable. Be transparent: disclose analytics usage in your privacy policy and consider adding a footer notice explaining what data you collect and why.

Affiliate Links: This post contains affiliate links to Fathom Analytics and Bunny.net. If you sign up through these links, I may receive a commission at no additional cost to you.

Legal Disclaimer: I’m not a lawyer, and this article does not constitute legal advice. This describes a technical solution I use on my own sites. Consult your own legal counsel about compliance with privacy regulations (GDPR, CCPA, etc.) applicable in your jurisdiction.

I hit this wall while backtesting forex indicators. I was testing different parameter combinations for indicators like MACD — things like fast EMA period, slow EMA period, and signal line length. Each parameter had a range of possible values, and I needed to test every valid combination.

The problem? Most combinations were invalid. MACD requires signalLine < fastEMA < slowEMA. But Python’s itertools.product doesn’t care about that. It generates every combination, including the ones that make no mathematical sense. I was wasting time and memory on millions of combinations I’d immediately throw away.

Here’s how I fixed it: a Python generator that filters invalid combinations before they pile up in memory, and processes the valid ones in small batches. The result? Fewer combinations, less memory, and backtests that actually finish.

The Cartesian Product Problem

When you test indicator parameters, you define ranges for each one. For MACD, that might look like:

• Fast EMA: 3 to 21
• Slow EMA: 10 to 34
• Signal Line: 1 to 16

To find the best settings, you need to test every valid combination. Python’s itertools.product gives you the cartesian product — every possible pairing across all ranges.

Here’s the basic approach using zip(*product(...)):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

import numpy as np
from itertools import product

range_1 = np.arange(1, 5, step=1, dtype=int)
range_2 = np.arange(1, 5, step=1, dtype=int)

combo_1, combo_2 = zip(*product(range_1, range_2))

print("combo_1:", combo_1)
print("combo_2:", combo_2)

The product() function produces the cartesian product — every possible pair from the two ranges. Then zip() regroups those pairs into separate tuples, one per parameter. The output:

1
2

combo_1: (1, 1, 1, 1, 2, 2, 2, 2, 3, 3, 3, 3, 4, 4, 4, 4)
combo_2: (1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4, 1, 2, 3, 4)

Each column is a unique combination. Four values in each range gives 16 combinations. That’s fine.

But what happens with real-world parameter ranges?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

import numpy as np

range_1 = np.arange(1, 50, step=1, dtype=int)    # 49 values
range_2 = np.arange(1, 50, step=1, dtype=int)    # 49 values
range_3 = np.arange(2, 30, step=1, dtype=int)    # 28 values
range_4 = np.arange(0.1, 30, step=0.1)           # 299 values
range_5 = np.arange(0.1, 30, step=0.1)           # 299 values

# This creates 5 lists, each with 56,538,748 elements
combo_1, combo_2, combo_3, combo_4, combo_5 = zip(*product(
    range_1, range_2, range_3, range_4, range_5
))

Over 56 million elements — per list. Your machine will choke on memory before the backtest even begins. And that’s regardless of which backtesting library you use. The bottleneck isn’t the library. It’s the sheer number of combinations.

Step 1: Process Combinations in Batches

Both product() and zip() are iterators. They generate values one at a time, on demand. The memory problem happens because zip(*product(...)) forces everything into memory at once.

The fix is a generator that collects combinations into small batches and yields them one group at a time:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

from itertools import product

def zip_product_in_batches(*iterables, size=1000):
    """
    Yields batches of zip(*product(...)) results,
    'size' combinations at a time.
    """
    if type(size) != int or size < 1:
        raise ValueError(
            f"'size' must be a positive integer. Got: {size}"
        )
    batch = []
    for elements in product(*iterables):
        batch.append(elements)
        if len(batch) >= size:
            yield zip(*batch)
            batch = []

    # Don't forget the last (possibly smaller) batch
    if batch:
        yield zip(*batch)

Instead of materializing all 56 million combinations, you process them 1,000 at a time (or whatever batch size fits your machine). Here it is in action:

1
2
3
4
5
6
7
8
9

import numpy as np

range_1 = np.arange(1, 5, step=1, dtype=int)
range_2 = np.arange(1, 5, step=1, dtype=int)

for combo_1, combo_2 in zip_product_in_batches(range_1, range_2, size=5):
    print("combo_1:", combo_1)
    print("combo_2:", combo_2)
    print("=" * 30)

Output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

combo_1: (1, 1, 1, 1, 2)
combo_2: (1, 2, 3, 4, 1)
==============================
combo_1: (2, 2, 2, 3, 3)
combo_2: (2, 3, 4, 1, 2)
==============================
combo_1: (3, 3, 4, 4, 4)
combo_2: (3, 4, 1, 2, 3)
==============================
combo_1: (4,)
combo_2: (4,)
==============================

Same 16 combinations, but now they arrive in groups of 5. You process each batch, save the results, and move on. Memory stays flat no matter how many total combinations exist.

This alone makes it possible to run massive parameter sweeps on a regular laptop. But we can do much better.

Step 2: Filter Out Invalid Combinations

Batching solves the memory problem. But you’re still iterating over every single combination — including the invalid ones. For MACD, where signalLine < fastEMA < slowEMA must hold, most combinations from a broad parameter sweep are useless.

Take three ranges of 1–9 (like the signal line, fast EMA, and slow EMA). That’s 9 × 9 × 9 = 729 total combinations. But how many actually satisfy the ascending order constraint? Only 84. That means 88% of the work is wasted on combinations you’ll never use.

The solution: filter inside the generator, before combinations ever reach the batch.

There are two ways to do this, and which one you pick depends on your filtering rule.

When the Same Operator Applies to Every Pair

If every adjacent pair follows the same rule — like strict ascending order (el_1 < el_2 < el_3 < ...) — you can generalize it. Python’s built-in all() function checks whether every item in an iterable is true. That lets you apply one operator across any number of elements, so the function works with two or more parameter lists:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

from itertools import product

def filtered_zip_product_in_batches(*iterables, size=1000):
    """
    Yields batched zip(*product(...)) results, keeping only
    combinations where each element is strictly less than the next.
    Works with two or more iterables.
    """
    if type(size) != int or size < 1:
        raise ValueError(
            f"'size' must be a positive integer. Got: {size}"
        )
    batch = []
    num_iterables = len(iterables)
    for elements in product(*iterables):
        # Check: elements[0] < elements[1] < elements[2] < ...
        if all(elements[i] < elements[i+1] for i in range(num_iterables - 1)):
            batch.append(elements)
            if len(batch) >= size:
                yield zip(*batch)
                batch = []

    if batch:
        yield zip(*batch)

The key line is the all() check. It walks through the elements pairwise: is the first less than the second? Is the second less than the third? And so on. Only if every pair passes does the combination make it into the batch.

This works great when the same operator applies everywhere. But what if it doesn’t?

When Operators Differ Between Pairs

Sometimes the relationship between parameters isn’t the same across the board. Maybe the first must be strictly less than the second, but the second can be less than or equal to the third — like el_1 < el_2 <= el_3. You can’t express mixed operators in a single all() call, so spell out the parameters explicitly and write the condition by hand:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

from itertools import product

def filtered_zip_product_fixed(list_1, list_2, list_3, size=1000):
    """
    Batched zip-product for exactly 3 lists,
    keeping only combinations where list_1 < list_2 <= list_3.
    """
    batch = []
    for el_1, el_2, el_3 in product(list_1, list_2, list_3):
        # Skip invalid combinations immediately
        if not (el_1 < el_2 <= el_3):
            continue
        batch.append([el_1, el_2, el_3])
        if len(batch) >= size:
            yield zip(*batch)
            batch = []

    if batch:
        yield zip(*batch)

This gives you full control over each comparison. The downside is that the function is locked to a fixed number of parameter lists.

Seeing It in Action

Let’s test with three ranges of 1–9 and a batch size of 10:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

import numpy as np

range_1 = np.arange(1, 10, step=1, dtype=int)
range_2 = np.arange(1, 10, step=1, dtype=int)
range_3 = np.arange(1, 10, step=1, dtype=int)

for list_1, list_2, list_3 in filtered_zip_product_in_batches(
    range_1, range_2, range_3, size=10
):
    print("list_1:", list_1)
    print("list_2:", list_2)
    print("list_3:", list_3)
    print("=" * 25)

The first two batches look like this:

1
2
3
4
5
6
7
8

list_1: (1, 1, 1, 1, 1, 1, 1, 1, 1, 1)
list_2: (2, 2, 2, 2, 2, 2, 2, 3, 3, 3)
list_3: (3, 4, 5, 6, 7, 8, 9, 4, 5, 6)
=========================
list_1: (1, 1, 1, 1, 1, 1, 1, 1, 1, 1)
list_2: (3, 3, 3, 4, 4, 4, 4, 4, 5, 5)
list_3: (7, 8, 9, 5, 6, 7, 8, 9, 6, 7)
=========================

Every single combination satisfies list_1 < list_2 < list_3. No wasted rows.

The unfiltered zip_product_in_batches() would have yielded all 729 combinations. The filtered version yields just 84. That’s 88.5% fewer combinations — fewer iterations, less compute time, less memory.

For a MACD backtest with realistic parameter ranges, the savings are even more dramatic. Instead of burning hours on combinations where the fast EMA is larger than the slow EMA (which makes no sense), you skip them entirely.

Adapting the Filter for Your Use Case

The ascending-order filter (a < b < c) maps directly to MACD’s constraint where signalLine < fastEMA < slowEMA. But you can swap in any filtering logic.

For example, if you need a minimum gap between parameters:

1
2

# Keep only combinations where each value is at least 3 apart
if all(elements[i+1] - elements[i] >= 3 for i in range(num_iterables - 1)):

Or if you have a completely custom rule — say, the third parameter must be less than half the second:

1

if elements[2] < elements[1] / 2:

The pattern stays the same. Define your validity rule, check it before appending to the batch, and let the generator handle the rest.

Wrapping Up

Two small changes to how you generate parameter combinations can save you massive amounts of time and memory:

1. Batch the output so you never hold all combinations in memory at once.
2. Filter inside the generator so invalid combinations never reach your backtest.

For my forex indicator backtests, this turned an impossible parameter sweep into something I could run on a normal machine. The 729-to-84 reduction in the example above is modest — with real parameter ranges across multiple indicators, the invalid combinations easily outnumber the valid ones by 10:1 or more. How much you save will depend on your specific input ranges and filtering rules. Narrower ranges with strict constraints will cut more; wider ranges with loose rules will cut less.

The code is pure Python with no dependencies beyond itertools. Copy the filtered_zip_product_in_batches function, plug in your own filtering rule, and you’re set.

Disclaimer: This article is for educational and informational purposes only. It does not constitute financial, investment, or trading advice. The examples involving forex indicators are used purely to illustrate a programming technique. Any trading or investment decisions you make are solely your own responsibility. Always do your own research and consult a qualified financial advisor before making trading decisions.

• rx.desktop_only()
• rx.tablet_only()
• rx.mobile_only()
• rx.mobile_and_tablet()
• rx.tablet_and_desktop()

Example:

1
2
3
4
5
6
7
8

# Tested with Reflex 0.8.5

import reflex as rx

# Works as expected: renders only on mobile & tablet widths
rx.mobile_and_tablet(
    rx.text("Shows on mobile and tablet, but not on desktop"),
)

These wrappers toggle visibility with CSS (display: none vs block) but children still mount.

rx.toast() is not a renderable component

This fails:

1
2
3
4
5
6

import reflex as rx

# ❌ Fails at compile time
rx.mobile_and_tablet(
    rx.toast("Shows on mobile and tablet, but not on desktop")
)

The reason is that rx.toast() is an event action (an EventSpec), not a renderable component. Passing it as a child triggers a ChildrenTypeError:

1
2
3

Component Box received child EventSpec(...) ...
Accepted types are components, state vars, or
primitive Python types.

Even if you tried to call a toast in on_mount inside a responsive wrapper:

1
2
3
4
5
6
7
8

import reflex as rx

# ❌ Show on all screen sizes
rx.mobile_and_tablet(
    rx.el.div(
        on_mount=rx.toast("Shows on mobile and tablet, but not on desktop")
    )
)

it would still show on all sizes because the child mounts regardless of visibility (the wrapper hides via CSS only).

Solution: call_script → State callback

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

import reflex as rx

class UiEvents(rx.State):
    @rx.event
    def toast_if_small(self, is_small: bool):
        if is_small:
            return rx.toast(
                "Shows on mobile and tablet, but not on desktop",
                duration=5000,
            )

rx.page(route="/")
def index():
    return rx.el.div(
        on_mount=rx.call_script(
            # Use matchMedia; it aligns better with CSS breakpoints than outerWidth 
            f'window.matchMedia("(max-width: 1024px)").matches',
            callback=UiEvents.toast_if_small,
        ),
    )

How it works

1. On mount, the client runs the JS code (window.matchMedia('(max-width: 1024px)').matches) which results in true if width is 1024px or less, otherwise false.
2. The boolean result is passed to UiEvents.toast_if_small.
3. The event function returns rx.toast(...) if the condition is met.

You may see two toasts in development

Reflex uses React on the client. In dev mode, React’s Strict Mode—enabled by Next.js during development—intentionally double-invokes mounts and effects, so you may see two toasts. Run reflex run --env prod to confirm the single-mount behavior in production.

Originally you have 2 options:

Set ENV_FILE in terminal

You can set ENV_FILE as a prefix to the command in the terminal:

1
2
3
4
5
6

# run command with env mode 'dev'
$ ENV_FILE=./.env.dev reflex run

# run command with env mode 'prod'
$ ENV_FILE=./.env.prod reflex run --env prod  # run it locally, or
$ ENV_FILE=./.env.prod reflex deploy  # deploy it to the cloud

Set env_file in the rxconfig.py

1
2
3
4
5
6
7

# rxconfig.py
import reflex as rx

config = rx.Config(
    env_file=".env.prod",  # or env_file=".env.dev"
    ...
)

In this case you will have to change the value of env_file yourself, before you run it in different env mode.

Bonus: Set env_file in the rxconfig.py programmatically

With a few lines of code, you can also make it switch automatically, based on the env mode.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22

import os
from reflex import constants
import reflex as rx

def get_value_based_on_env_mode(prod=None, dev=None):
    # Note that REFLEX_ENV_MODE variable is only set
    # with 'reflex run', but not with 'reflex deploy'.
    env_mode = os.environ.get(
        "REFLEX_ENV_MODE",
        constants.Env.PROD
    )
    is_dev_mode = env_mode == constants.Env.DEV

    return dev if is_dev_mode else prod

config = rx.Config(
    env_file=get_value_based_on_env_mode(
        prod=".env.prod",
        dev=".env.dev"
    ),
    ...
)

This function I often define in the ipython console, to symplify my work:

1
2
3
4

def ddir(modul, word=''):
    for d in dir(modul):
        if word.lower() in d.lower():
            print(d)

I name it simply ddir() with a double d.

The dir() function used in the 2nd row is a built-in Python function that takes our modul as parameter and returns the list of properties and functions as strings.

We can call our ddir() as

1
2
3

my_string = 'Hey!'

ddir(my_string)

and it will list all of the properties and functions of a string.

The way this function becomes useful to me is when I define the 2nd parameter as well:

1
2
3

my_string = 'Hey!'

ddir(my_string, 'is')

which, in this case, will list only properties and functions that include string ‘is’:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12

isalnum
isalpha
isascii
isdecimal
isdigit
isidentifier
islower
isnumeric
isprintable
isspace
istitle
isupper

This works with all libraries, functions, classes, etc. and it makes it easier to develop the code.

Search also within the docStrings

We can also go a step further and make it search inside docStrings as well:

1
2
3
4
5
6
7
8

def doc_dir(modul, word=''):
    word_lc = word.lower()
    for d in dir(modul):
        doc_string = modul.__getattribute__(d).__doc__ or ''
        if word_lc in d.lower() or word_lc in doc_string.lower():
            print('=>', d)
            print(doc_string)
            print('---' * 30)

Line 4 looks interesting. What we do here, is that we take a function name (i.e. ‘zfill’) that we get from dir(modul) as a string and we convert it into an actual function. Then we call its __doc__ to get the docString. In some cases the docString is not defined and the modul.__getattribute__(d).__doc__ will simply return None. To avoid getting

1

TypeError: argument of type 'NoneType' is not iterable

when searching for our word, we need to guarantee that a string is returned. Therefore in this code if 1st part returns None, the 2nd part makes sure that at least an empty string is returned.

Then in line 5, we check if our word is in the name or in the docString.

We can simply use it as:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33

my_string = 'key!'
doc_dir(my_string, 'lower')

=> capitalize
Return a capitalized version of the string.

More specifically, make the first character have upper case and
case.
---------
=> islower
Return True if the string is a lowercase string, False otherwise

A string is lowercase if all cased characters in the string are
there is at least one cased character in the string.
---------
=> istitle
Return True if the string is a title-cased string, False otherwi

In a title-cased string, upper- and title-case characters may on
follow uncased characters and lowercase characters only cased on
---------
=> lower
Return a copy of the string converted to lowercase.
---------
=> swapcase
Convert uppercase characters to lowercase and lowercase characte
---------
=> title
Return a version of the string where each word is titlecased.

More specifically, words start with uppercased characters and al
cased characters have lower case.
---------

The johnnydep library

You can simply install it with pip install johnnydep.

Then, if you want to get the list of dependencies of latest version of i.e Django library, you can call it with:

1

johnnydep Django

and it will output:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

2022-10-29 19:15:46 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:15:50 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:15:51 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:15:52 [info    ] init johnnydist           [johnnydep.lib]
name                 summary
-------------------  ------------------------------------------------------
Django               A high-level Python web framework that e
├── asgiref<4,>=3.5.2  ASGI specs, helper code, and adapters
├── backports.zoneinfo Backport of the standard library zoneinfo
└── sqlparse>=0.2.2    A non-validating SQL parser.

Or you can specify the library’s version as well:

1

johnnydep Django==4.0.3

and it will list the dependencies for that version:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

2022-10-29 19:16:55 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:16:56 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:16:57 [info    ] init johnnydist           [johnnydep.lib]
2022-10-29 19:16:58 [info    ] init johnnydist           [johnnydep.lib]
name                 summary
-------------------  ------------------------------------------------------
Django==4.0.3        A high-level Python web framework that e
├── asgiref<4,>=3.4.1  ASGI specs, helper code, and adapters
├── backports.zoneinfo Backport of the standard library zoneinfo
└── sqlparse>=0.2.2    A non-validating SQL parser.

List dependencies of all libraries in your project

Let’s first activate the virtualenv or your project:

1
2

cd your/project/folder/
source <venv_name>/bin/activate

List dependencies of installed version of each library

Ok. Now, if you want to list the libraries of your entire project, you can call:

1

pip freeze | xargs -n1 johnnydep

where pip freeze lists all installed libraries with their versions (1 library per line) and the -n1 parameter of xargs command ensures that it will feed 1 line at a time to the johnnydep library. This will list the dependencies of all libraries in you project, for the versions that you use.

List dependencies of the latest version of each library

You can also list all the dependencies of the latest versions of all of the libraries from your project, by calling:

1

pip freeze | awk -F "==" '{print $1}' | xargs -n1 johnnydep

The awk -F "==" '{print $1}' will split the e.g. Django==4.0.3 into Django and 4.0.3 and will pass only the first value to the johnnydep library.

We have a list of IDs that need to be processed. This list can hold from just a dozen of IDs to up to a few 100,000 IDs. Each ID is processed only once in each iteration and the order of IDs is not important.

This whole thing is presenting a bottleneck in our application, so we decided to take a look at other iterable data structures that Python offers.

To demonstrate this, we will create a simple example:

1. Function that generates a shuffled list of positive and negative numbers:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

from random import shuffle

def get_numbers(power=2):
    low_end = -10 ** power
    high_end = 10 ** power
    # generate list
    arr = [i for i in range(low_end, high_end)]
    # shuffle list
    shuffle(arr)
    # remove 25% of numbers, less numbers will have it's pair
    remove_n_elements = int(len(arr) * .25)
    arr = arr[remove_n_elements:]
    return arr

This will return:

1
2

get_numbers(2)  # list of 150 unique numbers, between -100 and 100
get_numbers(3)  # list of 1500 unique numbers, between -1000 and 1000

2. Then we will define a simple function that will iterate through list, tuple or set and find pairs, where the sum of both numbers equals sum:

1
2
3
4
5
6

def find_pairs(arr, sum):
    pairs = {} 
    for i in arr:
        if (sum - i) in arr:
            pairs.add((i, sum - i))
    return pairs

3. And let’s also create a function that will measure the execution time of find_pairs() function:

1
2
3
4
5
6
7

from time import time

def measure_time(nums, sum):
    start = time()
    pairs = find_pairs(nums, sum)
    end = time()
    return end - start  # seconds

Okay, now we can measure time, based on number of elements.

150 numbers:

1
2
3
4

numbers = get_numbers(2)         # list of 150 numbers
measure_time(numbers, 17)        # ~ 0.000271 seconds
measure_time(tuple(numbers), 17) # ~ 0.000224 seconds
measure_time(set(numbers), 17)   # ~ 0.000046 seconds

With 150 numbers, using set is ~5.89 times faster than using list.

1,500 numbers:

1
2
3
4

numbers = get_numbers(3)         # list of 1,500 numbers
measure_time(numbers, 17)        # ~ 0.025494 seconds
measure_time(tuple(numbers), 17) # ~ 0.026308 seconds
measure_time(set(numbers), 17)   # ~ 0.000418 seconds

With 1,500 numbers, using set is ~60.99 times faster than using list.

15,000 numbers:

1
2
3
4

numbers = get_numbers(4)         # list of 15,000 numbers
measure_time(numbers, 17)        # ~ 3.825252 seconds
measure_time(tuple(numbers), 17) # ~ 3.786150 seconds
measure_time(set(numbers), 17)   # ~ 0.006523 seconds

With 15,000 numbers, using set is ~586.42 times faster than using list.

150,000 numbers:

1
2
3
4

numbers = get_numbers(5)         # list of 150,000 numbers
measure_time(numbers, 17)        # ~ 834.580523 s = 13 min 54.58 sec
measure_time(tuple(numbers), 17) # ~ 854.708630 s = 14 min 14.70 sec
measure_time(set(numbers), 17)   # ~ 0.07081294 seconds

With 150,000 numbers, using set is ~11,785.70 times faster than using list.

Conclusion:

list and tuple work pretty much with same speed, but set made a big difference, here.

By using the set instead of list we significantly sped up the code.