Tag: Python

bookmark_borderRecipe: Reducing cold start with precompiled python bytecode in serverless

Posted on by Frank-Mich L'Heureux

Scroll to the bottom if you want the recipe and skip story telling.

This is a story of software: You have a greenfield project. It’s beautiful and fast. Then you add features. For five years. Then you realize your cold start times went from ~1 second to ~5.5 seconds.

To be fair, a ton of things happened in between and I did realize that cold start time had gone up like crazy. Some mitigating steps were taken to “control” them. Although, my local tests had always shown that precompiling bytecode was the best way to improve cold start, I never managed to make it work into production. Despite the precompilation, it kept being slow.

Then comes the AI and spare time. And the conversation basically goes like

🧑‍🦱Me: Hey AI! I see improvements to cold start locally when I precompile my python bytecode. I don’t see it when it’s in production. I use the serverless framework. Can you tell what’s going on?

Continue reading “Recipe: Reducing cold start with precompiled python bytecode in serverless”

bookmark_borderLeveraging pydantic to avoid logging PII

Posted on by Frank-Mich L'Heureux

PII, short for Personally Identifiable Information, is often tricky to manage. Many countries have legislation around it. How much can you store, how can you store it, what is your procedure to wipe out all data about a given person? In some regards, the best way to deal with it is to view it as toxic waste. You want as few as possible, and you want guard rails around it not to get intoxicated.

In the case of logging, it’s best to just not log it. This way, you will never have to go back and figure out a way to prune your logs of PII. In this post, we will explore how to leverage pydantic models to avoid logging PII by accident. This post will use FastAPI for its examples, but it’s not required at all. It will take some input (including PII), log it, and return it.

Continue reading “Leveraging pydantic to avoid logging PII”

bookmark_borderTrue sqlalchemy unit testing

Posted on by Frank-Mich L'Heureux

tl;dr; Let’s mock the sqlalchemy calls and look at the generated SQL statements.

I’ve read a couple of articles about testing when sqlalchemy is involved. None of them really did unit testing: they all ended up doing local integration tests by spinning up a DB of some sort. While that can work pretty well in many many use cases (in-memory sqlite!), it can also be a PITA when you need to start a docker container, wait for it to boot, install plugins (moddatetime, pgtrimt, unaccent, …), instantiate the models, insert the data, and finally run the tests. While these integration tests have their value, in such slower setup there are benefits to constrain them to the bare minimum instead of being the default way of testing.

Continue reading “True sqlalchemy unit testing”

bookmark_borderMeasuring Sentry Impact on AWS Lambda Cold Start and Time to Handler

Posted on by Frank-Mich L'Heureux

At Local Logic, we rely heavily on lambda functions. We currently monitor our environment with Sentry via their sdk and know that we could use, as an alternative, the sentry layer. As a good developer, I wondered what were the pros and cons. Obviously, one of them is: which option is the fastest? So, I compared them and will share the results in this post. Without further introduction, let’s dig into the experiment.

Continue reading “Measuring Sentry Impact on AWS Lambda Cold Start and Time to Handler”

bookmark_borderIt’s a Trap! Postgis Geometry with SRID 4326 is not a Geography

Posted on by Frank-Mich L'Heureux

Long story short, you create a table with a geometry column that stores points with srid 4326 (read geographic lat/lng, or should I write lng/lat, coordinates). That should be interpreted as geography right? Not at all!

Continue reading “It’s a Trap! Postgis Geometry with SRID 4326 is not a Geography”

bookmark_borderHybrid Pydantic/FastAPI Model

Posted on by Frank-Mich L'Heureux

Short story, I have an API that doesn’t run on FastAPI, but I still use FastAPI to generate documentation in OpenAPI format.

So I have models for endpoints and I want them to work with and without FastAPI, because in their pure version FastAPI is not deployed. (To make a long story short, installing FastAPI makes the package a bit heavier to deploy, but especially the cold starts of the AWS lambdas because of the Sentry initialization delay. Sentry detects that FastAPI is present in the environment and automatically adds monitoring, which takes a good 500ms longer than when it’s missing. Measured in December 2023).

Anyway, drawing heavily on a StackOverflow answer, I produced this.

# models.py
from typing import Annotated, Any, cast

from pydantic import BaseModel, Field
from pydantic.fields import FieldInfo

try:
    from fastapi import Query  # type:ignore[import-not-found]

    def FieldQuery(*args: Any, **kwargs: Any) -> FieldInfo:  # noqa:N802
        return cast(FieldInfo, Field(Query(*args, **kwargs)))

except ImportError:

    def FieldQuery(*args: Any, **kwargs: Any) -> FieldInfo:  # noqa:N802
        return cast(FieldInfo, Field(*args, **kwargs))  # type: ignore[pydantic-field]


class QueryParams(BaseModel):
    limit: Annotated[
        int,
        FieldQuery(
            -1,
            description="The limit of values to fetch. -1 means no limit.",
        ),
    ]

And for the routes:

# routes.py
from fastapi import FastAPI

from models import QueryParams

app = FastAPI()

@app.get("/things")
def get_things(
    params: Annotated[QueryParams, Depends()],
) -> dict:
    ...

Is it perfect? With the “type: ignore”, “noqa”, “import try/except”, not at all. It looks like a big hack.

Does it work? Oh yeah!

Note: The “noqa” and “type: ignore” tags are respectively linked to ruff and mypy linters.

bookmark_borderFastAPI Stripe Webhook Template

Posted on by Frank-Mich L'Heureux

A FastAPI equivalent for verify-events-came-from-stripe.

import os

from http import HTTPStatus
from typing import Annotated

import stripe
from fastapi import Depends, FastAPI, Header, HTTPException, Request


app = FastAPI()


async def get_body(request: Request) -> bytes:
    return await request.body()


@app.post("/webhook", status_code=HTTPStatus.NO_CONTENT)
def post_report(
    stripe_signature: Annotated[str, Header(alias="stripe-signature")],
    body: bytes = Depends(get_body),
) -> None:
    endpoint_secret = os.environ["ENDPOINT_SECRET"]

    try:
        # signature validation
        event = stripe.Webhook.construct_event(body, stripe_signature, endpoint_secret)
    except ValueError as e:
        # Invalid payload
        raise HTTPException(status_code=HTTPStatus.BAD_REQUEST) from e
    except stripe.error.SignatureVerificationError as e:
        # Invalid signature
        raise HTTPException(status_code=HTTPStatus.UNPROCESSABLE_ENTITY) from e

    print(event)

    return

A possible catch, one that I ran into, is that I had FastAPI convert the request.body to a dictionary in the function parameters (so body: dict). Then I serialized it to a string for the validation step… and it failed because it was no longer identical to what came in.

bookmark_borderPython Type Hinting: To hint or to cast?

Posted on by Frank-Mich L'Heureux

During a code review, a colleague, Zachary Paden, asked me why I was calling the typing.cast function on my variables rather than creating temporary variables just to type hint. Well, just as he didn’t know about cast, I didn’t know that this approach worked. Being the nerdz that we are, he decided to measure the performance of each approach.

Continue reading “Python Type Hinting: To hint or to cast?”