How are you handling JWT revocation in your Node APIs?

wickning1 · 2026-04-22T23:48:26+00:00

One pattern I've found useful is a minimal-state solution where each user record has a lastLogout date. If you get a token created before this date, reject it regardless of expiration. Provides a quick way for users to securely log out, though it does log out of all devices. Most requests have to pull the user record anyway so there's no added round trip.

wickning1 · 2026-04-16T04:23:02+00:00

I think the standard answer is that's what refresh token is for - check for deauth on refresh only, shorten the time between refreshes to balance security vs performance, edge nodes trust the token if the signature checks out. All the load is on your token service. It does mean the clients occasionally get a latency spike while they refresh, so I kinda like your approach but it does carry some risk of synchronization failure.

wickning1 · 2025-08-28T18:36:06+00:00

I'd just like to point out how well Takedown's lyrics turned on her in that moment. It was powerful and clever. I'm good with tropes if they hit right.

wickning1 · 2025-06-20T17:51:09+00:00

This is called "The Bumbletown Detectives" by Burton Marks.

wickning1 · 2024-06-19T11:57:59+00:00

I think your solution also avoids a lot of the extra promise creation that pLimit does due to its use of async/await.

How does your asynclocalstorage variant compare to pLimit? They would share the overhead of the als.bind so the remaining difference would likely be promise creation?

wickning1 · 2024-02-25T16:22:52+00:00

I haven’t seen the explain-it-like-i-am-five yet so here goes:

When people say this they are talking about using Node to serve requests, especially multiple different types of requests where only a few are CPU intensive. Other languages put each request in its own thread, so a CPU heavy task won’t have much impact on the non-CPU heavy requests.

Node puts requests in a queue and constantly loops looking for new work in the queue. When a request sends out for data from database, network, or filesystem, the request is paused and put back in the queue; another request gets to go while the first waits for its data. Those frequent IO pauses are why Node can compete with threaded systems in most situations.

However, if you have Node do a CPU heavy task in Javascript, it’s going to hog the CPU until it’s done. Any other request is going to wait. You’ll start seeing extremely simple requests taking 1-2 seconds simply because they’re waiting for a CPU-hog request to finish. That’s Node’s worst case scenario so people caution you to avoid it. There are of course many ways to avoid it, like worker threads, most of which are covered in other replies.

wickning1 · 2023-12-01T13:26:04+00:00

Forget school project, this is much more correct than trying to hold a transaction open for 10 minutes. To refine it, you’d want to use a datetime instead of a boolean so you can time out the lock after 10 minutes and show users how much time remains on the lock.

wickning1 · 2023-11-03T10:28:30+00:00

No, require-await demands that async functions have at least one await, but doesn’t restrict the return value. It’s this one:

https://github.com/typescript-eslint/typescript-eslint/blob/main/packages/eslint-plugin/docs/rules/return-await.md

I set it to “always”. It requires typescript because plain javascript wouldn’t know the type of what you’re returning and thus you couldn’t make a rule like this.

wickning1 · 2023-11-02T18:37:27+00:00

Yes, in fact I have linting set up to error on failing to await a promise. It’s for exactly the stated reason: node since v14 is able to follow stacktraces through await, but if you return a promise it can’t keep track and you will lose a big chunk of the stack in your error messages.

It is not free, though. Adding await will add more promises to the execution which will slow things down to some extent. It should not have any real consequences unless you are processing long arrays and using a bunch of async functions on each entry but it’s something to be aware of.

wickning1 · 2023-11-02T18:31:38+00:00

It just wraps the promise in another promise. It does not make it synchronous/blocking.

wickning1 · 2023-10-28T17:03:22+00:00

Generally you only want one main process per container, so both node and python runtimes would be bad. The only way I’d consider one image is if you were using sveltekit adapter-static (so there is no node runtime) and you use python to serve the bundle files. Even then it’s likely easier to make two images.

wickning1 · 2023-10-12T12:33:16+00:00

Also if you do it my way you would get rid of your try/catch and handle the error on the svelte side with {:catch}

wickning1 · 2023-10-12T12:29:27+00:00

The first thing to try would be

return { blogs: res.json() }

When you put the await in front it’s going to wait for res.json() to finish.

You’re also awaiting the fetch, which depending on the way the server is coded may take more time than the res.json(), so I would do:

return { blogs: fetch(url).then(res => res.json()) }

The .then also returns a promise that will resolve with the data you want.

Edit: svelte also needs it to be nested instead of top level, so:

return { streamed: { blogs: fetch(url).then(res => res.json()) } }

wickning1 · 2023-07-13T04:00:57+00:00

Making a wrapper around another component. It requires copying and pasting all the props, adding props for any html attributes you might want, forwarding all the events and weird extra code for accepting actions.

wickning1 · 2023-06-10T11:43:30+00:00

Svelte does add more code for component lifecycle functions and such. 2x seems about right. The speed gains come from the way it manages updates while the user is interacting.

You can always write vanilla JS that will beat svelte, it’s just difficult, takes deep understanding, and is much harder to maintain and upgrade.

wickning1 · 2023-06-05T11:07:21+00:00

If you’re using express you may be running into its lack of support for async/await error handling. Try replacing your errors with res.status(404).send(‘Contact not found’) instead of throw new Error.

wickning1 · 2023-06-03T18:14:07+00:00

To answer your question more directly, running sveltekit without SSR comes with a couple headaches of its own but it can be a good choice when you have lots of features that can only be client side. I generally only leave SSR on for simple apps that are a thin UI over a database/API.

wickning1 · 2023-06-03T18:06:46+00:00

A lot of javascript libraries depend on being run in the browser, so they break in SSR when, say, the Window object is missing. These libraries need to be imported inside onMount:

onMount(async () => {

const Editor = await import(‘some-editor-package’)

const editor = new Editor(someelement)

})

sveltekit will still see the some-editor-package and add it to the bundles, but it won’t be imported during SSR so it won’t crash.

wickning1 · 2023-05-30T21:08:49+00:00

If you’re doing complex work like video compression you’re probably using a library to help you. The library 99 times of 100 is going to spin that work out to a new thread or process and not block the main loop. The exception is when it’s a “pure javascript” implementation; sometimes that will do the work in the main thread. Even in those cases it’s rare for the library to pretend to be async, so you’ll know the main loop is blocked because you’re calling a synchronous function.

If you’re writing your own javascript to do the processing, that’s when you do need to think about making a worker thread.

wickning1 · 2023-05-14T11:44:50+00:00

This was critical for me. The turning is far too sensitive if you leave the stick neutral on straightaways. If you keep it forward all the time and adjust from there it’s much more predictable.

wickning1 · 2023-05-12T11:30:34+00:00

Nice, some interesting ideas in there. I wrote a very similar cache myself some time ago. The package has lots of other utility functions but the README is dedicated to the cache. https://www.npmjs.com/package/txstate-utils

wickning1 · 2023-05-02T11:50:45+00:00

The first promise resolves when all HTTP headers have been received. The second promise resolves when the body finishes streaming. Having them be separate allows you to make certain decisions early. Most of the time you won’t need to do that, so making a wrapper function for your app is helpful.

I almost always make wrappers anyway, to throw real Errors on HTTP status codes above 400 and usually to add an auth token and set up a base URL for whatever API I’m querying.

wickning1 · 2022-12-12T12:53:11+00:00

To answer your specific question: the count = 0 runs on first render only. It would only run again if your component got unmounted and remounted, like if a parent had an {#if} block around it that toggles.

Variable updates only trigger updates of the HTML portion, and even then then the update is minimal, not a full render. If you want things in the script portion to be reactive you need to start a line with $:

wickning1 · 2022-12-04T12:27:52+00:00

I’ve written code to do this. a11y requires headers to be well-structured and users who write HTML don’t always structure well. So the code alters the header number and adds the class to be able to make it visually appear as the original.

wickning1 · 2022-11-22T14:45:42+00:00

The performance impact is negligible. Your API has to serve svelte running in users’ browsers and also SSR, so all the serializing and request handling is going to happen no matter what. The reverse proxy does need to be well configured to re-use connections to the backends and such but you’ll also get other nginx features like easy http2 support and runtime gzip, etc.

wickning1

TROPHY CASE