DEV Community: Akbar Ali

Sign it without leaving the page

Akbar Ali — Sun, 13 Sep 2026 17:06:31 +0000

A guy sent me a screen recording last month. No message with it. Just the video.

It's his onboarding. Five steps, looks great, he clearly spent time on it. Then step six yanks the user out to our app. Our colours, our domain, our everything.

And you can see the poor user pause. Like, hold on, who am I signing with now?

He never said a word about it. Just the video. Somehow that's worse than a complaint.

Fine. We built an API. And an embed. Here's the whole thing.

The API just calls the same stuff the UI calls

This is the only decision I actually thought about.

export async function requireApiCaller(request: Request): Promise<ApiCaller> {
  // ...check the bearer key, hand back a `SessionUser`
}

See the return type? SessionUser. That's it, that's the whole idea.

Because createDocumentFromTemplate takes one. getTemplate takes one. The quota check takes one. They all already take one. So the API doesn't get to invent its own rules about who can touch what. It borrows the rules that were already sitting there.

Two copies of "is this person allowed" is two chances to screw it up. And they always drift. You look away for a week and they're different.

Endpoints, nothing exciting:

GET  /v1/templates
POST /v1/templates/:id/send
GET  /v1/documents
GET  /v1/documents/:id
GET  /v1/documents/:id/file

The list uses a cursor instead of ?page=2. Had to. It's sorted by updated_at and that thing moves constantly, every time somebody opens a document or signs or comments. So rows keep jumping around. Page through that with offsets and you'll skip stuff, silently, and never know. Grabbing one extra row tells you if there's more without a count query.

Errors look the same everywhere:

{
  "error": {
    "code": "quota_exceeded",
    "message": "You have sent 10 of 10 documents this month.",
    "quota": { "used": 10, "limit": 10, "resets_at": "2026-10-01T00:00:00.000Z" }
  }
}

Check code, not the message. The message is for you at 2am with your face in the logs (or me, let's be honest).

You know what actually ate the most time? Making sure you never get HTML back. React Router throws Responses all over. A 404 here, a 429 from the rate limiter there, and a redirect that shoves the browser at the marketing page. All perfectly fine when a human is looking at it. All completely useless to your res.json(). So everything goes through one wrapper that cleans it up, and that redirect becomes a 401, because your script does not have a session to go fix, does it.

The embed, and the thing that nearly bit me

Send with embed: true, we skip the emails entirely, you get a URL per person:

{
  "embed": {
    "expires_in": 1800,
    "sessions": [
      { "recipient_id": "rcp_b4c1...", "url": "https://putmysign.com/embed/sign/GfT9…" }
    ]
  }
}

Shove it in an iframe yourself if you want. Or use the script, which is honestly just an iframe and a message listener, that's it:

<div id="sign" style="height: 800px"></div>

<script src="https://putmysign.com/embed.js"></script>
<script>
  Putmysign.mount("#sign", {
    url: session.url,
    onSigned:   (e) => finish(e.documentId),
    onDeclined: (e) => bail(e.documentId),
  });
</script>

mount hands you back a destroy(). Please call it. Swap that container out in a SPA without it and the old listener is still hanging around, so next time every single handler fires twice and you sit there going "why did it save twice". I found this out the way everybody finds this out.

Ok now the good part.

Our normal signing page, the one from the email, cannot be put in a frame by anyone. frame-ancestors 'none'. Nobody. The only reason the embed one can be framed is that a customer told us, with a real authenticated key, which of their own domains to trust.

So the URL you get isn't the actual signing token. It's a little sealed box around it:

interface EmbedPayload {
  t: string;    // the real signing token
  k: string;    // which API key made this
  exp: number;  // epoch ms
}

That k is doing all the work. Opening the box is how the route finds out which origins are allowed to frame the page. So the CSP gets built fresh on every request off the key, not parked in some static header.

And if your key has no origins set? You get 'none'. It renders nowhere. Blank box.

Felt kind of mean when I wrote it. Some dev wires it all up, gets nothing, curses my name.

But the other way is defaulting to open, and defaulting to open means somebody's half finished Friday afternoon setup is now a signing page that literally any website can wrap in a frame and aim at their own users. Nah. Blank box it is.

If a default is going to fail, make it fail loud. The quiet ones become bugs nobody ever reports.

The 30 minute expiry is the same paranoia from the other direction. An emailed link has to survive a week because people open those things next Tuesday. But that's the worst possible property for something you hand to somebody else's webpage, where it just sits in their DOM and their logs and their analytics the entire time it's valid. So the expiry lives inside the sealed box. Can't stretch it by messing with something next to it. No table, no cleanup job, nothing to forget about.

Webhooks, because the iframe only sees its own little world

onSigned means that one person signed. Cool. Three other people might still owe you a signature.

For "ok it's actually done now", you want these:

document.sent · recipient.viewed · recipient.signed
recipient.declined · recipient.commented · document.completed

Signed t=<timestamp>,v1=<hmac>, five tries over about a day, at least once delivery. At least once, meaning yes, the same event will show up twice sometimes. Check the id, throw away the repeat.

There's a signature checker right on the docs page that runs the actual function our dispatcher signs with. Paste in a real delivery and you'll know in ten seconds if it's your code or mine.

It's raw body vs parsed body. I'm telling you now. It's always raw body vs parsed body.

That's it really. Docs at putmysign.com/docs/api, keys and webhooks live under Developers, and test keys do the full run without emailing anybody or charging you.

The bit I'm still chewing on is that origins default. Have you shipped an embed thing like this? Did you make people set up the allowlist before anything works, or let them start wide open and nag them later? And did anyone actually ever go back and fix it?

True or false?

Akbar Ali — Fri, 04 Sep 2026 15:54:06 +0000

Someone emailed me a signed contract, and I forwarded it to myself to test something.

Outlook did what Outlook does. Re-saved the attachment on the way through. Same contract, same signatures, same everything a human would care about.

Different bytes.

My verifier, which at that point returned a boolean, looked at it and said invalid.

That's the moment I realised I had built a liar (a very confident one, which is worse).

The thing I got wrong

I'm building Putmysign, a small app for sending PDFs out and collecting signatures. At the end of it there's a /verify page: you drop a signed PDF on it, and it tells you whether the thing in your hands is real.

The obvious design is a checkbox. Valid or not valid. Green or red.

The obvious design is wrong, and it took a mail client to teach me why.

Because "these are not the exact bytes I produced" and "this is a forgery" are not the same sentence. I had been printing the second one every time I meant the first.

If you tell someone holding a perfectly real contract that it's fake, you haven't built a security feature. You've built a way to ruin somebody's Tuesday.

Two checks, not one

So the verdict comes from two completely independent checks, which fail for completely different reasons.

One. Does the SHA-256 of this file match a document we finalized? That's the strongest answer there is: these are the exact bytes we made. This is the only check that needs a database row.

Two. Is the certificate inside the file authentically ours?

That second one needs explaining. When a document is finalized, I stamp a small HMAC-signed payload into the PDF's Keywords metadata. Who signed, when, the hash of the original, the document id. Base64url, because Keywords is a flat PDF string and JSON's quotes and parentheses have to be escaped correctly by every reader that ever touches the file (one opaque token has nothing to get wrong).

export const MANIFEST_PREFIX = "putmysign-certificate-v1:";

export function encodeManifest(manifest: CertificateManifest, signature?: string) {
  const payload = manifestPayload(manifest);
  return `${MANIFEST_PREFIX}${payload}${signature ? `.${signature}` : ""}`;
}

The point of that: the document can speak for itself.

My retention job deletes files on a schedule, by design. Someone downgrades, records age out, a mail client re-saves an attachment. In every one of those cases the byte-for-byte lookup finds nothing, and the only thing left in the world that can still say we issued this, for this document, with these signers is the certificate riding along inside the file.

A verifier that only recognises documents you still hold a row for will fail on everything you promised to delete.

Five outcomes

So there are five, strongest first:

verified: the bytes match a document we finalized. Nothing has changed.
certified: the certificate is authentically ours, but the bytes aren't the ones we made. The signings happened. This particular file just isn't the artifact we issued. This is my Outlook contract.
self-signed: signed with the free browser-only tool. Nothing witnessed it, so the file's account of itself is all there is.
tampered: carries a certificate that does not check out.
unknown: no certificate, no matching record. Not one of ours.

The middle three are the whole post. Collapsing any of them into "invalid" would be the wrong answer more often than the right one, and I have the receipts (one receipt, from my own inbox, but still).

There's a smaller decision in there I'm oddly proud of. A certificate with no signature at all is reported as unknown, not tampered, because that's what a document looks like when it was finalized while no signing key was configured. A signature that's present and wrong is a different matter entirely. Saying "forged" to someone holding a real contract is the worst mistake this endpoint could possibly make, so it only says it when it's actually sure.

if (!signature) return { verdict: "unknown" };
if (!certificateIsAuthentic(payload, signature)) return { verdict: "tampered" };
return { verdict: "certified" };

The self-signed one

The free tool on the landing page signs a PDF entirely in the browser. The file never touches my server. That's the promise, and I'm not breaking it to make my verifier's life easier.

Which means: nothing witnessed it. Nothing could have witnessed it.

I still write a certificate into it. Unsigned, marked kind: "self", and worth exactly nothing as proof.

But it means /verify can say "this was signed with Putmysign, by this name, on this date, and we were deliberately not involved", instead of reporting my own product's output as a stranger.

A claim about a file isn't proof, but it beats a shrug.

(The verify page keeps the same promise, by the way. Your PDF is read with File.arrayBuffer() and never uploaded. What goes to the server is a 32-byte one-way digest and the certificate that was already in the file. Neither of those is content.)

The bit I'd do differently

HMAC was the cheap choice. One environment variable, no key distribution, no ceremony.

The cost is that the check has to run on my server. A sceptical counterparty, the exact person this feature exists for, cannot verify a certificate without asking me to confirm my own honesty, which is a hilarious thing to build into a trust product.

A public key fixes it. That's the better end state and I haven't done it yet (I will, right after the eleven other things).

Anyway. My actual take, one sentence:

A verifier that can only say yes or no will spend most of its life saying the wrong one.

Have you had a boolean like this in your own code, a flag that quietly collapsed two very different failures into one answer? I'd genuinely like to hear about it, mostly so I feel less alone about the mail client thing.

PDF Rendering in browsers

Akbar Ali — Mon, 31 Aug 2026 14:02:55 +0000

Why was the certificate blank?

A user sent me a screenshot of a signed document.

The signature was there. The certificate page behind it was empty. Not broken, not garbled. Just a clean white page with nothing on it, like the PDF gave up halfway through.

Worked fine on my machine, obviously. It always does.

How the preview works

You can't hand a browser a raw PDF and call it a day (not when the file is private and every page needs an access check). So each page gets rendered on the server into a JPEG.

pdftoppm does the render. One page, scaled to a fixed width, quality 82, into a temp dir that gets torn down in a finally block. The result goes into object storage under a cache key, and that write is best effort. If the cache write fails you still get your page.

const cached = await getObject(cacheKey);
if (cached) return cached;

const pdf = await fetchPdfAsset(path);
const jpeg = await renderPageWithPoppler(pdf, page);

Simple enough. That part was never the problem.

The problem was Alpine

PDFs have fourteen "base" fonts. Helvetica, Times, Courier and friends. The spec says every viewer must have them, so writing tools don't bother embedding them. Why ship a font everyone already has?

Everyone, except a node:24-alpine container.

Alpine ships with basically no fonts (that's the whole point of Alpine). So pdftoppm opens the PDF, reads "draw this in Helvetica", goes looking for something to substitute with, finds absolutely nothing, and draws nothing at all. Correctly, by its own logic.

No error. No warning. Exit code 0. A perfectly successful render of a blank page.

That's the worst kind of bug. It didn't fail. It agreed with me.

The fix is one line in the Dockerfile: install Liberation fonts. They're metric compatible with the base-14 families, so nothing shifts around.

The other font problem

While I was in there I found something worse, and this one didn't crash either.

The app shows typed signatures in Dancing Script, the loopy face that reads like handwriting. The generated PDF was drawing them in Helvetica Oblique.

So you type your name, watch it appear in nice script, click sign, download the file, and get slanted Helvetica. Not wrong exactly. Just not what you agreed to.

For an app whose entire pitch is "the document is exactly what you saw", that's not a cosmetic bug.
So Dancing Script got vendored into the repo and embedded straight into the PDF with fontkit, subsetted so only the glyphs you actually used come along for the ride.

export async function embedSignatureFont(pdf: PDFDocument): Promise<PDFFont> {
  pdf.registerFontkit(fontkit);
  return pdf.embedFont(bytes, { subset: true });
}

The font is inlined as a data URI at build time instead of read off disk. The production image only copies build/, so a runtime file read would have found nothing (the blank page bug again, wearing a different hat).
Embedding fixed both ends at once. The download matches the screen now, and the renderer doesn't need the font installed anywhere, because the font is sitting inside the file.

What I actually learned

Fonts are a deployment concern. I'd have filed them under "design" on any list you handed me, right up until a container with no fonts quietly produced legal documents with nothing written on them.

And a renderer that exits 0 will lie to you. Check the pixels, not the exit code.

The certificate page got rebuilt in the same pass. Three big signer cards became compact rows, seven to a page, readable timestamps, a pointer to /verify at the bottom. It's the page almost nobody opens, right until the one day somebody really needs it.

That's most of what building Putmysign has been, honestly. Polishing things people will hopefully never have to look at.

Anyone else been bitten by a slim base image quietly dropping something? I want to hear the worse ones.

I built an e-signature app that charges for what actually costs money

Akbar Ali — Sat, 22 Aug 2026 14:06:54 +0000

The bill that made no sense

A signature is about 400 bytes of JSON and a hash.

Every big e-signature product will charge you somewhere between $1 and $4 for each document you send. They call it an "envelope". On top of that you pay per seat, so every colleague who needs to send a contract is another line on the invoice. Run out of envelopes on the 22nd of the month and your deal waits until the 1st. I have watched a real contract sit still because a counter hit zero.

So I looked at what an e-signature product actually costs to run, and priced Putmysign around that.

What actually costs money

Storage is the obvious guess, and it is wrong. Uploads are capped at 5 MB. A heavy account sends a few hundred documents a year, which is a few gigabytes. At object storage prices that is cents. Per year.

The cost that actually grows with use is sending a document: an email to every recipient, reminders, and the bandwidth when they open the PDF. Fractions of a cent each time, but it is the one number that scales.

It is also the number customers already think in. Nobody knows how many gigabytes they store. Everyone knows roughly how many contracts they send.

So Putmysign meters exactly one thing, documents sent per month:

Free: 10 documents a month, up to 10 recipients each, signing links live up to 30 days
Pro, $19/month: 100 documents a month, up to 50 recipients each, links live up to a year, automatic reminders
Every plan: files and audit trail kept forever, unlimited signatures, unlimited reusable templates, no seats, recipients never make an account

Drafts don't count. The allowance resets on the 1st of the month (UTC), not on a rolling 30-day window, so you always know when it comes back.

On Pro that works out to 19 cents a document, against $1 to $4 elsewhere.

That one pricing decision shaped most of the technical choices underneath. That is the interesting part.

1. Keep the file, and keep the proof

Every signed PDF is kept. Storage is cheap, so there is no reason to make anyone think about retention.

The file alone is not proof, though. So every document records two hashes:

const originalHash = sha256(originalBytes);
// signatures applied, certificate page added
const finalHash = sha256(finalBytes);

The original is hashed on upload, the final one after the signatures and the audit certificate page are applied. If you download your copy, you can hash it and check it against a record I cannot quietly change. Your proof does not depend on trusting my storage.

2. Recipients never make an account

A signup wall in the middle of someone else's contract is the biggest reason paperwork stalls. It mostly exists so vendors can count seats.

So the signing link is the login. It is an HMAC over the document and the recipient, built from a server-only secret. Only the hash of the token is stored:

const secret = process.env.SIGNING_TOKEN_SECRET ?? process.env.SESSION_SECRET;
if (secret.length < 32) throw new Error("must be at least 32 characters");
return createHash("sha256").update(token).digest("hex");

Store the hash, not the token. If my database leaks tomorrow, nobody gets a working signing link out of it. Same idea as hashing passwords, applied to a URL.

3. Whatever you meter, check what slips past it

If you count documents, a single document with unlimited recipients is an unmetered mailing list. Someone on the free plan sent one document to 664 addresses, every one of them an email from my domain.

So there is a per-document recipient cap: 10 on Free, 50 on Pro. Real approval rounds rarely go past a handful of people, and the cap closes the gap the meter left open.

Any usage-based price has a hole like this. Find it before someone else does.

4. One row per document

A signing session is a burst of tiny writes. Opened. Viewed page 3. Signed field 2. IP recorded. All of it against one document that is only ever read as a whole.

Splitting that across six tables buys me joins I never run. So each document is one JSONB column holding everything, with the fields I actually filter on copied out into real indexed columns: owner, status, updated date. A GIN index on the JSON handles signing-link and "shared with me" lookups.

The real risk with a single row is two people signing at the same moment. Last write wins, one signature disappears. I fixed it the boring way, with SELECT ... FOR UPDATE inside a transaction.

Postgres has been a fine document database for years, and it still hands you row locks when you need them.

5. Thumbnails without a thumbnail service

Page previews come from pdftoppm, part of poppler. It is a 25 year old C program. I shell out to it, render the page when someone asks for it, and cache the image back into the bucket next to the PDF.

No render service, no queue, no third party API with a per page price on it. When your price is per document, anything that adds a per-page cost underneath eats straight into it.

The stack, quickly

React Router 7, TypeScript, Postgres with Prisma, any S3 compatible bucket (MinIO locally, so the whole thing runs on a laptop with one docker compose up), Firebase Auth for owners only, Resend for email with bounce handling, Paddle for billing.

Nothing fancy. The interesting decisions are all about what is missing.

Things worth stealing

You do not have to care about e-signatures to use any of this:

Charge for what actually costs you money, and check the bill before deciding what that is. It is often not what you'd guess.
Meter the unit customers already think in. Documents sent, not gigabytes.
Whatever you meter, look for what slips past it. Count documents and someone will put 664 people on one.
Keep checkable proof, not just the file. Hashes are tiny and they make your records verifiable without trusting you.
A signup wall in someone else's workflow is a tax on your own customer. They pay it in deals that stall.
JSONB, plus a few copied-out indexed columns, plus FOR UPDATE covers a lot of "we need a document database" situations.

It is live at putmysign.com. Free tier, no card. Upload a PDF you already have and send it to someone who will never make an account.

If you can break the signing link logic, I would genuinely like to hear about it in the comments.

What is the most backwards pricing unit you have run into? I will start: per seat pricing on a read only viewer.

Translate apps in one command

Akbar Ali — Wed, 13 Aug 2025 06:04:17 +0000

Check out the package first:
@pulimoodan/localiser

Features

Translate i18n locales with one command
Translate only required languages (only the ones we changed)
Translate only the required namespaces (yeah, same as above: only the ones we changed)
Translate any language, with any iso codes: like pt or pt-BR (because, we're using AI. Not a flex btw)

Concerns to be addressed

Optimise the Open AI requests with the only the required keys, instead of whole json file
An init command to generate the project configuration
Doesn't support different types of folder structures, only: lang/namespace.json
Configure different types of models

Contribute (or detract)

If you've got an idea to improve or play around with this:

Fork the repo
Work your magic, cook well
Slam a PR
And I will think about it (kidding, we need those contributions)

Link to GitHub repo: Localiser

Code pollution

Akbar Ali — Sun, 03 Aug 2025 06:04:11 +0000

The list of PRs to be reviewed, getting long and long each day in numbers.

The dashboard, looking at me with that weird devil laugh every time I open the Github.

It's not me, being lazy and stubborn to keep reviewing everything consistently (maybe).

It's some dry dreaded lines of waste, of code changes being written in those files that make the stubborn I am.

The AI slop, waiting on those changes to get refuge in our codebases are becoming a nightmare day by day.

The Cause

Developers being lazy to write code. They're not here for passion (or they lost it), just for money.
They don't care about what they (or the agent) write, they're just focused on completing the task due to work pressure.
They're not good at this, maybe they're some product managers who focus on the app but not technology under the hood.
The FOMO of using AI to get tasks move quickly and wasting time (most of the medias are responsible for this, the me before a few months would assure this).
People being developers instead of poets (The art of beautiful code is long gone).

The Solution

Review PRs effectively (I used to rewrite some my own, instead of educating the PR author)
Talk to your teammates and motivate them (there had been one of my friends who quoted about a fellow's code: I got goosebumps reading it)
As a developer, think about a problem before asking it to the agent. Share your thoughts and get feedback.
Try to use AI for automation, not to be dumb day by day (The ability to think will fade away, aware of that).
Proofread the code written by the agent, and instruct how to make it well written.
Sometimes writing with your own hands feels like greatness being achieved (don't listen to the FOMO creators).
Learn to code or learn to prompt (be good at it, sometimes it is easier to express in code than in natural language).

I could have become a project manager 20 years ago if I didn’t care to write code myself and I just wanted outcomes.
-- DHH

Common JS library import in ES Module

Akbar Ali — Mon, 21 Jul 2025 07:15:13 +0000

Spent a lot of time debugging this.

I was using react color library from NPM in a project and my project was in ES module scope.

Problem

import reactColor from "react-color";

TypeError: Cannot read properties of undefined (reading 'displayName')

Fix

import * as reactColor from "react-color";

const { SketchPicker } = reactColor;

Prisma: Could not parse schema engine response

Akbar Ali — Thu, 19 Dec 2024 08:13:48 +0000

Problem

Recently encountered this error while deploying our app to production:

Error: Could not parse schema engine response: SyntaxError: Unexpected token E in JSON at position 0

There is no more explanation why this occurred, just this line. In the recent merge commit we had only changed a couple of locale keywords, that's it.

Figuring out

Searched all over the internet and found nothing.

Then, I noticed a warning a couple lines of above the error, like this:

prisma:warn Prisma failed to detect the libssl/openssl version to use, and may not work as expected. Defaulting to "openssl-1.1.x".

I searched about this on GitHub and found this:
Prisma fails to find openssl 3.0.x on new bookworm

I realised that for some reasons, the new version of the alpine docker image I was using doesn't come with the openssl package - Which was required for Prisma engine.

Solution

The issue discussion I shared above said that use node version 18.5.something and we can temporarily resolve this or use a different docker image.

But, I don't have to use a different version of node and make conflicts to other packages.

So, I should install the package manually.

This is the docker image I was using:

FROM node:18-alpine

I added these lines to it:

# install openssl
RUN apk update && apk upgrade
RUN apk add --no-cache openssl

And, that solved the problem.

Importing from GitLab to GitHub

Akbar Ali — Fri, 17 May 2024 07:19:17 +0000

In GitLab:

Profile -> Preferences -> Access tokens -> Add new token
Name it, select all permission that apply, click create.
Now you get a token, copy it.

In GitHub

Create new repository.
On the create page, right below the heading there is a text saying import a repository.
Click it, copy the repo url from Gitlab and paste it there.
Add your gitlab username and the access token.
Name the repository.
Click begin import.
It will take some time, sit tight.

Object memory reference in JS

Akbar Ali — Tue, 12 Mar 2024 20:05:52 +0000

const person1 = {
    name: "Alex",
    address: "Toronto"
}

const person2 = person1;
person2.name = "John";

console.log(person1);

What would be the output of the above code?

Does that look like this:

{
    name: "Alex",
    address: "Toronto"
}

You're wrong. It would look like this:

{
    name: "John",
    address: "Toronto"
}

Yes, that's the correct output. But that was not what we ought to do. We need the name of the person1 to stay like whatever it was before. We changed the name of person2.

Then, where did it go wrong?

The problem is with the JavaScript's object memory reference. We only assigned the person1 variable to the person2 variable. Javascript keeps the memory reference of the variable in the place for both of them. That's why when we changed the name of person2, it affected person1.

How to overcome this bug?

Even, I had spent a full day debugging a commercial app and banged my keyboards due to frustration to find out it's just a memory reference bug.

Here's a solution:
Spread operator

const person1 = {
    name: "Alex",
    address: "Toronto"
}

const person2 = {...person1};
person2.name = "John";

console.log(person1);

Here, we are spreading the person1 variable to create a new one. Now it would work fine as we expected. But, it has an exception.

What if our code was like this:

const person1 = {
    name: {
        first: "Alex",
        last: "Telles"
    },
    address: "Toronto"
}

const person2 = {...person1};
person2.name.first = "John";

console.log(person1);

This is our expected output:

{
    name: {
        first: "Alex",
        last: "Telles"
    },
    address: "Toronto"
}

But, what we get:

{
    name: {
        first: "John",
        last: "Telles"
    },
    address: "Toronto"
}

The person1 also got changed even if we used spread operation to create a new object.

This is because, the spread operator only affects the first level properties and it won't clone the deep level key values. So, the first in the name property still has the memory reference to its parent.

Here is the solution to deep clone JS objects:

JSON stringify

const person2 = JSON.parse(JSON.stringify(person1));

Converting the object to string and then into JSON resolves the problem.

But still, we have a problem.

function test() { console.log("This is a Test") }

const person1 = {
  name: {
    first: "Alex",
    last: "Telles"
  },
  f: test,
  address: "Toronto"
}
person1.f()

const person2 = JSON.parse(JSON.stringify(person1));

person2.f()

This code will return an error saying TypeError: person2.f is not a function. This is because, we had a memory reference to the function in the parent object and when we converted it into string for cloning, that reference got lost.

thanks to @efpage for the feedback.

So, there are some ways to overcome this:

Using loadash

const _ = require('lodash');

function test() { console.log("This is a Test") }

const person1 = {
  name: {
    first: "Alex",
    last: "Telles"
  },
  f: test,
  address: "XYZ"
}

const person2 = _.cloneDeep(person1);
person2.f();

lodash library has a cloneDeep function which will help to deep clone object with all memory reference.

Structured clone function

const person2 = structuredClone(person1);

The structuredClone function will be available in the new version of JavaScript and it will deep copy the parent object.

Hope this articles helped you. Drop your feedbacks in comments.

This or that?

Akbar Ali — Wed, 06 Dec 2023 09:07:49 +0000

Have you ever ended up in a situation where you have many images of something but hard to choose the perfect one?

Like, if we have two images, it's easy to choose the best one. But when it's 5 or 10 or 50 images, the process becomes more difficult.

The solution is to take the first two pictures, find the best one. Now take the third picture and cross check with the best one and it continues.

I made a simple web app which helps to do this. Simply, we upload a bunch of images and click start. The program shows us a pair of images and we have to choose the best one. It repeats until the best one finally being found.

Dot-poll is a simple web app with basic html and js which delivers this solution. See the live version here: Demo

There is a lot of features we can add to this app and I am looking for developers who are interested working on this. Leave a comment or a pull request if you find this worth a try.

An alternative for Render?

Akbar Ali — Tue, 05 Dec 2023 09:17:32 +0000

I have been using Render for hosting my side projects. It's flawless, easy to connect GitHub projects and deploy with just a click.

I switched to render because I was fed up with the hard and weird deployment process of Heroku. Render has some amazing features and easy to use.

But recently, I faced this problem of services getting suspended if they are in free tier. Somehow, it's hard to afford some side projects in a paid plan. I share my side projects with my friends and they say it's not loading. I ask them to wait for couple of minutes and they usually stop trying after some time.

Currently, I am searching for a better alternative which provide full time serving of the web app we deploy. I really liked the workflow of Render and hope to find something similar.