DEV Community: Faithful Ojebiyi

Building Production AI Agents with Mastra, NestJS, Inngest, and Next.js

Faithful Ojebiyi — Wed, 15 Jul 2026 18:31:15 +0000

Lessons from shipping agents in two real products — a legal AI platform and a carbon data platform.

Everyone can build an AI demo in a weekend. The hard part starts when the agent has to survive production: a run that takes four minutes and can't die when a pod restarts, a tool call that mutates customer data and needs a human to say "yes" first, a stream of tokens that has to reach a browser through two services and a queue.

Over the past months I've built AI agents into two production systems with the same stack:

Gavely — a legal AI platform where agents plan multi-step document reviews, extract structured data from contracts into spreadsheet-like grids, and draft documents.
CarbonMe — a carbon data platform where an agent team profiles raw warehouse tables, authors SQL transforms, and builds a semantic layer — with a human approving every materializ ation.

Both run on the same four pillars: NestJS (structure), Mastra (agents), Inngest (durability), and Next.js (the UI). Here's how the pieces fit, and what I'd tell anyone
starting the same journey.

The architecture in one paragraph

Two NestJS apps in a monorepo: an api app that handles HTTP and an isolated worker app that runs long agent jobs. They never import each other — they communicate exclusively th
rough Inngest events with zod-typed payloads. Mastra hosts the agents (model config, tools, memory) as a shared library both apps can use. The Next.js dashboard talks to the api ov
er REST and consumes agent progress over SSE. Postgres holds business data via Prisma, and Mastra keeps its own memory tables in a separate schema so the two never fight over migration
s.

Next.js ──HTTP/SSE──▶ NestJS api ──Inngest events──▶ NestJS worker
                          │                              │
                          └────────── Mastra agents ─────┘
                                        │
                              Postgres (+ separate
                               mastra schema)

Why split api and worker at all? Because agent runs are minutes, not milliseconds. You don't want a 4-minute LLM loop holding an HTTP connection open, blocking your event loop, or dy
ing silently when you deploy. The api's job is to accept the request, write a row, publish an event, and return in 50ms. The worker's job is to do the slow, failure-prone thing — with
retries.

1. Agents are code, and they live in a library

Mastra's core primitive is the Agent: a model, instructions, tools, and oplick for me is that everything can be dynamic per request:

export const legalAssistantAgent = new Agent({
  id: 'legal-assistant',
  // instructions loaded from DB — base prompt + the workflow's skill file
  instructions: async ({ requestContext }) => {
    const workflow = await loadWorkflow(requestContext.get('workflowId'));
    return withWorkflow(BASE_PROMPT, workflow?.title, workflow?.promptMd);
  },
  model: ({ requestContext }) => resolveModel(requestContext.get('model')),
  tools: ({ requestContext }) => ({ /* conditionally registered tools */ }),
});

Instructions come from the database (so product can iterate on prompts without a deploy), the model is selectable per request, and tools appear only when their backing service is wiredup.

For bigger jobs, Mastra's supervisor pattern shines. In CarbonMe, a "semantic manager" agent delegates to three focused sub-agents instead of one god-agent with 12 tools:

return new Agent({
  id: 'semantic',
  instructions: `Plan the work and DELEGATE to your sub-agents:
    - data: profile tables and AUTHOR cleaning transforms
    - modeling: define the semantic model (dimensions + metrics)
    - query: answer questions against PUBLISHED models`,
  model: 'anthropic/claude-sonnet-4-6',
  memory: new Memory({ options: { lastMessages: 20 } }),
  agents: { data, modeling, query },
});

Small tool sets per agent means better tool selection, cheaper context, and instructions that actually fit in the model's head.

2. Never let the model tell you who the user is

This is the security pattern I'd put on a billboard. Multi-tenant + LLM = a model that can be prompt-injected into asking for someone else's data. The fix: tenant identity never comes from model input. It flows from the authenticated HTTP request, through NestJS's async local storage, into Mastra's RequestContext — and tools read it from there:

// in the CQRS command handler (api)
const requestContext = new RequestContext([
  ['organizationId', this.als.ctx.get('organizationId')],
  ['projectId', projectId],
  ['userId', userId],
]);
await agent.stream(message, { requestContext, memory: { thread: conversationId, resource: userId } });

// in every tool
execute: async (inputData, ctx) => {
  const { organizationId, projectId } = requireTenant(ctx); // from context, NEVER from input
  return runner.run({ organizationId, projectId, query: Schema.parse(inputData) });
}

The model decides what to do; the platform decides on whose behalf. Those must never mix.

3. Inngest makes agent runs durable — and CQRS keeps them testable

An agent run in Gavely is a state machine: PENDING → PLANNING → AWAITING_APPROVAL → RUNNING → DONE, with pauses for human input. The api starts it with three lines of intent:

const run = await prisma.agentRun.create({ data: { brief, organizationId, ..
await eventPublisher.sendEvent({
  id: run.id, // event id = run id → redeliveries are idempotent
  name: EVENT_KEYS.AGENT_RUN_REQUESTED,
  data: { agentRunId: run.id, organizationId },
});

The worker consumes it with a deliberately thin Inngest function — every step just dispatches a NestJS CQRS command:

inngest.createFunction(
  { id: 'agent-run-requested', retries: 1, triggers: [EVENTS.AGENT_RUN_REQUESTED] },
  async ({ event, step }) => {
    await step.run('plan-agent-run', () =>
      commandBus.execute(new PlanAgentRunCommand(event.data)));
  },
);

This split is the whole trick: Inngest owns retries, memoization, and durability; NestJS command handlers own business logic. Steps that already succeeded don't re-run after a crash. And because the handler is a plain injectable class, it's unit-testable without a queue in sight.

For multi-stage pipelines it scales beautifully. Gavely's list extraction is seven step.run calls — plan, generate, reconcile, check conflicts, commit, summarize, project — each one a command, each one independently retried. Fan-out is one more primitive: ex uses step.invoke to spawn one child function per document, all concurrent.

One more detail that pays for itself: every event payload is a zod schema in a central registry, so publishing a typo'd event or a malformed payload is a compile error, not a 2 a.m. incident.

4. Humans in the loop, two ways

Autonomous agents that mutate customer data are a liability. Both products gate the dangerous moments, with two different mechanisms worth knowing:

Gate on the plan (Gavely). The planning agent must call a submit_plan ut here's the twist — the tool doesn't do anything. The worker watches the stream, and the tool call itself is the control-flow signal:

for await (const chunk of stream.fullStream) {
  if (chunk.type === 'tool-call' && chunk.payload.toolName === 'submit_plan') {
    return { submitPlan: PlanInputSchema.parse(chunk.payload.args) }; // → AWAITING_APPROVAL
  }
  if (chunk.type === 'tool-call' && chunk.payload.toolName === 'ask_user') {
    return { askUser: chunk.payload.args.questions }; // → AWAITING_INPUT
  }
}

The run suspends, the UI renders a plan card with an Approve button, and approval publishes a fresh Inngest event that wakes the worker up. The same ask_user tool lets the agent pause mid-execution to ask clarifying questions — the answer comes back as the next event.

Gate on the tool (CarbonMe). Mastra has first-class support for this: mark a tool requireApproval: true and the stream emits an approval chunk instead of executing:

createTool({
  id: 'run_transforms',
  description: "'Materialize transforms against the warehouse',"
  requireApproval: true, // human reviews the SQL before it touches data
  execute: async (_input, ctx) => { /* only runs after approval */ },
});

The chat UI shows a Run/Decline card; approving resumes the same run — no rewind, no lost context. The agent authors SQL, the human clicks Run. "You author, the human runs" is even written into the agent's instructions.

5. Streaming to the browser: journal first, stream second

The naive approach — pipe the LLM stream straight to the HTTP response — breaks the moment the run outlives the request or the user refreshes the page. Both products instead treat the database as the source of truth and the stream as a live view.

As the worker consumes the agent stream, every meaningful chunk (text delta, tool call, tool result, status change) is journaled as a row in an agentRunEvent table, then published over Redis pub/sub for anyone listening:

const journal = (event) =>
  prisma.agentRunEvent.create({ data: { runId, type: event.type, ... } })
    .then((row) => onPublish?.(row)); // → SSE subscribers

The Next.js side reads SSE frames with a small custom reader (more control than EventSource), and a useChat hook folds events into React state:

if (event.type === 'text')      patch((m) => ({ ...m, text: m.text + event.text }));
if (event.type === 'tool-call') patch((m) => ({ ...m, tools: [...m.tools, event.tool] }));
if (event.type === 'approval')  patch((m) => ({ ...m, approval: { runId, toolCallId } }));

Because the journal is durable, the timeline UI is trivially resumable: reload the page, fetch the events, re-render the exact same thread — streamed text, tool steps with spinners/che
ckmarks, plan cards, question gates, and deliverable cards anchored to the tool results that produced them. The live stream is just the tail.

6. Lessons I'd hand to my past self

Split api and worker from day one. Agent workloads and HTTP workloads have opposite performance profiles. Different apps, shared libraries, events in between.
Keep Inngest functions thin. step.run → commandBus.execute(...) and nothing else. Your business logic shouldn't know a queue exists.
Give Mastra its own Postgres schema. Agent memory tables and Prisma migrations must never collide. One connection string, two schemas, zero conflicts.
Tools that only signal are a superpower. submit_plan and ask_user execute nothing — they're typed control-flow markers the orchestrator reacts to. Cheapest state machine you'll ever build.
Zod at every boundary. HTTP DTOs, event payloads, tool inputs, workflow step outputs. If it crosses a process boundary, it has a schema. This is what keeps a 4-service async sys tem debuggable.
Journal, then stream. DB rows are truth; SSE is a projection. Refreshes, reconnects, and multi-device just work.
Design the approval UX before the agent. The gates (plan approval, tool approval, clarifying questions) shaped more of the architecture than the prompts did.

The stack, honestly assessed

Mastra gave me agents-as-code with per-request dynamism, sub-agent delegation, built-in memory, and tool approval — without owning a single line of LLM-loop plumbing. (One caveat: its NestJS adapter is Express-only; we run Fastify, so we wrote a thin adapter.)
Inngest turned "long-running AI job" from a distributed-systems problem into a function with steps. Retries, idempotency, fan-out, and a local dev UI included.
NestJS kept two apps and a growing feature set coherent — CQRS handlers, DI, and zod-derived DTOs mean every feature looks like every other feature.
Next.js plus a small SSE reader and one hook was all the frontend needed to make agents feel alive.

If you're building agents that have to survive contact with real users and r the most leverage per line of code I've found.

Building something similar, or stuck on one of these pieces? I'm happy to c or DM.

An Ultimate Guide to Javascript Promises.(code Examples)

Faithful Ojebiyi — Sat, 20 Mar 2021 13:42:37 +0000

In this tutorial we would be talking about all the JavaScript promises, their differences and their use cases.

Introduction

Promises are a way to implement async programming in JavaScript(ES6). A Promise will become a container for future value. In a layman's term, you place and order for an item on Amazon. After your order is placed you receive a receipt with delivery date in your mailbox . The receipt in this case stands as a promise that your order will be delivered to you. The receipt is like the container or a proof of the item you order(future value).

For asynchronous programming, JavaScript used callbacks but there is a problem with using callbacks which is callback hell.

Callback might seem ok for little applications but when it comes to complex application with a lot of callbacks, you begin to have a lot of deeply nested callback functions which might become very difficult to read, understand or mange.

An example of callback hell

func1(function(a){ 
 func2(a, function(b){ 
  func3(b, function(c){ 
   ... 
  }); 
 }); 
});

Promises to the Rescue

A Promise is basically created when we are unsure of whether or not the assigned task will be completed. The Promise object represents the eventual completion (or failure) of an async(asynchronous) operation and its resulting value. As the name suggests, a Promise is either kept or broken.
A Promise is always in one of the following states:

fulfilled: Action related to the promise succeeded.
rejected: Action related to the promise failed.
pending: Promise is still pending i.e not fulfilled or rejected yet.
settled: Promise has fulfilled or rejected

Syntax

const promise = new Promise((resolve,reject) => {....});

Example

const myPromise = new Promise((resolve, reject) => { 
 if (Math.random() > 0) { 
  resolve('Hello, I am positive number!'); 
 } 
 reject(new Error('I failed some times')); 
})

I published an article about "the new features in ECMAscript 2021" Where I talked about promise.any() 1 and people asked about the differences between Javascript promises. So here am I with another article to clear any confusion you might have about the various implementations of Javascript promises.

Promise.All()

The Promise.all() method takes an iterable of promises as an input, and returns a single Promise that resolves to an array of the results of the input promises. This returned promise will resolve when all of the input's promises have resolved, or if the input iterable contains no promises. If any of the promises is rejected promise.all() throws and error with the first rejected promise

Let's take this example below. We create 3 promises to resolve at random times.

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("first promise resolved")
    // reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("second promise resolved")
    // reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("third promise resolved")
    // reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.all([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err)
  }

})();

If we take a look at our result in console, we can see that all three promises resolves.

Now, what if one of our promises is rejected? We have handled that error easily inside our try catch block.

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("first promise resolved")
    // reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("second promise resolved")
    reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("third promise resolved")
    // reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.all([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err)
  }

})();

Taking a look at console, we can see the rejected promise logged in console.

Promise.race()

The Promise.race() method returns a promise that fulfills or rejects as soon as one of the promises in an iterable fulfills or rejects, with the value or reason from that promise.

Example

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("first promise resolved")
    // reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("second promise resolved")
    // reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("third promise resolved")
    // reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.race([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err)
  }

})();

if we check our console only, one promise is returned and that's the promise that settles first either its resolved or rejected.

Promise.any()

Promise.any() is like the opposite of Promise.all(). Promise.any() resolves if any of the supplied promised is resolved unlike promise.all() which waits for all promises to resolve before it resolves.
lets take a look at the example below.
Basically, we have 3 promises that resolves at random times. We have used setTimeout() function to set a time taken for each promise to resolve. We used Math.floor(Math.random) to give a random time to the setTimeout function so we really dont know which promise resolves first. This is exaclty what happens in real life secenario.

const prom1 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the first promise"),
    Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the second promise"),
    Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the third promise"),
    Math.floor(Math.random() * 100)
  );
});

(async function() {
  const result = await Promise.any([prom1, prom2, prom3]);
  console.log(result); // Prints "A", "B" or "C"
})();

The good thing about promise.any() is even if one of the promises is rejected, it would continue to resolve other promise. It would only throw an aggregation error if all promises are rejected
.
Take a look at the two examples below
In the first example only on promise is rejected but it continues to resolves. In the second example all there promises are rejected hence we get an aggregate error

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("first promise resolved")
    reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("second promise resolved")
    // reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("third promise resolved")
    reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.any([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err, 'all promises rejected')
  }

})();

Example 2

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("first promise resolved")
    reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("second promise resolved")
    reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("third promise resolved")
    reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.any([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err, 'all promises rejected')
  }

})();

promise.allSettled()

The Promise.allSettled() method returns a promise that resolves after all of the given promises have either fulfilled or rejected, with an array of objects that each describes the outcome of each promise.
In the example below one of the promises is rejected but promise.allSettled() still returns all settled promises.

const prom1 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("first promise resolved")
    // reject("first promise rejected")
    }, Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(() => {
    resolve("second promise resolved")
    // reject("second promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(() => {
    // resolve("third promise resolved")
    reject("third promise rejected")
  }, Math.floor(Math.random() * 100)
  );
});

(async function() {
  try {
    const result = await Promise.allSettled([prom1, prom2, prom3]);
    console.log(result);
  } catch (err) {
    console.log(err)
  }

})();

Conclusion

In this tutorial, we have been able to point out the difference between JavaScript Promises and what they do.
If you have any additions or reservations, let me know in the comment below.

New Features in ECMAScript 2021 (with code examples)

Faithful Ojebiyi — Tue, 09 Mar 2021 10:08:53 +0000

In this tutorial we are going to learn about the new features we can use in the latest version of ECMAScript 2021 with some coding examples

Introduction

This Ecma Standard defines the ECMAScript 2022 Language. It is the twelfth edition of the ECMAScript Language Specification. Since publication of the first edition in 1997, ECMAScript has grown to be one of the world's most widely used general-purpose programming languages. It is best known as the language embedded in web browsers but has also been widely adopted for server and embedded applications.Introduction
This Ecma Standard defines the ECMAScript 2022 Language. It is the twelfth edition of the ECMAScript Language Specification. Since publication of the first edition in 1997, ECMAScript has grown to be one of the world's most widely used general-purpose programming languages. It is best known as the language embedded in web browsers but has also been widely adopted for server and embedded applications.

ECMA 2021

ECMAScript 2021, the 12th edition, introduces the replaceAll method for Strings; Promise.any, a Promise combinator that short-circuits when an input value is fulfilled; AggregateError, a new Error type to represent multiple errors at once; logical assignment operators (??=, &&=, ||=); WeakRef, for referring to a target object without preserving it from garbage collection, and FinalizationRegistry, to manage registration and unregistration of cleanup operations performed when target objects are garbage collected; separators for numeric literals (1_000); and Array.prototype.sort was made stable.

replaceAll

Assuming we have a constant named string

const string = "Javascript is the best web scripting language. Javascript can be used for both front end and backend";

and we want to replace the word Javascript with Typescript
we normally would use the replace method

const string = "Javascript is the best web scripting language. Javascript can be used for both front end and backend";

console.log(string.replace("Javascript", "Typescript"));

What if we want to replace all instances of Javascript with Typescript
That is where the replaceAll method comes to shine

const string = "Javascript is the best web scripting language. Javascript can be used for both front end and backend";

console.log(string.replaceAll("Javascript", "Typescript"));

Private Methods

lets create a class named People and we have will have some methods

class People {
  showName() {
    console.log("My name is Faithful")
  }
  showAge() {
    console.log("Faithful is 20")
  }
}

To access the methods inside the classes we first need to instantiate the class

class People {
  showName() {
    console.log("My name is Faithful")
  }
  showAge() {
    console.log("Faithful is 20")
  }
}

const people = new People()

people.showName()
people.showAge()

We can see that My name is Faithful and Faithful is 20 gets logged on console.

if we want to make showAge() a private method inside the class People so outside the scope of the class it is not accessible
we just add the # sign in front of the showAge method like this #showAge

class People {
  showName() {
    console.log("My name is Faithful")
  }
  #showAge() {
    console.log("Faithful is 20")
  }
}

const people = new People()

people.showName()
people.showAge()

we can see the result on our console. An error is saying people.showAge is not a function. This is because #showAge() is now a private method inside the class People and can only be access via a public method in side the class People.

Now lets try and access the private method #showAge()

first we create new public method called showAll() inside the class People from this public method we can access the private method #showAge() and since our new method is a public one we would be able to print the age on the console. Take a look at the code below

class People {
  showName() {
    console.log("My name is Faithful");
  }
  #showAge() {
    console.log("Faithful is 20");
  }
  showAll() {
    this.showName()
    this.#showAge();
  }
}

const people = new People();
people.showAll();

we can see that the error has disappeared and we can now access our private method via a public one showAll()

Private Accessors

Private accessors work very similar to private methods lets create a class named People and we have will have some methods

class People {
  get Name() {
    return "Faithful"
  }
  get Age() {
    return 20
  }
}

let people = new People();
console.log(people.Age);

We can see 20 gets logged on console.

if we want to make Age a private accessor inside the class People so outside the scope of the class it is not accessible
we just add the # sign in front of the Age method like this #Age

class People {
  get Name() {
    return "Faithful"
  }
  get #Age() {
    return 20
  }

}

let people = new People();
console.log(people.Age)

we can see the result on our console is undefined.
Now lets try and access the private method #Age()

first we create new public method called publicAge() inside the class People from this public method we can access the private method #Age() and since our new method is a public one we would be able to print the age on the console. Take a look at the code below

class People {
  get Name() {
    return "Faithful"
  }
  get #Age() {
    return 20
  }
  get publicAge() {
    return this.#Age
  }
}

let people = new People();
console.log(people.publicAge)

we can see that the error has disappeared and we can now access our private accessor via a public one publicAge()

Promise.any()

Promise.any() is like the opposite of Promise.all(). Promise.any() resolves if any of the supplied promised is resolved unlike promise.all() which waits for all promises to resolve before it resolves.
lets take a look at the example below
Basically we have 3 promises that resolves at random times. We have used setTimeout() function to set a time taken for each promise to resolve and we used Math.floor(Math.random) to give a random time to the setTimeout function so we really dont know which promise resolves first. This exaclty what happens in real world secenario.

const prom1 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the first promise"),
    Math.floor(Math.random() * 100)
  );
});
const prom2 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the second promise"),
    Math.floor(Math.random() * 100)
  );
});
const prom3 = new Promise((resolve, reject) => {
  setTimeout(
    () => resolve("this is the third promise"),
    Math.floor(Math.random() * 100)
  );
});

(async function() {
  const result = await Promise.any([prom1, prom2, prom3]);
  console.log(result); // Prints "A", "B" or "C"
})();

from the result in console, we can see that our second promise resolves first.

Wait! what if none of the promises resolve? Well, Promise.any() throws an AggregateError exception. We will handle it in a try catch block.
Take a look at the example below

const rejected = new Promise((resolve, reject) => {
  setTimeout(
    () => reject("this is the first promise"),
    Math.floor(Math.random() * 100)
  );
});

try {
  (async function() {
    const result = await Promise.any([rejected]);
    console.log(result);
  })();
} catch(error) {
  console.log(error.errors);
}

Numeric Separators

This feature enables developers to make their numeric literals more readable by creating a visual separation between groups of digits. Large numeric literals are difficult for the human eye to parse quickly, especially when there are long digit repetitions.

1000000000   // Is this a billion? a hundred millions? Ten millions?
101475938.38 // what scale is this? what power of 10?

Examples

Regular Number Literals

let budget = 1_000_000_000_000;
// What is the value of `budget`? It's 1 trillion!
// 
// Let's confirm:
console.log(budget === 10 ** 12); // true

Binary Literals

let nibbles = 0b1010_0001_1000_0101;
// Is bit 7 on? It sure is!
// 0b1010_0001_1000_0101
//          
// We can double check: 
console.log(!!(nibbles & (1 << 7))); // true

Hex Literals

// Messages are sent as 24 bit values, but should be 
// treated as 3 distinct bytes:
let message = 0xA0_B0_C0;

// What's the value of the upper most byte? It's A0, or 160.
// We can confirm that:
let a = (message >> 16) & 0xFF; 
console.log(a.toString(16), a); // a0, 160

// What's the value of the middle byte? It's B0, or 176.
// Let's just make sure...
let b = (message >> 8) & 0xFF;
console.log(b.toString(16), b); // b0, 176

// What's the value of the lower most byte? It's C0, or 192.
// Again, let's prove that:
let c = message & 0xFF;
console.log(c.toString(16), b); // c0, 192

lets view our result in console

Logical Assignment Operator

Logical Assignment Operator with `&&`

Logical assignment operator combines the logical operations(&&, || or ??) with assignment.

var x = 1;
var y = 2;
x &&= y;
console.log(x); // 2

Techincally here's what is actually going on

if(x) {
  x = y
}

Since x is a truthy value, it is assigned with the value of y, ie 2.

Just like the way we did with &&, we can do with || and ??.

x &&= y;
x ||= y;
x ??= y;

Logical assignment operator with `||`

var x = 1;
var y = 2;
x ||= y;
console.log(x);

That means, the assignment operation happens only if x is a falsy value. In our code, x contains 1 which is a truthy value and hence, assignment does not happen. That is why our code prints 1 in the console.

Logical assignment operator with `??`

?? is Nullish Coalescing operator in JavaScript. It specifically checks if a value is null or undefined.

var a;
var b = a ?? 5;
console.log(b);

In line 2, if the value of a is null or undefined, the right hand side of ?? is evaluated and assigned to b.

Let us now consider ?? along with =.

var x;
var y = 2;
x ??= y;
console.log(x); //

Here the value of x is undefined. So the right hand side expression is evaluated and sets x to 2.

You can edit and test the code here

Happy Coding!

Migrating your SQL Database to MongoDb

Faithful Ojebiyi — Mon, 08 Mar 2021 19:29:33 +0000

In this article you are going to learn how to migrate your Relational database(MySQL, MariaDb etc) to Non-relational database like MongoDb.

Requirements.

I expect that any one reading this article has at least a minimal knowledge of databases, and if you are a complete newbie, there will be a brief introduction to database and a link will be attached for further reading.

Expectation.

At the end of this article you should be able to write your own script and migrate your database from MySQL to MongoDB
You should be able to differentiate between a Relational Database and a Non Relational Database is, how they work, their differences and their similarities.

Stack
Mongodb, MySQL(Maridb was used in this article), Sequelize, Sequelize-auto Nodejs
NOTE: The example code is similar to what you’ll be having when you follow the steps and do not expect the exact same thing since the structure of your database differs.

Database

A database is simply a collection of structured data. Think of taking a selfie: you push a button and capture an image of yourself. Your photo is data, and your phone’s gallery is the database. A database is a place in which data is stored and organized.

SQL

MySQL and SQL are not the same. Be aware that MySQL is one of the most popular Relational Database Management System (RDBMS) software’s brand names, which implements a client-server model. So, how do the client and server communicate in an RDBMS environment? They use a domain-specific language – Structured Query Language (SQL). If you ever encounter other names that have SQL in them, like PostgreSQL and Microsoft SQL server, they are most likely brands which also use Structured Query Language syntax. RDBMS software is often written in other programming languages, but always use SQL as their primary language to interact with the database. MySQL itself is written in C and C++. The word “relational” means that the data stored in the dataset is organized as tables. Every table relates in some ways. If the software doesn’t support the relational data model, just call it DBMS.

Introduction to MySQL

MySQL is an open source relational database management system (RDBMS) which uses the Structured Query Language (SQL) as a mechanism for dealing and interacting with the data. Although MySQL is one of the widely used and well known database management systems and is considered as reliable, scalable and efficient database management system, It is NOT well suited for handling big data, especially with HUGE insertion rates.

Intoduction to MongoDb

MongoDB is an open source, nonrelational database management system (DBMS) that uses flexible documents instead of tables and rows to process and store various forms of data. As a NoSQL solution, MongoDB does not require a relational database management system (RDBMS), so it provides an elastic data storage model that enables users to store and query multivariate data types with ease. This not only simplifies database management for developers but also creates a highly scalable environment for cross-platform applications and services.
MongoDB documents or collections of documents are the basic units of data. Formatted as Binary JSON (Java Script Object Notation), these documents can store various types of data and be distributed across multiple systems. Since MongoDB employs a dynamic schema design, users have unparalleled flexibility when creating data records, querying document collections through MongoDB aggregation and analyzing large amounts of information.

MongoDB vs. MySQL
MySQL uses a structured query language to access stored data. In this format, schemas are used to create database structures, utilizing tables as a way to standardize data types so that values are searchable and can be queried properly. A mature solution, MySQL is useful for a variety of situations including website databases, applications and commercial product management.
Because of its rigid nature, MySQL is preferable to MongoDB when data integrity and isolation are essential, such as when managing transactional data. But MongoDB’s less-restrictive format and higher performance make it a better choice, particularly when availability and speed are primary concerns

Why we needed to migrate
We built a digital Sytems for farmers and as we tried scaling and replicating our technology in other states and countries, we discovered our database structure was constantly changing. Because of the schemaless and unstructured design of MongoDb we could have documents with different datasets in MongoDb in contrast to relational database. I was going to migrate about 600k records from MariaDb to MongoDb.
I surfed the internet for tools that could be of help and I came across Studio3t and Mongify

Studio3T is owned by 3T Software Labs and they are a MongoDB technology partner.
3T has been making professional tools for MongoDB since 2014 and Studio 3T is now the number one 3rd party GUI / IDE for developers and data engineers who work with MongoDB. Data management features such as in-place editing and easy database connections are matched with polyglot query code generation, advanced shell with auto-completion, easy SQL import/export, as well as heavy-duty migrations between relational databases and MongoDB.

Problem Statement
Sincerely, Studio has great features. They have a free plan which allows you to test their features for 30 days. This was cool until I had finished writing my queries(filters and joins), clicked “export” and all saw was 1000 documents in MongoDb , but i have about 600k records in MariaDB there was no way my MongoDb database could be any less than that. So i decided to do some digging and I found out that the max i could do with the free tier was 1k. This nothing compared to 600k. Upgrading to their enterprise plan wasn’t a big deal the price was 700USD for a single user per year, but coming from a third -world country link Nigeria that’s a lot of money. Considering the fact that, i needed just a single tool from the entire software package. It was a no for me.

Mongify is a utility (or a ruby gem ) written in the ruby language and is used to migrate databases from SQL to mongodb. Further detailed information about ruby language and ruby gems can be found on their corresponding websites. Mongify utility migrates databases while not caring about primary keys and foreign keys as in the case of an RDBMS. It supports data migration from MySQL, SQLite and other relational databases. However, this article only focuses on migrating data from MySQL to MongoDB.

Problem Statement
The problem I had with mongify was ruby gems had compatibility issues. Installation on windows is not quite straight forward, it could be easier on Linux (give it a trial if you use Linux). Solving an issue appears to be a license for bugs, they keep springing up. After burring my head in their documentation and spending almost a full day trying to fix gem’s compatibility issues, I gave up.

My Solution

I figured it was high time i wrote my script.
For the migration i assume you should already have a SQL database somewhere either in the cloud or on your local machine.
To install mongodb on your server or local machine follow the instruction in the mongodb docs

You must have Node and MongoDB Compass installed on your local machine,
Your MongoDB itself could reside anywhere either on your local machine or on the cloud like MongoDB atlas. You can follow the instructions in the MongoDB docs to get you started.

MongoDB Compass is the official GUI for MongoDB, maintained by MongoDB itself. MongoDB Compass helps users make clever decisions about the data structure, querying, indexing, and many more actions you can perform on the database.
To get Node installed on your computer. Follow any of the links below:
for windows, for Mac or for linux
To check if you have Node.js installed, run this command in your terminal:
node -v
To confirm NPM is installed, type **npm** -v in Terminal. This should print the version number so you'll see something like this 6.4.

NPM is a package manager for the JavaScript programming language. npm, Inc. is a subsidiary of GitHub, that provides hosting for software development and version control with the usage of Git. npm is the default package manager for the JavaScript runtime environment Node.js.

To get started on a new project cd into your workspace folder make a new directory that will host your project open terminal and type:

npm init

you’ll be asked to fill in some details about your project. After saving a package.json file should be created for you.
Then you can now install the following npm dependencies with the following command.

npm install sequelize-auto sequelize mysql2

sequelize-auto was used to generate a model for my sequelize

sequelize is a promise-based Node. js ORM for Postgres, MySQL, MariaDB,
SQLite and Microsoft SQL Server. It features solid transaction support, relations, eager and lazy loading, read replication and more.

mysql2 is a MySQL client for Node.js with focus on performance.
To generate your model with sequelize-auto you needed to run this command

npx sequelize-auto -h <host> -d <database> -u <user> -x [password] -p [port]  --dialect [dialect] -c [/path/to/config] -o [/path/to/models] -t [tableName]

the models are all saved into the file you set in “path/to/models”. It produces a file like this /model/user.js

Sequelize-auto also generates an initialization file, ./models/init-models.js, which contains the code to load each model definition into Sequelize:

This makes it easy to import all your models into Sequelize by calling initModels(sequelize).

To run our script create a file called index.js in the root folder this would be the starting point for your script.
Follow the **[getting started guide**](https://sequelize.org/master/manual/getting-started.html) in the sequelize documentation to get you started with sequelize.

We want to be able to write the result of our database into a json file which we will later import into MongoDB using MongoDB Compass.
We need two modules “fs” and “path” we don’t need to install them they already come with node. i just import them using ‘require’ in our code

The Path module provides a way of working with directories and file paths.
Node.js includes fs module to access physical file system. The fs module is responsible for all the asynchronous or synchronous file I/O operations. You can click on the links to learn more about their usecase.

to run the index.js file edit your package.json file to look something like this

then run the command npm run start in the terminal. Your imports should be saved into a file called users.json in your root folder.

Happy Coding.

For further questions you can reach out to me via email faithfulojebiyi@gmail.com

DEV Community: Faithful Ojebiyi

Building Production AI Agents with Mastra, NestJS, Inngest, and Next.js

The architecture in one paragraph

1. Agents are code, and they live in a library

2. Never let the model tell you who the user is

3. Inngest makes agent runs durable — and CQRS keeps them testable

4. Humans in the loop, two ways

5. Streaming to the browser: journal first, stream second

6. Lessons I'd hand to my past self

The stack, honestly assessed

An Ultimate Guide to Javascript Promises.(code Examples)

Introduction

Promises to the Rescue

Promise.All()

Promise.race()

Promise.any()

promise.allSettled()

Conclusion

New Features in ECMAScript 2021 (with code examples)

Introduction

ECMA 2021

replaceAll

Private Methods

Private Accessors

Promise.any()

Numeric Separators

Examples

Logical Assignment Operator

Logical Assignment Operator with &&

Logical assignment operator with ||

Logical assignment operator with ??

You can edit and test the code here

Happy Coding!

Migrating your SQL Database to MongoDb

Database

SQL

Introduction to MySQL

Intoduction to MongoDb

My Solution

Logical Assignment Operator with `&&`

Logical assignment operator with `||`

Logical assignment operator with `??`