DEV Community: Alec Larson

Postgres TypeScript bindings for "stored procedures"

Alec Larson — Tue, 17 Dec 2024 21:51:26 +0000

Disclaimer: If you have preconceived notions about making heavy use of “stored procedures” (personally, I just call them “routines” like Postgres does), then you probably won't like what I'm showing you, and I won't try to convince you.

I'm the creator of pg-nano. It's not an ORM, a query builder, or a basic query driver, but it's closest to the last one. The twist is, it's also a migration tool and a code generator. It's not production-ready yet (more on that below).

The link: https://github.com/pg-nano/pg-nano/

It generates TypeScript bindings for your native Postgres routines (think CREATE FUNCTION or CREATE PROCEDURE, excuse the caps). For views (e.g. CREATE VIEW), pg-nano can infer each column's “nullability” via static analysis. I plan to extend that inference to user-defined routines in the near future, but the generated types are already quite good.

From your TypeScript application server, you call your Postgres routines with 100% type safety. The query driver uses libpq, the official C driver, under the hood. I've implemented a connection pool, auto-reconnect with exponential backoff, and query streaming on top of libpq.

It scans a directory for .sql files and instantly updates your local database instance by diffing the current schema with the desired schema. It only drops data if absolutely necessary. Note that I haven't implemented production migrations yet, which will of course err on the safe side.

I use a combination of static analysis (parsing your SQL) and introspection (querying Postgres system tables) at compile time to both generate the TypeScript bindings and the migration plan.

The link again: https://github.com/pg-nano/pg-nano/

I posted all this to get your feedback:

Could you see yourself using pg-nano? Why or why not?
Are there specific features you’d like to see, or concerns you have?

I could really use some beta testers, but even your thoughts would help a great deal.

In order to get pg-nano production ready, I have a few things left to do.
Database seeding
Migrations in production
Transactions

Nim Notes

Alec Larson — Thu, 09 Sep 2021 23:22:39 +0000

Stuff to remember when developing in Nim.

^{This post will be updated over time.}

Using raise with Defect cannot be caught when --panics:on is used

You can cast noSideEffect pragma:

  {.cast(noSideEffect).}:
    # code goes here

Almost always prefer {.inline.} over template, as it lets the C compiler decide when it's best to inline a proc

Introducing filespy

Alec Larson — Tue, 16 Mar 2021 14:09:07 +0000

Today I wrote a file watching library that wraps @parcel/watcher as an alternative to Chokidar.

https://github.com/alloc/filespy/

Features

Emits files only
Crawls asynchronously before watching
Powered by @parcel/watcher for native performance, event throttling, and Watchman support
Tolerates permission errors
Has powerful pattern syntax
Handles renamed directories properly
Exposes the paths being watched
Exposes the paths that were skipped
Ensures file paths use forward slashes
Protects against reentrancy by using setImmediate before emitting
Splits up long-running listeners with setImmediate
Crashes if you don't handle error events
Waits for root directory to exist

Usage

import filespy from 'filespy'

const spy = filespy(process.cwd(), {
  only: ['*.[jt]sx?'],
  skip: ['node_modules'],
}).on('all', (event, file, stats, cwd) => {
  // "file" argument is relative to "cwd"
  // "stats" is from lstat call

  if (event == 'create') {
    // File created.
  } else if (event == 'update') {
    // File changed.
  } else {
    // File deleted.
  }
}).on('error', error => {
  // Permission error or watcher failed.
}).on('ready', () => {
  // Initial crawl completed. Watcher initialized.
})

spy.dirs // Set of watched directories.
spy.files // Sorted list of watched paths (even directories).
spy.skipped // Sorted list of existing paths that were skipped.

// List all watched paths within a watched directory.
// Returned paths are relative to cwd.
spy.list('foo/bar')

// Stop watching.
spy.close()

Events

interface {
  all(
    event: 'create' | 'update' | 'delete',
    /** Path relative to cwd */
    file: string,
    /** Equals null for "delete" events */
    stats: fs.Stats | null, // https://nodejs.org/api/fs.html#fs_class_fs_stats
    /** The root directory */
    cwd: string
  ): void

  /** Permission error or watcher failure */
  error(error: Error): void

  /** Directory was crawled */
  crawl(dir: string, cwd: string): void

  /** Watcher is ready */
  ready(): void

  /** File created */
  create(file: string, stats: fs.Stats, cwd: string): void

  /** File changed */
  update(file: string, stats: fs.Stats, cwd: string): void

  /** File deleted */
  delete(file: string, cwd: string): void
}

Pattern syntax

Filespy mixes globbing with regular expressions, a concept borrowed from Recrawl.

When a path has no separators (/), only the basename is matched.

'*.js' // matches 'a.js' and 'a/b.js'

Recursivity is implicit.

'a/b' // identical to '**/a/b'

Use a leading separator to match against the root.

'/*.js' // matches 'a.js' not 'a/b.js'

Use a trailing separator to match all descendants.

'foo/' // matches 'foo/bar' and 'foo/bar/baz' etc

Regular expression syntax is supported. (except dot-all)

'*.jsx?' // matches 'a.js' and 'b.jsx'
'*.(js|ts)' // matches 'a.js' and 'b.ts'

Recursive globbing is supported.

'foo/**/bar' // matches 'foo/bar' and 'foo/a/b/c/bar' etc

Keep @types/node out of your React project

Alec Larson — Fri, 13 Nov 2020 01:54:47 +0000

If you're trying to prevent @types/node (or any other global types package) from leaking into your React project, you will probably end up tinkering with your tsconfig.json and you'll eventually try disabling implicit type imports altogether like so:

{
  "include": ["src"],
  "compilerOptions": {
    "types": []
  }
}

But first, why is @types/node leaking into your React components in the first place? Chances are that one of your dev dependencies (eg: @testing-library/react-native if you're writing a React Native app) relies on @types/node and so it ends up in your node_modules.

Normally, that won't be a problem after you put "types": [] in your tsconfig.json, but sometimes that doesn't work, and you commence pulling your hair out.

But then, in a stroke of genius, you decide to use the --traceResolution flag when compiling your project:

yarn tsc -p . --traceResolution --noEmit

You scour its logs for the culprit, using cmd+f to save yourself some time. A-ha! Turns out a transient dependency (aka an indirect dependency) has a triple-slash directive in one of its ambient declarations (aka .d.ts modules). Behold!

/// <reference types="node" />

You screech in terror!

Now there's only one thing to do. Open a PR and maintain a fork until the dreaded <reference> tag is obliterated from this Earth, never to return.

pretty-quick git trick

Alec Larson — Mon, 15 Apr 2019 22:20:15 +0000

A cool thing about using pretty-quick in a husky pre-commit hook is that it catches unresolved merge conflicts when you run:

git cherry-pick --continue

Share your favorite mixes/playlists for programming to!

Alec Larson — Sat, 09 Mar 2019 20:28:28 +0000

I'll start us off with https://www.youtube.com/watch?v=ZSk8k6basWw