DEV Community: Toshita Pandey

Build 'Find My Photos' for Event Galleries with Amazon Rekognition and Node.js

Toshita Pandey — Sat, 14 Nov 2026 05:05:22 +0000

After a wedding, a conference or a marathon, the photographer uploads three thousand photos and every guest asks the same question: which ones am I in? Scrolling through a gallery that size is miserable. Uploading one selfie and getting back only your photos is a feature people actually remember.

This tutorial builds that feature with Amazon Rekognition's face collections, S3 and a small Node.js service. By the end you will have three pieces: indexing every face in a gallery, searching that index with a selfie, and the cost and privacy decisions you need to make before shipping it.

You will need an AWS account, Node.js 18 or later, and the AWS SDK for JavaScript v3.

npm install @aws-sdk/client-rekognition @aws-sdk/client-s3

How Rekognition face search works

Rekognition does not store your photos. When you index an image, it detects each face, turns it into a face vector, and stores that vector in a collection along with an id you choose. Later, you send a new image and ask, "which stored faces match this one?" It returns matching face ids with a similarity score.

So the design is simple:

One collection per event.
Index every gallery photo into it, tagging each face with the photo's key.
Search the collection with the guest's selfie and return the photo keys that matched.

Step 1: Create a collection per event

import {
  RekognitionClient,
  CreateCollectionCommand,
} from "@aws-sdk/client-rekognition";

const rek = new RekognitionClient({ region: "ap-south-1" });

export async function createEventCollection(eventId) {
  await rek.send(new CreateCollectionCommand({
    CollectionId: `event-${eventId}`,
  }));
}

A collection per event keeps searches fast and accurate, because a guest's selfie is only compared against faces from that event. It also makes deletion clean: when the event's retention period ends, you delete one collection.

Step 2: Index the gallery

Photos live in S3, so Rekognition can read them directly without you downloading anything.

import { IndexFacesCommand } from "@aws-sdk/client-rekognition";

export async function indexPhoto(eventId, bucket, key) {
  const res = await rek.send(new IndexFacesCommand({
    CollectionId: `event-${eventId}`,
    Image: { S3Object: { Bucket: bucket, Name: key } },
    ExternalImageId: key.replace(/[^a-zA-Z0-9_.\-:]/g, "_"),
    MaxFaces: 15,
    QualityFilter: "AUTO",
    DetectionAttributes: [],
  }));

  return res.FaceRecords.length;
}

A few choices here matter:

ExternalImageId is how you get from a matched face back to a photo. It only accepts a restricted character set, so sanitize the S3 key, or store a short id and keep a lookup table in your database.
MaxFaces caps how many faces are indexed per photo. Group shots can contain dozens of tiny background faces that are useless for search and cost money to store. Rekognition keeps the largest faces first.
QualityFilter: "AUTO" skips faces that are too blurry, dark or small to match reliably. Leave it on.

For a gallery of thousands of photos, do not index them in a loop inside a web request. Trigger indexing from an S3 upload event (S3 to SQS to a worker, or straight to Lambda), and keep concurrency modest to stay inside your account's Rekognition transactions-per-second limit.

Step 3: Search with a selfie

The guest's selfie never needs to touch S3. Send the bytes directly:

import { SearchFacesByImageCommand } from "@aws-sdk/client-rekognition";

export async function findMyPhotos(eventId, selfieBuffer) {
  const res = await rek.send(new SearchFacesByImageCommand({
    CollectionId: `event-${eventId}`,
    Image: { Bytes: selfieBuffer },
    FaceMatchThreshold: 90,
    MaxFaces: 500,
  }));

  const keys = new Set(
    res.FaceMatches.map((m) => m.Face.ExternalImageId)
  );
  return [...keys];
}

SearchFacesByImage finds the largest face in the selfie and compares it against the collection. One person can appear in many photos, so expect many matches and de-duplicate by photo.

Choosing the threshold. FaceMatchThreshold is the minimum similarity to return. At 80 you will catch more photos but start showing guests their cousin. At 95 you will miss profile shots and photos taken in poor light. For event galleries, 90 is a good starting point. Tune it against a real event before launch: take ten volunteers, count the photos each one should get, and compare.

Step 4: Handle the edge cases users will hit on day one

No face in the selfie. Rekognition throws an InvalidParameterException. Catch it and ask for a clearer, front-facing photo instead of returning an empty gallery.
Several people in the selfie. Only the largest face is searched. Say so in the upload screen.
Sunglasses, masks, heavy makeup. Matching drops sharply. Telling guests "best results with a clear, front-facing selfie" saves support messages.
Children's faces change fast and match less reliably across ages, which matters for school events.

Step 5: Cost

Rekognition charges per image processed for IndexFaces and SearchFacesByImage, plus a small monthly fee per thousand face vectors stored. Check the current price for your region, then estimate with real numbers:

A 3,000-photo event costs 3,000 index calls once.
Each guest search costs 1 call. 400 guests searching twice is 800 calls.
Storage is charged on the number of faces stored, which is why MaxFaces and the quality filter keep the bill down.

The biggest avoidable cost is re-indexing. Store which photos you have indexed so a retry or a redeploy does not process the whole gallery again.

Step 6: Privacy is part of the feature

Face vectors are biometric data, and in many places, including under India's DPDP Act and the EU's GDPR, that comes with real obligations. Build these in from the start:

Consent. Tell guests clearly that their selfie is used only to find their photos, and get an explicit yes before upload.
Do not keep selfies. Search with the bytes and discard them. Never index a guest's selfie into the collection.
Retention. Delete the event's collection when the gallery expires:

import { DeleteCollectionCommand } from "@aws-sdk/client-rekognition";

await rek.send(new DeleteCollectionCommand({
  CollectionId: `event-${eventId}`,
}));

Opt-out. Let a guest remove their face from the index. Search with their selfie, then call DeleteFacesCommand with the matched face ids.

What you have built

An indexing pipeline that turns a gallery into a searchable face collection, a single endpoint that turns a selfie into a personal gallery, and the threshold, cost and privacy decisions that make it safe to ship. The whole feature is under 100 lines of application code. Most of the work is in the decisions around it, which is exactly where it should be.

Finding and Killing N+1 Queries in a Rails API Before Your Users Notice

Toshita Pandey — Sat, 14 Nov 2026 05:05:10 +0000

A dashboard that loads in 300 ms on your laptop and 9 seconds in production usually has the same cause: an N+1 query. With ten rows of seed data it is invisible. With two thousand orders, each pulling its customer, its address and its line items, one request quietly becomes six thousand database round trips.

This tutorial walks through how to spot N+1 queries in a Rails API, the three loading strategies Active Record gives you and when each one is right, and how to stop new N+1s from reaching production at all.

You will need a Rails 7 app and PostgreSQL. The examples use a small order-dispatch domain, but the patterns apply to any app.

The setup

class Order < ApplicationRecord
  belongs_to :customer
  belongs_to :delivery_slot
  has_many :line_items
end

class Customer < ApplicationRecord
  has_many :orders
  has_one :address
end

And a controller that powers a dispatch screen:

class Api::OrdersController < ApplicationController
  def index
    orders = Order.where(status: "ready").order(:created_at).limit(200)

    render json: orders.map { |o|
      {
        id: o.id,
        customer: o.customer.name,
        city: o.customer.address.city,
        slot: o.delivery_slot.starts_at,
        items: o.line_items.sum(&:quantity)
      }
    }
  end
end

It reads cleanly. It also runs 1 query for the orders, then 200 for customers, 200 for addresses, 200 for slots and 200 for line items: 801 queries for one page.

Step 1: See it

The development log already tells you. Hit the endpoint and look for the same SELECT repeated with a different id each time:

Customer Load (0.3ms)  SELECT "customers".* FROM "customers" WHERE "customers"."id" = $1 LIMIT $2  [["id", 41], ["LIMIT", 1]]
Customer Load (0.2ms)  SELECT "customers".* FROM "customers" WHERE "customers"."id" = $1 LIMIT $2  [["id", 42], ["LIMIT", 1]]
...

Each query is fast. The problem is the count, and the network round trip each one costs in production, where the database is not on localhost.

For a less manual signal, add the Bullet gem in development:

# Gemfile
group :development, :test do
  gem "bullet"
end

# config/environments/development.rb
config.after_initialize do
  Bullet.enable = true
  Bullet.rails_logger = true
  Bullet.raise = false
end

Bullet logs each N+1 it detects, names the association, and tells you what to add. It also flags the opposite mistake: eager loading something you never use.

Step 2: Pick the right loading strategy

Active Record gives you three tools, and they are not interchangeable.

preload runs one extra query per association and stitches the results together in Ruby.

Order.where(status: "ready").preload(:customer, :line_items)
# SELECT "orders".* ... WHERE status = 'ready'
# SELECT "customers".* WHERE id IN (41, 42, ...)
# SELECT "line_items".* WHERE order_id IN (...)

Use it when you only need to read the associated records, not filter by them.

eager_load builds a single query with LEFT OUTER JOINs.

Order.eager_load(:customer).where(customers: { city: "Pune" })

Use it when the WHERE or ORDER BY depends on the association. Be careful with several has_many joins at once: the result set multiplies and can get slower than the N+1 you were fixing.

includes lets Rails choose. It behaves like preload unless your query references the joined table, then switches to eager_load. It is a sensible default, but when performance matters, being explicit makes the behaviour obvious to the next person reading the code.

For our endpoint, nothing filters on associations, so preload is the right call, including the nested address:

orders = Order.where(status: "ready")
              .order(:created_at)
              .limit(200)
              .preload(:delivery_slot, :line_items, customer: :address)

801 queries become 5.

Step 3: Stop computing in Ruby what the database can compute

o.line_items.sum(&:quantity) loads every line item just to add up one column. If that is all you need, ask the database:

totals = LineItem.where(order_id: orders.map(&:id))
                 .group(:order_id)
                 .sum(:quantity)
# => { 101 => 7, 102 => 3, ... }

Then look up totals[o.id] while rendering. One grouped query instead of loading thousands of rows into memory. For counts shown on every request, a counter_cache column is cheaper still.

Step 4: Make N+1s fail loudly

Fixing today's N+1 is half the job. The other half is making sure a new one cannot slip in with next week's feature.

Rails 6.1 added strict_loading. On a relation, it raises an error if any association is lazy-loaded:

orders = Order.strict_loading.where(status: "ready").preload(:customer)
orders.first.line_items
# => ActiveRecord::StrictLoadingViolationError

You can turn it on per model (self.strict_loading_by_default = true), or app-wide in development and test only:

# config/environments/test.rb
config.active_record.strict_loading_by_default = true

Now a request spec that touches an un-preloaded association fails in CI, long before it reaches production. In production itself, prefer logging over raising:

config.active_record.action_on_strict_loading_violation = :log

If you want detection on code paths your specs do not cover, run Bullet with Bullet.raise = true in the test environment as well.

Step 5: Verify with numbers

Do not trust the fix until you have measured it. A simple request spec can pin the query count:

it "loads the dispatch list in a fixed number of queries" do
  create_list(:order, 50, :with_items, status: "ready")

  queries = 0
  counter = ->(*) { queries += 1 }
  ActiveSupport::Notifications.subscribed(counter, "sql.active_record") do
    get "/api/orders"
  end

  expect(queries).to be <= 6
end

The test creates 50 orders, but the bound stays at 6. That is the point: the query count should not grow with the data.

A checklist for every new endpoint

Watch the development log for repeated SELECTs with changing ids.
Use preload for reading associations and eager_load only when you filter or sort on them.
Push sums, counts and grouping into SQL.
Keep strict_loading on in test so regressions fail in CI.
Pin the query count for your heaviest endpoints in a spec.

N+1 queries are rarely hard to fix. They are easy to miss, which is why the fix that matters most is the guardrail, not the preload.