You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Instantly share code, notes, and snippets.
Jeff Schwab
jeffs
Software engineer and manager in NYC. Email jeff@unbuggy.com if you're interested in working together.
Application Programming Interface (API) design is hard. But it's even harder to change once you get it wrong. So what you should do is to spend the effort to get it right the first time around.
In the Linux Kernel community Rusty Russell came up with a API rating scheme to help us determine if our API is sensible, or not. It's a rating from -10 to 10, where 10 is perfect is -10 is hell. Unfortunately there are too many examples at the wrong end of the scale.
Logging setup for FastAPI, Uvicorn and Structlog (with Datadog integration)
Logging setup for FastAPI
This logging setup configures Structlog to output pretty logs in development, and JSON log lines in production.
Then, you can use Structlog loggers or standard logging loggers, and they both will be processed by the Structlog pipeline (see the hello() endpoint for reference). That way any log generated by your dependencies will also be processed and enriched, even if they know nothing about Structlog!
Requests are assigned a correlation ID with the asgi-correlation-id middleware (either captured from incoming request or generated on the fly).
All logs are linked to the correlation ID, and to the Datadog trace/span if instrumented.
This data "global to the request" is stored in context vars, and automatically added to all logs produced during the request thanks to Structlog.
You can add to these "global local variables" at any point in an endpoint with `structlog.contextvars.bind_contextvars(custom
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
What could we do to improve your experience next time?
Firstly, avoid the need for users to contact support:
Don't make breaking changes. (In the case at hand, the behavior of ⌘K was changed in a surprising and irritating way.)
If you must make breaking changes:
Announce them loudly. (You did not.)
Provide an opt-out, or at least a carrot that's bigger than the stick. (You did neither.)
Secondly, make the "Contact us" easier to find: Don't make me jump through multiple links and support pages on the off chance that I'll find an existing answer to my question.
From: Mark S. Miller <erights@google.com>
Date: Tue, Nov 16, 2010 at 3:44 PM
Subject: "Future of Javascript" doc from our internal "JavaScript Summit"
last week
To: javascript-standard@google.com