Forem: Jordan Haines

Just use this Next.js Eslint Configuration

Jordan Haines — Sun, 12 Jan 2025 18:59:34 +0000

Here, Take this Configuration

I get it. If you're just here to find a good, working ESLint configuration for a NextJS project, then look no further. Copy what's below. Although, it's probably out of date, so you can find a version that's been updated since I published this post in my open source project Historio ➡️ in Github here ⬅️.

eslint.config.mjs

Run this command to install necessary npm packages:

npm i --save eslint typescript-eslint eslint-config-next eslint-plugin-react eslint-plugin-react-hooks eslint-plugin-tailwindcss eslint-plugin-unicorn

Why Lint

When starting a new project, the very first thing I do is write some really sloppy, hacky, and messy code that (mostly) just works. I'm trying to validate an idea; to get a product off the ground.

This lasts all of about 2 pull requests before it gets out of hand, and I need some rules. You can see the exact moment in Historio where I realized inconsistent code was holding me back in this pull request where linting was first applied.

Having conventions on shared projects helps keep everyone aligned and working in the same direction. Conventions allow us to focus code reviews and discussion on the logic problems that matter instead of the semicolon placement or tab size that - frankly - only matter because they’re a distraction. Written conventions for a team, starting with a style guide but encompassing any rules that keep engineers focused on engineering, are thus essential.

The benefits to a team may be obvious, but even individual projects deserve conventions. Perhaps even stricter ones. Indeed, when I’m working on a project alone, I tend to codify a larger set of conventions than I would with a team simply because I get to do everything exactly my way. It's unclear if this is software engineering bliss or OCD. Every convention eliminates decisions I would otherwise have to make in the future (often many times over). Further, without a colleague to review every line of code I write, conventions help keep me consistent and tidy even when I really want to move fast.

How I Arrived at this Configuration

Other coders have thought longer and harder about conventions than I ever want to. When spinning up a new linting configuration or style guide, I look to what already exists. For my stack, this includes the following ESLint Plugins. For each, I start with their recommended config:

Vercel's rules for NextJS
Official React eslint plugin
Typescript ESLint
Tailwind
Drizzle
Unicorn - This is the big one, with lots of rules and opinions on general typescript styling outside of conventions for the specific frameworks covered by the plugins above.

Additionally, here are a few plugins I evaluated but decided not to use:

AirBbB. I usually start here, but Vercel's config covered most of what I care about for both React and Node code styling.
XO. This feels like the Black of Typescript linting. XO has styles for everything and is very opinionated. This can be nice, because it takes a lot of code style decisions off of your plate. But beware it can be cumbersome to implement in the middle of a project because it will require extensive reformatting. In lieu of XO, I found Unicorn opinionated enough and more immediately useful.

Technical Note on ESLint Config

There are too many ways to configure ESLint. I started with the .eslintrcs.json config that came from create-next-app. However, this configuration is now deprecated in favor of eslint.config.mjs.

Because I couldn't easily extend this deprecated configuration, I (swore and then) scrapped it and initialized a new eslint config with npm init @eslint/config@latest. I then added the configuration for next wrapped with eslint's flat compat utility. Here's the snippet in eslint.config.mjs:

import { FlatCompat } from "@eslint/eslintrc"
export default const config = [
// other ESLint plugins and rulesets
...compat.config({
    extends: ["next"],
    settings: {
      next: {
        rootDir: ".",
      },
    },
  }),
]

Most other plugins offer a configuration that can be plugged into eslint.config.mjs directly. But if you see an error starting with:

Support for loading ES Module in require() is an experimental feature and might change at any time
then you probably need to wrap a plugin with that flat config migration utility

Sharpen Skills by Exploring Linting Config

Ultimately, there is no single "right" style guide or linting configuration. You should choose what works best for your project. When creating or revisiting my configurations, I often uncover new tricks or coding conventions that make me a better software engineer. when putting together this configuration, I learned:

It's important to deal with the ambiguity of null and undefined in JS/TS, but how you do it is project-dependent. By default, unicorn encourages use of undefined over null always, but there are very legitimate reasons to use null, like if you have a lot of code that leverages an ORM with null values. This long thread has many great points and no single right answer.
Avoid passing a function reference directly to iterators (i.e. {elements.map(callback)}) details

Your style guide also shouldn't be static. It should evolve as your project grows. Not only do the needs of your project change, but conventions, libraries, and coding languages evolve around your work, too. It's okay (good, even) to make considered and reasoned changes to your conventions, even if you're backtracking on something you once felt was really important.

NextJS + Drizzle -- 8 Things I Learned Spinning up a New Project

Jordan Haines — Fri, 01 Nov 2024 20:47:00 +0000

The best way to learn is by building new stuff (for me, at least). I'm building Historio -- a web app to explore history through timelines and your favorite books. I'm intentionally learning a new stack and dev tooling along the way. I'm a month or so in -- here's what I've learned creating a new NextJS + Drizzle project from scratch.

Subscribe to Learn, Build, Teach {Repeat}!

1. Run TS files as a script from your terminal

To test and iterate on backend code, I've started calling some modules (like OpenAI researches) from scripts I execute via the terminal. Copious console.debug and console.warn statements make this a kinda effective way to debug without having to craft a frontend. To execute these scripts, I use TSX resulting in commands like this one that extracts events from history books:

npx tsx scripts/scriptProcessBook.ts

2. How NOT to execute async functions in series

Quiz: Will these async functions be executed in series or parallel?

_.range(10).forEach(async (idx) => doSomething())

The answer: In parallel, which is not what I wanted. Turns out the right answer is a good ole' fashioned for loop:

for (let i = 0; i < 10; i++)
 doSomething()

3. How to set common fields on all Drizzle models

One pattern I love with Django’s ORM is using abstract models to define fields that are re-used across models. This makes it easy to ensure models are consistent and core fields are predictable. To achieve a similar pattern with drizzle, I defined common fields in an object that gets spread in model definitions:

import { timestamp, uuid } from "drizzle-orm/pg-core"

export const BASE_SCHEMA_FIELDS = {
  id: uuid("id").primaryKey().defaultRandom()
}

// to implement in a model:
import { BASE_SCHEMA_FIELDS } from "./common"

export const books = pgTable("books", {
  ...BASE_SCHEMA_FIELDS,
  title: varchar("title"),
  author: varchar("author"),
  // ... additional fields
})

4. How to deploy a static site with Cloudflare pages

The way I deploy websites has evolved over time. My first sites were deployed by dragging a folder from my computer to a server with an FTP client; with git, I started using git pull on the server, followed by some bash scripts; the final evolution brought all of this into CI/CD pipelines that magically work most of the time and require so much grief to debug the rest of the time.

However, hose pipelines (even Github pages) are overkill if you merely want to deploy a static site.

I'm trying (and mostly succeeding) not to over-engineer Historio, and stuck to Cloudflare pages to deploy the initial landing page. It couldn't be easier. Literally just drag and drop a zip folder with a static site and boom it’s deployed.

The Rest!

Read about my other 4 learnings here, including how to set created and updated timestamps on Drizzle models that automatically get set when objects are created/updated. If you find this useful, subscribe to LBT{R} where I write about a range of web development and product management topics like this.

🤔 For the Commments

What were your first learnings with NextJS or Drizzle?

How to filter on number or date custom fields in ActionNetwork targeting

Jordan Haines — Fri, 29 Mar 2024 19:45:00 +0000

This week I learned how to filter (using less than/great than) on a number custom field in ActionNetwork targeting. Because we focus on young progressives at Run for Something, you can imagine we target folks based on their age, when available.

The ActionNetwork docs allude to using << and >> to filter on custom number/date fields but this was not working for our age custom field. The issue was that - in addition to ages - this field contained data like the string "n/a" and "prefer not to answer" (largely from old data sources that were not validated). So, to filter on a number or date field in ActionNetwork, as their docs suggest, you must ensure the custom field has a consistent data type and that there aren't strings mixed in with date or number values (null values are fine).

One way to ensure this is the case is to add some field validation. This is the closest analog to designating a field type that ActionNetwork has.

Work Hard, Play Hard(er)

Jordan Haines — Mon, 02 Oct 2023 15:53:00 +0000

This post was originally published at Kalosal.com

I am somewhere in the middle of a journey from being an enthusiastic to skeptical participant in Grind Culture. This system measures worth and success based on the “grind” of work. Along the way, I've realized that the trick of relating work and play in the first place is deceptive. Hard work cannot be balanced by hard(er) leisure. And the grind comes from trying.

How much is one hour of leisure worth to you? Your economics 101 professor may argue that it's worth exactly your wage because taking that hour of leisure means giving up the opportunity to work another hour. According to this logic, the average American's leisure time is valued at just under $30 per hour.

Your professor - of course - is wrong. I doubt anyone making $55K per year would trade an hour of partying, attending a concert, or having dinner with their grandma for thirty bucks. (And yes, there are more complex economic theories that can assign higher values to an hour of leisure, but they all fall short in capturing the true value of leisure in the first place.)

In America, especially in work environments affected by Grind Culture, the value of labor is not accurately reflected by the amount you're paid for it. For many people, there is an implicit expectation of future value associated with each hour of work. I like to call it the "American Dream". In this perspective, every hour you invest in your job is an investment in your future self – someone with enhanced skills, a stronger work ethic, and valuable professional connections. This is in addition to the 30 dollars you bring home.

This concept of the American Dream may be most prescient for founders and small business owners who very literally have a vested financial interest in their work beyond their salary. For early-stage founders, a few extra hours of work now could potentially be worth millions of dollars in the future. Given the high stakes, it's hard to justify not working the extra hour or two.

There is one thing your econ 101 professor wasn’t simplifying, though: Unless we’re careful, as the value of work inflates, the value of leisure rises to match it. More specifically, the value required of leisure rises to match it. If working a few extra hours could potentially result in million-dollar gains, how can one justify taking a vacation or even spending an afternoon peacefully binge-watching a show on Netflix?

By operating within this framework, you're essentially gambling with your free time. Sacrificing leisure for work that may or may not bring significant value is a risky bet. It may not pay off, but it will definitely deprive you of those “leisure” moments to relax, find joy, be present with loved ones, or grow as a person. Sound harsh? Perhaps this isn’t the right framework to consider work and leisure in the first place.

At one point, I thought I merely had the causality wrong. Maybe it's not that the value of work determines the price of leisure, but rather the value of leisure determines how much an hour of work is worth (or worth giving up). But even this perspective feels off. The value of leisure is different from the value of work, and both have real worth that cannot be quantified in dollars (regardless of how complex the economic formulae get).

Grind Culture’s greatest trick is that it puts work and leisure in the same equation to begin with. As if they’re directly related. As if the value of leisure and work doesn’t change day to day depending on how you feel and what you need. As if doing more of one necessitates doing less of the other. We shouldn’t discuss work and leisure in the same sentence except to acknowledge that there’s leisure in work and work in leisure. Sometimes playing hard is hard work, and working hard is a lot of fun. “Work/Life” balance is a false dichotomy that reads as if we’re balancing two things on a teeter totter; more of one, less of the other. “Work Hard Play Hard” goes a step further to imply that more work necessitates more leisure. Neither is true.

The antidote? Work hard - or don’t. Play hard - or don’t. Balance hard work with easy work; un-fun work with fun work; play with leisure (they’re different); relaxation with growth. Be very wary of sacrificing “low-value” leisure for “high-value” work. Like doubling down on a bet when the odds are stacked against you, it’s a decision (and time) you can’t get back.

4 Bullet Thursday

Jordan Haines — Fri, 13 Jan 2023 03:50:29 +0000

This post originally posted at kalosal.com

My past week, summed up in 4 bullet points on things I found cool or found myself returning to think about:

I finally retired my Economist Holiday Double Issue this week. This issue - which spans the last two weeks of the year - is always my favorite because it combines two of my favorite things: the writing of The Economist and history. Some things I learned this year include: Chicago is the grid-iest city; if Satya Nadella and his friends have their way, Cricket may be the next big sport in the US; and guano (yes that guano) was a valuable commodity back in the day before synthetic nitrogen fertilizers. I nearly got through all the fun articles before the first issue of 2023 arrived. (I have a strict rule that the previous issue of any periodical must be recycled when the next issue arrives lest they pile up and create the hell described in The Good Place).
This week I was playing Factorio On Switch. I'm one of those people who likes my games to feel like work. Because of the cult popularity of Factorio, I know I'm not alone. Factorio basically boils down to a huge optimization problem as you configure robots and complex manufacturing workflows to research and build a series of successively more resource-consuming items. Factorio is incredibly well-balanced and challenging enough to keep me returning for casual play. If you like simulation/management games, check it out!
We got a Breville Bambino as a wedding gift and now that I've started using it I literally can't stop. With no shame, I'm buying vanilla syrup by the case and making myself lattes for dayyys. I also have so much more respect for baristas after the stress of deciding to make a latte 4 minutes before a meeting starts.
Every couple of months I totally revamp my task, notes, and planning systems. There is perhaps no better catalyst for this change than New Years Resolutions (which of course must be specific, measurable, attainable, relevant, and timely). My most recent revamping involved moving all of my tasks - including goals and habits - into ClickUp (which I was previously using just for work). Before you start thinking that these posts are all about me flogging products, let me be very clear that I don't recommend ClickUp (notice I didn't link it. That'll show 'em). It's buggy and clunky and better for teams than individuals. BUT at least all of my stuff is in one place now. And I've found that when it comes to task systems, it's constantly revamping them that matters far more than what system one uses at a given time.

The Product Development Cycle

Jordan Haines — Sun, 02 Jan 2022 14:56:49 +0000

Originally posted on Codified Musings

Delivering great product to customers is hard. Commonly, the product and design team thinks the software engineers cut the one feature that ties the product together because it “literally like quadruples our complexity”. The engineering team thinks the product is poorly specified. The operations team thinks the solution is over-engineered and difficult to roll out. And the leadership team just wants to know why the whole process is taking so darn long.

Great product management serves to placate these varied (and legitimate) concerns while still delivering a delightful product to end-users that is sorta on time and maybe even within budget.

As I tease out what makes great product management…great… in other posts, it’s worth taking a moment to explore the product development lifecycle (PDL). In this post I will outline the 5 stages of the product development lifecycle and describe why the lifecycle as a whole is useful. In later posts I’ll dive deeper into each stage to discuss common pitfalls, what success really looks like, and how to best engage product stakeholders.

First: What the heck is this PDL thing?

The Product Development Lifecycle

In a nutshell, the product development lifecycle includes everything that happens between when it becomes apparent a new feature is necessary to it being rolled out to customers and even iterated upon. Crucially, ideation is a part of the product development lifecycle, so the process often begins before what becomes the product even crosses anyone’s mind. The PDL can be broken down into 5 stages:

Identify the problem
Design a solution
Build and test the solution
Rollout!
Measure success and Iterate

1. Identify the Problem

Tools for this stage: SCAMPER, Product Hypothesis

Great product starts with a real problem. Unsuccessful products are often great solutions in search of a problem. In this phase you’ll first identify the problem to be solved and then ideate solutions. Note that another way to think of the “problem” to be identified is actually as an opportunity: New products capitalize on the opportunity to solve a problem for users.

Be wary of products that start as a solution (“Wouldn’t it be cool if we made a mobile app version of our website”) as oppose to a problem (“I noticed that most of our users abandon our site during registration, and most of our competitors have mobile apps that don’t require registration. Should we build a mobile app?”).

To rock problem identification:

Ensure that the problem being solved is visible in data. For example, if the problem you are trying to solve is that people never return to your site after registering for an account, you should have clear abandonment and retention metrics that illustrate this problem. Identifying these metrics at the beginning is also important because their improvement is how you’ll ultimately measure success. Be wary of attempting to solve a problem that is not yet measured.
Identify the stakeholders whose perspective you’ll need to design the perfect solution to the problem. This should include end-users, and may also include other product teams, company leadership, support, sales, and even marketing teams.

At the end of this stage you will have: A single clearly identified problem to be solved visible in data, including an idea of the KPIs that can be used to confirm the problem is solved.

2. Design a Solution

Tools: SWOT and RICE

Let the brainstorming begin! Ideate the solutions to the problem you’ve identified. In this stage, you should pay special attention to your user personae.) (you have those defined, right?). This is especially important if multiple types of users face the problem you’ve outlined. Your solution should be a Pareto improvement: benefiting at least 1 type of user while not making things worse for any other persona. If you end up needing multiple solutions for your different personae, that’s okay!

Remember those 5th grade science fair projects? Turns out that just like in those projects, thinking of new product in the form of a hypothesis is super useful. Phrase each of your potential solutions in the form of a product hypothesis like the one below. This construct ensures you have a clearly identified problem, and that the proposed solution is a (potential) way to solve it. Your product hypotheses should take the form: By doing , we will as measured by . Example product hypothesis:

By automatically sending engagement texts from customer success team members, we can increase customer retention in the first week after account creation as measured by our daily customer retention KPI.

Need help choosing the right solution? If you’re stuck, consider a framework like RICE or SWOT to evaluate and compare solutions. Ensure you have a solid product hypothesis for your final idea and then craft a Product Requirements Document (PRD) that articulates the goals, granular requirements, and implementation details for the product.

At the end of this stage you will have: A single product idea that you’ve decided to move forward with, and a few other candidates you considered. The final product idea has a clear product hypothesis and measurable goal, is specified through PRD/TSD, and has buy-in from all key stakeholders (including the end-users you - as PM - represent).

3. Build and Test the Solution

Tools: Critical Path Method — Shortcut; Jira — PRD.

Bad product teams spend all of their time on this stage. Great product teams realize that investing in the other four stages of the PLD makes this stage - building the solution - easier. So don’t start with this stage; don’t end with this stage. And if you find yourself dreading this stage, then you probably aren’t spending enough energy on the others (hint: Stage 2 is where to look first!).

In this stage you work closely with your design and engineering teams to bring the designed solution to fruition. Unless you’re directly writing code, your role during this stage verges into that of a project manager: keep the feature development on schedule.

You should be anticipating the challenges that will arise and circumventing them as best you can. This means:

Ensuring any questions on the PRD receive swift and thorough answers.
Ensuring all copy, messaging, and other “soft” parts of the specification are included before engineers need them.
Providing swift feedback on features as they are completed so the engineering team can focus on building and iterating.

You’ll likely use some technical project management software like Shortcut or Jira during this stage to track the progress of features as they are built. These software provide tools like burn down charts and other velocity metrics that can help you see what components are on time or falling behind.

Don’t forget to test! I’m sure your engineering team only builds perfect bug-free products 😏. But even if they do, it’s important to test to ensure the product works as intended and actually achieves the vision set out in the product hypothesis. Get feedback from as many stakeholders as possible, including real end-users where you can (if you can’t, then your job is to represent them as you test yourself). Testing is complete when all stakeholders agree that the product is ready to be rolled out to newly delighted end-users.

At the end of this stage you will have: A built and tested prototype that is ready to roll out to at least some of your users.

4. Rollout

Tools: Internal Knowledge Base like Notion, Confluence or Guru

The software is built! Time to deploy and then you’re done, right? Almost. Rolling out complex software requires a lot of coordination. As PM, it is your responsibility to ensure this coordination happens, that everyone knows that the new product exists as well as how to use it, and that reference materials exist for new customers/team members (or those that are apt to forget).

Ensure that your product update is well documented prior to launch. Expect people on your team and customers to ask some variation of “what the heck is this?” Instead of copying and pasting the same response over and over again, do yourself a favor and curate documentation ahead of time in a knowledge base like Notion, Confluence or Guru that you can link to. Particularly when the product changes internal operations, you may need to create separate public-facing documentation (for customers) and internal documentation (for ops/support teams).

PMs who were previously software engineers tend to underestimate the importance (and work required) of this stage. Engineers are used to “finishing” a product once the code is written and feature is tested. But the PM’s job is not done until product is built, actually used, and achieving success as laid out in your product hypothesis.

At the end of this stage you will have: Documentation for your team and end-users describing your new product and how it works. Support and operations teams will understand the new product in-depth, including any new tools at their disposal to support customers using the product.

5. Measure Success and Iterate

Tools: BI or KPI dashboards like Datastudio or Looker — Product Hypothesis (round2)

Even once your great new product is in the hands of end-users, your job is not done. Return to your product hypothesis from stage 2: What was the goal of this product again? How were you going to measure success?

It’s time to see your work pay off: Measure the KPIs you identified from stage 2 and compare them to where they were before your new product went live. An improvement in those indicators signifies a product success. Of course, the usual caveats of not confusing correlation with causation apply; if there were other initiatives that coincided with the launch of your product and could have affected your KPIs then you’ll need to adjust your assessment accordingly. If you’re really geeky, you can even test for a statistically significant improvement.

KPIs didn’t improve? Well that’s kind of a win, too. You found something that didn’t work, or at least didn’t work in the way it was built. This is where the “cycle” part of the Product Development Cycle comes into play. Circle back to those KPIs that have yet to be improved, and return to Stage 1 to define the problem and (in Stage 2) ideate solutions to build upon your success.

But be careful! One common PM pitfall is focusing only on product that isn’t working well. While this is important, don’t neglect further improving the parts of your product that are successful to make them even more so (more on this trade off later 😉).

At the end of this stage you will have: Measured the success of your new product against your product hypothesis and KPIs. Areas of further improvement - both in product that did and did not achieve its goal - are identified and you’re eager to jump into another go around the Product Development Cycle.

Django and Cloudwatch: Logging in a place you can see

Jordan Haines — Sun, 24 May 2020 17:41:24 +0000

This post describes how to get Django log messages into Cloudwatch. We'll configure a Cloudwatch log handler, and then outfit a DRF view to log a message to our Cloudwatch stream when a new object is created. This mimics a recent practical use case I encountered: Logging every request to a public API endpoint in Cloudwatch to aid in debugging. Let's get into it!

Originally posted on Codified Musings, cross posted on Medium

Complete Demo Code

Setup Cloudwatch - Copy AWS credentials

This post will not go into detail on setting up an AWS account. From AWS, you'll need the Access Key and ID for a user with write access to Cloudwatch logs. I'd recommend not using account you use to login to AWS. Instead, create an IAM user who we can grant Cloudwatch write access to. I tend to create separate users for dev, staging, and (especially) production environments for security and to aid in tracking down issues. At the end of the day, you'll need to make sure the IAM user you're using has the CloudWatchLogsFullAccess permission, and you'll want to copy both the Access Key ID and Access Key Secret for an access key for your user (click Create access key if you need new credentials)

Configure Django Logging

We are going to override the Django Logging setting to create a new logger, handler, and formatter to get our log messages into Cloudwatch.

Install the python packages we need (boto3 to interact with the AWS API, and Watchtower to get push logs to Watchtower, specifically). Run pip install watchtower boto3 (you're running in a virtual environment, right?).
In your settings file, instantiate a Boto3 session that Watchtower can use to connect to your AWS Cloudwatch account. In this example, I've put my AWS access key ID and Secret in the AWS_ID and AWS_KEY environmental variables.

from boto3.session import Session
# ...
CLOUDWATCH_AWS_ID = os.environ.get('AWS_ID')
CLOUDWATCH_AWS_KEY = os.environ.get('AWS_KEY')
AWS_DEFAULT_REGION = 'us-west-2' # Be sure to update with your AWS region
logger_boto3_session = Session(
    aws_access_key_id=CLOUDWATCH_AWS_ID,
    aws_secret_access_key=CLOUDWATCH_AWS_KEY,
    region_name=AWS_DEFAULT_REGION,
)

Define new LOGGING settings in your Django settings file. Here's the complete LOGGING settings you'll want to add (example):

LOGGING = {
    "version": 1,
    "disable_existing_loggers": False,
    "formatters": {
        "aws": {
            "format": "%(asctime)s [%(levelname)-8s] %(message)s [%(pathname)s:%(lineno)d]",
            "datefmt": "%Y-%m-%d %H:%M:%S",
        },
    },
    "handlers": {
        "watchtower": {
            "level": "INFO",
            "class": "watchtower.CloudWatchLogHandler",
            # From step 2
            "boto3_session": logger_boto3_session,
            "log_group": "DemoLogs",
            # Different stream for each environment
            "stream_name": f"logs",
            "formatter": "aws",
        },
        "console": {"class": "logging.StreamHandler", "formatter": "aws",},
    },
    "loggers": {
        # Use this logger to send data just to Cloudwatch
        "watchtower": {"level": "INFO", "handlers": ["watchtower"], "propogate": False,}
    },
}

Let's break this down.

"formatters": {
        "aws": {
            "format": "%(asctime)s [%(levelname)-8s] %(message)s [%(pathname)s:%(lineno)d]",
            "datefmt": "%Y-%m-%d %H:%M:%S",
        },
    }

This adds a new formatter which defines how our logged messages will appear in Cloudwatch. This formatter ensures the time and log level are in the title. Here is what the resulting display looks like in Cloudwatch:
2020-05-24 15:26:48 [INFO ] Student Created: Arya Start (PK: 4) [.../django-starter-project/schoolusers/views.py:23]

"handlers": {...}

This section creates a new handler that will forward all logs of level INFO or higher, to the designated loggers (in this case, just our watchtower logger). The log_group key indicates the log group, and stream_name the Cloudwatch stream within that group, that our message will appear under. Finally, we specify the aws formatter which dictates how logged messages will appear

"loggers": {
        # Use this logger to send data just to Cloudwatch
        "watchtower": {"level": "INFO", "handlers": ["watchtower"], "propogate": False,}
    }

This section defines a new logger for Cloudwatch. All messages of level or higher (that is, level "INFO") or higher, will be sent to the watchtower handler. The propogate property determines whether messages will be sent to additional loggers.

Posting a Log Message From a View

Alright, we've configured our Cloudwatch logger. Let's test it out. I added the following two lines to one of my views, specifically when a student is created in my school demo project (complete views code):

logger = logging.getLogger("watchtower")
logger.info(f"Student Created: \n\n {student.name} (PK: {student.pk})")

I then test by posting to this view with Insomnia Rest Client. For this post, I also include example code that executes a request that uses this view, and thus should post a log message to Cloudwatch if you've configured your logger properly.

In my demo project, when a POST is made to create a new student, I see a message like the following appear within Cloudwatch 😀:

Enriching your log messages

I lied - the example above is not the extent of the logging I do with Cloudwatch. Because we have apps running in separate environments for local development, staging, testing, and product, we break out the logs for each of these environments to make messages easier to find (and to potentially add alarms to the production logs). In case this is also useful to you, we do this by:

Defining an ENV setting that describes what environment we're in. This setting can be set from an environmental variable, or you can use a different settings file for each environment to set a different value. In our logging configuration, we include ENV in the stream_name so that each environment has its own log stream within our Cloudwatch log group.
We define an aws logging filter that attaches ENV to a new env property on the message. This was a key learning for me -- you can use a filter to add data to a log message*:

class CloudwatchLoggingFilter(logging.Filter):
    """ Filter which injects context for env on record """
    def filter(self, record):
        record.env = settings.ENV
        return True # All messages make it through filter

We use this new env property in the title of the message for good measure.

This is the code you'll find in the demo code

An aside on Django Logging

As I dove into this topic, I found Django logging to be quite a bit more complex than expected. The Django Logging Documentation does a great job of explaining how logging works, how to setup your own loggers, and how to get different types of log messages to different places. Below are my notes:

Overview:
Loggers are buckets where messages (Log Records) are sent. Loggers have a Log Level (DEBUG, INFO, WARNING, ERROR, CRITICAL); Loggers ignore records with a log level below the logger's level.

Loggers send messages (that they don't ignore) to one or more Handlers. Handlers determine what to do with a log record - like writing to console, a file or - as in our example above - to a log repository like CloudWatch. There is a many-to-many relationship between handlers and loggers, so the same handler can be re-used across many loggers. Handlers have their own log level, and ignore records below the handler's log level (allowing different forms of notification - based on record level - for the same logger).

I know what you're thinking: This whole system is not nearly granular enough. Enter filters. Filters provide additional control over which log records make their way from a logger to a handler. Filters can alter the log level of a log record; they can also suppress log records based on their source or other metadata on the log record. Filters can be chained.

Big Revelation

Filters can attach additional information to log records which can then be used in formatters to customize the display. I used this feature to attach a Django setting variable (ENV) to records, so the ENV is visible in the log record in CloudWatch.

Finally, once a record makes its way to a handler and the record has a log level at or above that of the handler a formatter is used to determine how the record is written by the handler. A formatter is just a python formatting string that leverages the Log Record Attributes.

Cool? Cool. In summary:

Log Record created. Sent to all loggers, but ignored by loggers w/Log Level above that of the log record.
Filters (associated with each logger) are applied to determine which records actually get passed to handler(s).
Records that aren't suppressed by filters get sent to all of the handlers on logger. Handlers ignore records below the handler's log level
Handler uses formatter to determine what the record will look like when you read it. Handler writes the record (to a file, or console, or Cloudwatch, etc).