feat: package likes #712

fatfingers23 · 2026-02-02T05:50:34Z

Our first social feature 🥳 This closes #79

Adds

Likes and unlikes
Generic cache that uses useStorage locally and redis in prod with set expire
Caches on the Constellation requests to return total counts faster since Constellation cannot show counts until it indexs it and that takes a few milliseconds to seconds depending on traffic
Some more helpers for working with atproto for checking for scopes, redirecting to login
Since we have added a scope the client needs to re-authenticate with the new one if a user was already logged in. Right now if it sees the logged in client does not have the new scope it directs to the PDS to reauth.
If the user likes without being logged in shows them the auth modal

Could be Improved

Not sure on the icon. Went with what I could find. I think a filled one may work better and an animation would be nice.
I think the caching layer I added for Likes could be abstracted out for better use with constellation. Constellation is the source of truth, but we need caching at times for faster feed back. Will have to think on how that will work
The redirect for scopes reauth could probably be improved to let the user know?
Auth always redirects back to main page. I think we could probably add an item to add some state where on redirect it loads the previous page

Concerns

Race conditions on likes and many users. Interested to see how it holds up with a lot of users at once. And just genreal race condtions of state
I'm not familiar with how Nuxt handles dependencies and not sure if the way I did the Redis connection will reuse client connections or open new ones?
I need to test more on error handling on everything and showing errors from the API. But this PR was getting really long in the tooth and I think some of that can be divided up for others who may not know atproto stuff but are much better with Nuxt than me

I probably won't be able to address feedback till tomorrow around 22:00 UTC

Zen.mp4

vercel · 2026-02-02T05:50:40Z

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
npmx.dev	Ready	Preview, Comment	Feb 3, 2026 4:32am

2 Skipped Deployments

Project	Deployment	Actions	Updated (UTC)
docs.npmx.dev	Ignored	Preview	Feb 3, 2026 4:32am
npmx-lunaria	Ignored		Feb 3, 2026 4:32am

Adebesin-Cell

Interesting PR!

Screen.Recording.2026-02-02.at.08.07.12.mov

Connecting with any of the socials results in a 404 error.

It attempts to navigate to: https://npmxdev-git-fork-fatfingers23-feat-likes-poetry.vercel.app/package/api/auth/atproto

Adebesin-Cell · 2026-02-02T07:19:43Z

app/pages/package/[...package].vue

+  if (user.value?.handle == null) {
+    authModal.open()
+  } else {
+    const result = likesData.value?.userHasLiked ? await unlikePackage() : await likePackage()


I think this approach could be improved a bit. Right now, the API request is sent immediately on every click.

It might be better to optimistically update the UI and debounce the request, so users can toggle the button freely and only the final state is sent to the API after a short delay. This would also allow us to provide immediate feedback that the action was registered, and handle request failures more gracefully (e.g., by rolling back the UI state or showing an error).

This would avoid unnecessary API calls and result in a smoother UX overall.

i agree, optimistic updates would fit nicely here and shouldn't be too difficult 👍

server/api/auth/social/like.delete.ts

wojtekmaj · 2026-02-02T09:53:24Z

server/api/social/like.post.ts

+  if (hasLiked) {
+    throw createError({
+      status: 400,
+      message: 'User has already liked the package',
+    })
+  }


Suggestion: silently succeed here instead of throwing an error.

Scenario: user likes the package twice with quirky internet connection and/or slower than usual response times.

Potential result on the UI: user see the like added then seeing the error message that liking has failed.

Been there, done that, with an app with more than 500,000 users :D

server/api/auth/social/like.post.ts

wojtekmaj · 2026-02-02T09:54:45Z

server/api/auth/social/like.post.ts

+  const body = await readBody<{ packageName: string }>(event)
+
+  if (!body.packageName) {
+    throw createError({
+      status: 400,
+      message: 'packageName is required',
+    })
+  }


Could leverage valibot here, this way you wouldn't have to resort to custom null checks to ensure that body is actually of type you expect it to be.

server/utils/atproto/utils/likes.ts

wojtekmaj · 2026-02-02T09:56:07Z

server/utils/atproto/utils/likes.ts

+   * Gets the definite answer if the user has liked a npm package. Either from the cache or the network
+   * @param packageName
+   * @param usersDid
+   * @returns


alexdln · 2026-02-02T12:24:06Z

server/api/social/like.delete.ts

How about making xrpc routes (sth like /xrpc/npmx.feed.like.create)?

Right now we're just using the the server side oauth client so if we made this endpoint an XRPC it wouldn't be quite correct since it uses the cookie for authentication. But there is a plan for some XRPC endpoints for other things just need to make a middleware for it to authenticate the service auth jwt

danielroe · 2026-02-02T13:08:37Z

nuxt.config.ts

        driver: 'fsLite',
        base: './.cache/atproto-oauth/session',
      },
+      'generic-cache': {


we probably also need to update modules/cache.ts to configure production redis

May have to leave that one to you 😅. Do you have something to read up on that? The local generic-cache defined there is used just locally for dev and then uses upstash redis like you did for the oauth session lock when in production if that makes a difference.

danielroe · 2026-02-02T13:09:09Z

server/utils/atproto/utils/likes.ts

@@ -0,0 +1,246 @@
+import { getCacheAdatper } from '../../cache'
+import { $nsid as likeNsid } from '#shared/types/lexicons/dev/npmx/feed/like.defs'
+import type { Backlink } from '~~/shared/utils/constellation'


here and some other places too:

Suggested change

import type { Backlink } from '~~/shared/utils/constellation'

import type { Backlink } from '#shared/utils/constellation'

danielroe · 2026-02-02T13:09:51Z

app/pages/package/[...package].vue

+const authModal = useModal('auth-modal')
+
+const { data: likesData } = useFetch(() => `/api/social/likes/${packageName.value}`, {
+  default: () => ({ totalLikes: 0, userHasLiked: false }),


this should probably be client-side only:

Suggested change

default: () => ({ totalLikes: 0, userHasLiked: false }),

default: () => ({ totalLikes: 0, userHasLiked: false }),

server: false,

43081j · 2026-02-02T15:07:46Z

app/composables/useAtproto.ts

+import type { PackageLikes } from '#server/utils/atproto/utils/likes'
+
+export async function authRedirect(identifier: string, create: boolean = false) {
+  let query = { handle: identifier } as {}


nit: this should be a type annotation rather than a cast, and shouldn't be {}

Suggested change

let query = { handle: identifier } as {}

let query: LocationQueryRaw = { handle: identifier }

or if we can't pull the exact type from vue-router, use Record<string, string> or something

43081j · 2026-02-02T15:09:59Z

app/composables/useAtproto.ts

+}
+
+export async function handleAuthError(e: unknown, userHandle?: string | null): Promise<never> {
+  const fetchError = e as FetchError


given we cast the error anyway at all call sites, can this function just accept a FetchError

otherwise we're doing an unsafe cast here, if anyone in future calls it from somewhere that doesn't only do a $fetch in the try block

43081j · 2026-02-02T15:12:15Z

app/composables/useAtproto.ts

  return { user, pending, logout }
 }
+
+export function useLikePackage(packageName: string) {


this file is becoming a bit of a "catch all" as the atproto features quickly expand. we should split them up i think, and have a app/composables/atproto/*, one file per composable.

that'll also help with organising the tests once they exist

its currently named after one of the composables, and the rest are just thrown into the mix

43081j · 2026-02-02T15:18:25Z

server/api/social/like.delete.ts

i think all the social/ endpoints need to live outside of the auth/ directory

they're not auth related, they just rely on a session.

auth/* anything to do with actually authenticating (login, logout, session, etc)

social/* anything to do with social, whether it requires a session or not

43081j · 2026-02-02T15:20:24Z

server/api/social/like.delete.ts

+    loggedInUsersDid,
+  )
+
+  if (getTheUsersLikedRecord) {


what if it isn't truthy? somehow

feels like something would have to be very wrong for that to happen, but we should log an error if so

Same. I think some of this like logic is kind of "let's see what all comes of it stage". Do we have something for logging or is it just console.error?

I think just a regular console.error for now

They should show up in the vercel logs

43081j · 2026-02-02T15:35:45Z

server/utils/cache.ts

+/**
+ * Local implmentation of a cache to be used during development
+ */
+export class StorageCacheAdapter implements CacheAdapter {


we should probably organise these into files:

server/utils/cache/adapter.ts - or shared.ts, holds the interface and any shared functions

server/utils/cache/local.ts - this StorageCacheAdapter

server/utils/cache/redis.ts

server/utils/cache/get.ts - not sure about this one, but just holds the main getCacheAdapter. can't live in the shared file since that'd cause circular imports

generally we should have one class per file imo

43081j · 2026-02-02T15:38:43Z

looking good!

i left a bunch of comments, mostly about code organisation though tbh

OrbisK · 2026-02-02T16:42:36Z

app/composables/useAtproto.ts

+  const data = ref<PackageLikes | null>(null)
+  const error = ref<Error | null>(null)
+  const pending = ref(false)


Suggested change

const data = ref<PackageLikes | null>(null)

const error = ref<Error | null>(null)

const pending = ref(false)

const data = shallowRef<PackageLikes | null>(null)

const error = shallowRef<Error | null>(null)

const pending = shallowRef(false)

By the way, I dont think we need these as composables. We almost never want the data from the ref itself, but rather the data returned by mutate. Just use $fetch where we need it or capsule just the $fetch in a util (IMO)

OrbisK · 2026-02-02T16:48:40Z

app/pages/package/[...package].vue

+  server: false,
+})
+
+const { mutate: likePackage } = useLikePackage(packageName.value)


passing packageName.value means, that when packageName updates the likePackage will like the initial value.

fatfingers23 · 2026-02-03T00:32:33Z

Thank you everyone for all the feedback! I think I have addressed everything brought up. About to log off for a few hours and going come back to do some final testing and I have 2 todos I want to hit

There's a like type I can share with the backend
Look into the user session being loaded when not needed

danielroe · 2026-02-03T00:40:25Z

it seems that likes aren't persisted, right? as in, when I navigate back to a package, it shows up as 'unliked'

fatfingers23 · 2026-02-03T00:45:37Z

it seems that likes aren't persisted, right? as in, when I navigate back to a package, it shows up as 'unliked'

They should be 😬. Was some heavy refactoring today so may be a bit of a bug. Going give it some more heavy testing when I come back. Is that on the preview URL? Should be loaded into cache for a while and once the cache expire it grabs from constellation if you have liked the packaged and the total count

fatfingers23 · 2026-02-03T04:40:14Z

I think I've taken troubleshooting about as far as I can on this side of the fence :/. I think someone with access to the Vercel service will need to look. All works locally both for upstash redis and useStorage

When you like it updates the record in your user repo but does not show, notice after the 10 minutes it shows you liked it. Which is about the time it takes for cache entry to expire. I am passing in a fresh instance of $fetch to the likes service I made so it should not be using the cachedFetch. On the cache side I tried removing upstash option and tried useStorage with both vercel-kv and vercel-runtime-cache. Same thing there.

Feels very much so like something in Vercel is caching web requests or that the cache backends may not be writing as expected. Any help would be greatly appreciated 🙏

vercel bot deployed to Preview – npmx.dev February 2, 2026 05:53 View deployment

fatfingers23 changed the title ~~Feat: Likes~~ feat: Likes Feb 2, 2026

vercel bot deployed to Preview – npmx.dev February 2, 2026 06:18 View deployment

fatfingers23 changed the title ~~feat: Likes~~ feat: package likes Feb 2, 2026

Adebesin-Cell reviewed Feb 2, 2026

View reviewed changes

wojtekmaj reviewed Feb 2, 2026

View reviewed changes

danielroe mentioned this pull request Feb 2, 2026

feat: bookmarks to pin packages #371

Draft

alexdln reviewed Feb 2, 2026

View reviewed changes

danielroe reviewed Feb 2, 2026

View reviewed changes

fatfingers23 force-pushed the feat/likes branch from 3807cb3 to 3b8d928 Compare February 2, 2026 13:52

vercel bot deployed to Preview – npmx.dev February 2, 2026 13:55 View deployment

vercel bot deployed to Preview – npmx.dev February 2, 2026 14:01 View deployment

43081j reviewed Feb 2, 2026

View reviewed changes

vercel bot deployed to Preview – npmx.dev February 2, 2026 16:10 View deployment

OrbisK reviewed Feb 2, 2026

View reviewed changes

fatfingers23 added 5 commits February 2, 2026 17:59

generic cache. local file in dev, redis in prod

4830f1d

Ideally should be the logic to read/set likes for npmx

5637945

made the get cache actually work

e708ea5

Should be proper read of likes on ui

551e01f

I think that's liking

85b73d8

fatfingers23 added 11 commits February 2, 2026 17:59

wip

26411a9

scope upgrade works

cd6207c

feels so close

784bcc7

rebase?

b3d3995

Hopefully resolves the tests?

a282987

Some small changes

53b3268

missed the server side one

a69048d

uses valibot to check body schema

f3d422e

moved useComposables

4cbfb05

moving the api around

5787fc3

Divided up the cache and changed keys a bit

a8f9a02

fatfingers23 force-pushed the feat/likes branch from 911bcd2 to a8f9a02 Compare February 2, 2026 23:59

vercel bot deployed to Preview – npmx.dev February 3, 2026 00:02 View deployment

I think this every thing expect to todos and more testing

202de5b

vercel bot deployed to Preview – npmx.dev February 3, 2026 00:33 View deployment

fatfingers23 added 2 commits February 2, 2026 21:45

tweaked some of the cache logic

8c6b799

Moved a type to be shared for api endpoints

934fd6d

vercel bot deployed to Preview – npmx.dev February 3, 2026 03:51 View deployment

vercel bot deployed to Preview – npmx.dev February 3, 2026 03:56 View deployment

fatfingers23 force-pushed the feat/likes branch from 6f240e2 to 1603f53 Compare February 3, 2026 04:02

vercel bot deployed to Preview – npmx.dev February 3, 2026 04:04 View deployment

fatfingers23 force-pushed the feat/likes branch from 1603f53 to f403b80 Compare February 3, 2026 04:29

vercel bot deployed to Preview – npmx.dev February 3, 2026 04:32 View deployment

fatfingers23 force-pushed the feat/likes branch from f403b80 to 934fd6d Compare February 3, 2026 04:33

	import type { Backlink } from '~~/shared/utils/constellation'
	import type { Backlink } from '#shared/utils/constellation'

	default: () => ({ totalLikes: 0, userHasLiked: false }),
	default: () => ({ totalLikes: 0, userHasLiked: false }),
	server: false,

	let query = { handle: identifier } as {}
	let query: LocationQueryRaw = { handle: identifier }

Uh oh!

feat: package likes #712

Are you sure you want to change the base?

feat: package likes #712

Conversation

fatfingers23 commented Feb 2, 2026 • edited by danielroe Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

vercel bot commented Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Adebesin-Cell left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

alexdln Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

43081j Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

43081j Feb 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

43081j commented Feb 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

fatfingers23 commented Feb 3, 2026

Uh oh!

danielroe commented Feb 3, 2026

Uh oh!

fatfingers23 commented Feb 3, 2026

Uh oh!

fatfingers23 commented Feb 3, 2026

Uh oh!

Reviewers

Assignees

Labels

fatfingers23 commented Feb 2, 2026 •

edited by danielroe

Loading

vercel bot commented Feb 2, 2026 •

edited

Loading

alexdln Feb 2, 2026 •

edited

Loading

43081j Feb 2, 2026 •

edited

Loading

43081j Feb 2, 2026 •

edited

Loading