DEV Community: john mbugua

[Boost]

john mbugua — Sat, 07 Feb 2026 13:44:58 +0000

Local vs Cloud Builds in Expo: What expo prebuild and eas build Really Do

john mbugua ・ Feb 7

#reactnative #programming #react #mobile

Local vs Cloud Builds in Expo: What expo prebuild and eas build Really Do

john mbugua — Sat, 07 Feb 2026 13:44:39 +0000

Introduction

There’s a lot of confusion around terms like Prebuild, Dev Client, EAS Build, and Continuous Native Generation (CNG). I remember the confusion I used to have myself especially when trying to understand the difference between EAS cloud builds and local builds.

For a long time, I assumed that a local build was the same thing as the CNG process. I kept asking myself:

What is the logic behind each build?
What’s the real difference between cloud builds and local builds?
What do you actually gain from using EAS Build versus building locally?

At some point, the questions got even more confusing:

Was EAS Build ignoring my native code?
And where did CNG fit into all of this?

The confusion didn’t come from the tools themselves, it came from not understanding how they connect.

Once I finally understood what CNG really is, how Prebuild fits into it, and how both local builds and cloud builds rely on the same native generation system, everything clicked.

So before comparing cloud builds and local builds, let’s first talk about CNG.

What is Continuous Native Generation (CNG)?

When I was learning React Native, I remember a time when CNG was not really a thing yet. Building an app that included native modules often meant ejecting from your project whether you were using Expo or React Native CLI. Once you ejected, you were suddenly responsible for configuring native code manually.

Does this look familiar? 😅 The old managed vs bare workflow era…

expo eject

expo eject --eject-method=bare

Or even better, the interactive prompt where you had to choose:

Bare workflow (eject)
Managed workflow (stay)

Working with native modules meant editing things like:

AndroidManifest.xml
Gradle files
iOS Info.plist
platform-specific permissions and setup

On top of that, some libraries only supported older OS versions, and getting them to work correctly with your app could be frustrating. Upgrading React Native or adding new native functionality often felt risky, because one wrong change could break the entire build.

Then CNG came in and changed the workflow completely.

Continuous Native Generation (CNG) is Expo’s approach to managing native code in a React Native app. Before CNG, native projects were usually created once and then manually maintained for the entire lifetime of the app. Over time, this made native code fragile, hard to upgrade, and difficult to reason about.

Instead of treating native projects as something you create once and protect forever, CNG treats them as short-lived, generated artifacts. Native projects are created only when needed such as during development, debugging, or building and they are generated from a standard template plus a set of configuration rules.

With CNG, developers don’t maintain the native projects themselves. They maintain the instructions for how those native projects should be created.

Those instructions live in:

app.json or app.config.js
config plugins provided by libraries or written by the developer

When Expo needs native code, it:

Starts from a clean native template
Applies the configuration and config plugins
Generates the Android and iOS projects
Builds the app

At this point, we now know what CNG is and why it exists. It’s the system responsible for generating native projects in a predictable and repeatable way.

CNG itself doesn’t build your app it prepares the native code that builds depend on. Tools like Prebuild, local dev builds, and EAS cloud builds all rely on this same native generation process.

With that foundation in place, we can now clearly compare local builds and EAS cloud builds, understand what each one actually does, and see how CNG fits into both.

Local Builds vs EAS Builds

Before comparing local builds and EAS builds, it’s important to clarify what we actually mean by “local build” because this is where a lot of confusion starts 😅.

When I say local build, I’m referring to building your native app on your own machine, where the Android and iOS projects (/android and /ios) are generated locally and compiled using your local environment.

That usually looks like this:

Native projects are generated locally
You can open Android Studio or Xcode
You can run and debug the app directly on your machine

Now, to make things a little more confusing (because of course 😄), we also have:

eas build --local

Which allows you to run the EAS Build pipeline locally, instead of on Expo’s servers.

So now we have:

local builds using npx expo prebuild + npx expo run:*
local builds using eas build --local
cloud builds using eas build

At first glance, this can make it feel like there are many different build systems. But here’s the key point:

All of these builds rely on the same underlying system: Continuous Native Generation (CNG).

Whether you build locally or in the cloud, native projects are always generated using CNG. The difference between these workflows is not how native code is generated it’s where the build runs and what the workflow is optimized for.

With that in mind, we can now clearly break down the differences between local builds and EAS cloud builds, and understand when each one makes sense.

Local Builds (Dev Client Builds)

When we talk about local builds in Expo, we’re usually referring to building and running the app on your own machine, with native projects generated locally. This is the workflow most developers use during active development and debugging.

Local builds are powered by Prebuild, which is Expo’s implementation of Continuous Native Generation (CNG).

when you run:

npx expo prebuild

Expo generates the native Android and iOS projects (/android and /ios) from your app configuration and installed libraries. These native projects are created so your React Native code can be compiled and run as a real native app.

Once the native projects exist, you can run the app locally using.

Android:

npx expo run:android

IOS

npx expo run:ios

This compiles and launches the app using your local Android or iOS development environment, allowing you to debug the app, inspect logs, and even open the project in Android Studio or Xcode.

A quick but important note about modifying native files

Because the native projects are generated by Prebuild, modifying them manually comes with a tradeoff.

If you later run:

npx expo prebuild --clean

Expo will delete and regenerate the native projects. Any manual changes made directly inside /android or /ios can be lost.

That’s why Expo encourages developers to use config plugins instead of editing native files directly. Config plugins are functions that apply native changes automatically during Prebuild, making those changes repeatable and safe.

EAS Build (Cloud Builds)

While local builds are great for development and debugging, they’re not always ideal for packaging, distributing, or shipping apps. This is where EAS Build comes in.

EAS Build is Expo’s cloud-based build service. Instead of compiling your Android or iOS app on your machine, the entire build process runs on Expo’s servers, producing installable artifacts like APKs, AABs, or IPAs.

At its simplest, running:

eas build --platform all

Uploads your project to EAS Build, where it is compiled in a clean, consistent environment for both Android and iOS.

How EAS Build works with CNG

This is where a lot of confusion usually comes from.

EAS Build does not replace Continuous Native Generation (CNG). It uses it.

If your project does not have /android and /ios folders, EAS Build will run Prebuild (CNG) in the cloud to generate them.
If your project already has /android and /ios, EAS Build will use those native projects as they are and will not regenerate them.

Either way, native code is still prepared using the same CNG system. The difference is simply where the process runs and who compiles the app.

What EAS Build is really good at

EAS Build is optimized for distribution and automation, not daily iteration. It shines when you need to:

build production-ready binaries for app stores
share builds with testers using internal distribution links
avoid local Android or iOS environment setup
ensure consistent builds across a team
automate builds using CI or EAS Workflows
manage signing credentials without manual setup

Because builds run in the cloud, every build starts from a clean environment, reducing “works on my machine” problems.

The key takeaway

EAS Build focuses on packaging, distribution, and automation.
Local builds focus on fast iteration and debugging.
Both rely on the same CNG system underneath.

Once you understand that, the relationship between local builds, cloud builds, and native code becomes much easier to reason about.

Happy coding

john mbugua — Sat, 24 Jan 2026 19:31:56 +0000

john mbugua

Jan 24

React Render vs Commit: What Actually Happens (DOM vs React Native)

#react #reactnative #programming

Comments

4 min read

React Render vs Commit: What Actually Happens (DOM vs React Native)

john mbugua — Sat, 24 Jan 2026 19:23:02 +0000

I know we’ve all heard these phrases: “React rendering” and “React commit” and if you’ve ever profiled a React Native app, you’ve probably seen logs or profiler entries like “committed.” It’s an interesting topic: how React works when it’s rendering and committing changes, whether that’s to the DOM (on the web) or to native UI views (in React Native).

So let’s start with something small but important: React’s render phase and commit phase. We’ll look at how updates get scheduled across the component tree, what actually causes React to render, what reconciliation means, why some renders don’t result in visible UI changes, and how optimization starts to matter once rendering becomes a performance bottleneck.

What causes a component to render?

A component renders when React thinks something in that part of the tree might have changed. The most common triggers are:

State updates (useState, useReducer, class setState)
Props changes from a parent
Context updates (any consumers of that context may re-render)
Store updates (Redux/Zustand/MobX subscriptions)
A parent re-render, which can cause React to re-run children while computing the next UI

Once any of these happen, React schedules work and begins the update process. And this is where the two phases come in.

The two-phase model: render phase & commit phase

The easiest way to think about React updates is:

Render phase computes the next UI. Commit phase applies it to the real platform UI.

Render phase

On the left side of the image is the Render Phase. This is where React does planning, not painting.

1) JSX becomes React elements

In my diagram, JSX flows into a React element via createElement(). That’s exactly the idea:

JSX is just syntax.
It becomes React elements (plain objects describing type + props + children).
This step is the same in React DOM and React Native.

React elements are not DOM nodes and not native views, they’re the description of what you want.

2) Current tree vs Work-in-progress tree

When an update happens (state/props change), React doesn’t immediately touch the screen. Instead, it builds a new version of the UI internally:

Current tree: the last committed version (what the user is currently seeing)
Work-in-progress tree: the next version React is building based on the new state/props

3) Reconciliation

That “Compare React Element/Reconciliation” arrow in my image represents the core job of the render phase.
React compares what the UI looked like before (current) with what it should look like now (work-in-progress) and figures out:

what stays the same
what needs to update
what should be added
what should be removed

4) Output of render phase

At the end of the render phase, React produces what I have called in the diagram changes, basically a list of “things the renderer must do.”

The screen hasn’t changed yet. React has only computed what should change.

Commit phase

Now we move to the right side of the image the Commit Phase. This is where React stops planning and starts applying. React core hands the “changes” to a renderer.

React Native commit

React Native applies those changes by creating/updating/removing native view instances, such as:

View
Text
Image

So commit in React Native means: update the native UI tree.

React DOM commit

React DOM applies those changes by creating/updating/removing DOM nodes,elements in the browser DOM tree.
So commit on the web means: update the DOM.

Unnecessary renders

Now that we’ve seen the big picture (render phase - commit phase), this second diagram shows a very common performance situation: a component re-renders, but nothing visually changes. That’s what people usually mean when they say unnecessary (or wasted) renders.

The setup

In the diagram, the Parent component is flagged because its state or props changed. That could be a button press, a text input update, a timer tick, a fetch response, anything that triggers a state/props update.

Once the parent is flagged, React schedules work and starts the render phase.

What happens in the render phase (and why children get involved)

During the render phase, React re-runs the parent to compute the next UI. But it doesn’t stop there.

Because the parent’s output may include children, React will typically continue into the subtree and re-run child components too, so it can build the next work-in-progress tree.

That’s the key idea of the diagram is showing:

Parent changes → React re-runs Parent
React attempts to render its children as part of building the next tree
React produces the next output (React elements)
React compares **Current tree vs **Work-in-progress tree (reconciliation)

The “unnecessary render” moment

Here’s the important part: the child re-rendered, but its output didn’t change.

So what does React do?

The child component function still ran (render work happened)
Reconciliation still compared old vs new output
But since the child output was the same, React produces no host updates for that child

That means when React gets to the commit phase, there’s nothing to apply for that child subtree:

React Native: no new/updated/removed native view instances for that child
React DOM: no meaningful DOM mutations for that child

So the render happened, but the commit work for that child was basically a no-op.

This is why it’s called wasted work:

You paid the cost of re-running the component and reconciling it, but you didn’t get any UI change.

Why unnecessary renders matter in profiling

When profiling, this is exactly why you might see:

many component renders,
but very little commit activity,
and still feel the app getting slower (especially on lower-end devices).

Because the cost you’re paying is mostly on the JavaScript side

executing component functions
running hooks
reconciling children

Even if commit is small, lots of wasted render work can still block the JS thread and create jank.

Unnecessary renders happen when a parent update causes a child to re-render during the render phase, but the child’s output stays the same, so there are no actual UI changes to commit.

[Boost]

john mbugua — Sat, 10 Jan 2026 20:19:36 +0000

john mbugua

Jan 10

React Native Optimization: Stop Recreating Functions in Large Lists (FlatList, Flashlist, LegendList...)

#reactnative #react #softwaredevelopment #programming

Comments

2 min read

React Native Optimization: Stop Recreating Functions in Large Lists (FlatList, Flashlist, LegendList...)

john mbugua — Sat, 10 Jan 2026 19:51:39 +0000

A practical guide to optimizing list performance in React Native by memoizing renderItem and callbacks to prevent unnecessary re-renders.

When a React Native screen starts feeling (Heavy, janky scroll, dropped frames), it’s often not one big issue, it’s lots of small ones stacking up.One of the most common (and easiest to fix) is inline functions in large lists. This applies to FlatList, SectionList, LegendList, Shopify FlashList, and pretty much any component that renders many rows.

Why inline functions hurt list performance

In JavaScript, functions are objects. That means every time your component re-renders, any inline function you write is created again with a new reference.

<LegendList
  data={data}
  renderItem={({ item }) => (
    <Row
      item={item}
      onPress={() => handlePress(item.id)} // new function every render
    />
  )}
/>

Even if item didn’t change, onPress={() => ...} is a brand new function each render.

Why does that matter?

If Row is memoized, it can still re-render because a prop changed (new function reference).
In big lists, that means more work for the JS thread, more layout work, and a higher chance of scroll stutters.

The goal is not “never use inline functions.” The goal is: don’t create new function references for every row, every render, especially when the list is large.

Memoize renderItem with useCallback

First, make renderItem stable.

const renderItem = useCallback(({ item }) => {
  return <Row item={item} />;
}, []);

return (
  <FlatList
    data={data}
    renderItem={renderItem}
    keyExtractor={(item) => item.id}
  />
);

Now renderItem won’t be recreated on every screen re-render.

Cool — but what about row actions?

At this point renderItem is stable, which is a big win.

But sometimes items usually have actions:

tap to open details
long-press to show a menu
swipe / delete
“call customer”, “copy code”, etc.

And this is where many apps accidentally bring the problem back.

The common trap: inline callbacks per row

You will often have/see something like this:

const renderItem = useCallback(({ item }) => (
  <Row
    item={item}
    onPress={() => handleOpen(item.id)}
    onLongPress={() => handleMenu(item)}
  />
), [handleOpen, handleMenu]);

Even though renderItem is memoized, those () => ... functions are still created when renderItem runs. That means every row receives new callback references, which can cause Row to re-render even when the UI didn’t actually change.

So what's the next goal:

Keep handlers stable, and avoid generating new functions for each item inside renderItem.

The better pattern: pass stable handlers, let the row provide the id Instead of binding item inside renderItem, pass a stable function down and let the row call it with its own identifier.

const onPressItem = useCallback((id: string) => {
  handleOpen(id);
}, [handleOpen]);

const onLongPressItem = useCallback((id: string) => {
  handleMenu(id);
}, [handleMenu]);

const renderItem = useCallback(({ item }) => {
  return (
    <Row
      item={item}
      onPressItem={onPressItem}
      onLongPressItem={onLongPressItem}
    />
  );
}, [onPressItem, onLongPressItem]);

Now, as long ashandleOpen and handleMenu don’t change, the function references stay stable.

Conclusion

When you are working with large lists in React Native, the small things matter. Memoizing renderItem and avoiding inline callbacks helps keep references stable, which means fewer unnecessary row re-renders and smoother scrolling.

You don’t have to over optimize every screen, but for list heavy UIs, these changes are some of the highest wins you can make.

Acknowledgement: Big thanks to the team at Callstack for their webinar on React Native optimization a lot of the ideas here clicked for me through that talk.

[Boost]

john mbugua — Sun, 05 Oct 2025 09:50:44 +0000

john mbugua

Oct 5 '25

Two Apps, One Device: Dynamic app.config.(js|ts) in Expo

#reactnative #mobile #programming #buildinpublic

Comments 1

5 min read

Two Apps, One Device: Dynamic app.config.(js|ts) in Expo

john mbugua — Sun, 05 Oct 2025 09:50:10 +0000

Introduction
What is app.config.(js|ts), app.json?
A quick story
Why this matters
Conclusion
Resources

Introduction

In my React Native + Expo workflow I run three environments: development, preview, and production. I use development for day to day coding and to take full advantage of Expo’s dev tools and fast iteration. Preview mimics production so I can see exactly how the app will behave before a release, no debug extras, realistic settings. Production is the real, ready build for users. With a dynamic app.config.(js|ts), I can keep all three installed side by side on one device.✅

What is `app.config.(js|ts), app.json`?

It's a file used for configuring Expo Prebuild, platform settings (names, bundle IDs, icons, deep-link schemes, OTA update channels, plugins, etc.)
It must be located at the root of your project.

What it can contain (most common properties)
The app config configures many things such as app name, icon, splash screen, deep linking scheme, API keys to use for some services and so on.

Identity: name, slug, owner, version
Platform IDs: ios.bundleIdentifier, android.package
Deep links: scheme, intentFilters (Android), associated domains (iOS)
Assets & UI: icon, splash, adaptiveIcon, userInterfaceStyle
Updates/OTA: updates.channel or runtimeVersion policy
Permissions & platform options: e.g., Bluetooth, camera, android.permissions
Build tooling: plugins, experiments, newArchEnabled
Runtime flags: extra (and EXPO_PUBLIC_* envs) for reading inside your app

Static vs dynamic

Static(json)

{
  "expo": { "name": "MyApp", "ios": { "bundleIdentifier": "com.company.myapp" } }
}

Dynamic(json)

Dynamic configuration in Expo lets you generate your app settings at build time using real JavaScript/TypeScript. That means you can branch on environment variables, tweak names/IDs/icons/schemes per build, and expose safe runtime flags all from one file. Below are the key points; you can dive deeper in the official Expo Docs.

You can write your config in JavaScript (app.config.js) or TypeScript (app.config.ts) for more flexibility.
In these files you can use comments, variables, and single quotes—it’s just regular JS/TS.
ES module import isn’t supported in plain JS. Use require() instead. (Exception: TypeScript with tsx can use import.)
In dynamic configs, you can use modern JavaScript features like optional chaining (?.) and nullish coalescing (??). They work in app.config.ts via TS, and in app.config.js as long as your Node version supports ES2020 (Node 14+ recommended).
The config is re-evaluated on Metro reload, so changes show up when the bundler refreshes.
You can read env vars (e.g., process.env.APP_VARIANT) to pass environment info into your app (via extra or EXPO_PUBLIC_*).
The config must be synchronous—no Promises/async code inside.

// app.config.ts
const ENV = process.env.APP_VARIANT ?? 'production'; // env info

export default ({ config }) => {
  const isDev = ENV === 'development'; // variables + single quotes

  const name = isDev ? 'MyApp (Dev)' : 'MyApp';

  return {
    ...config,
    name,
    ios: { bundleIdentifier: isDev ? 'com.me.myapp.dev' : 'com.me.myapp' },
    android: { package: isDev ? 'com.me.myapp.dev' : 'com.me.myapp' },
    extra: { APP_VARIANT: ENV }, // expose to app at runtime
  };
};

A quick story

For a long time I shipped with a static app.json. It worked until testing time. I needed the production build to feel what users feel, and the development build for my daily work. But with one static config (one bundle ID, one scheme), my phone couldn’t keep both installed. Every test cycle became: uninstall dev → install prod/preview → test → uninstall prod/preview → reinstall dev → keep coding. It was slow, tiresome, and I constantly second guessed whether I was testing the right thing. Thanks to dynamic configuration, I can now keep both environments on my phone and test each app side-by-side—no more uninstall/reinstall dance.

Why this matters

You want dev, preview, and prod to coexist on the same phone. That only works if each build has a unique identity. Dynamic app.config.js lets you generate those identities from one codebase .

How it works
Expo reads your app.config.js at build time. Because it’s JavaScript, you can:

Look at an env variable (here: process.env.APP_VARIANT)🕰️.
Branch the config to change names✳️
Return a plain object, Expo uses it to produce native projects with those values❇️.

Core idea: different IDs → different apps. iOS uses bundleIdentifier; Android uses package. If these differ, the OS treats them as different apps that can be installed side-by-side. Below is just a sample of my app.config.js

export default ({ config }) => ({
  ...config,
  name: getAppName(),
  slug: "tkt-app",
  owner: "iguru-ltd",
  version: "2.2.0",
  orientation: "portrait",
  icon: "./assets/images/icon.png",
  scheme: "tktapp",
  userInterfaceStyle: "automatic",
  newArchEnabled: true,
  ios: {
     // other configs for ios
    bundleIdentifier: getUniqueIdentifier(),
  },
  android: {
    // other config for android
    package: getUniqueIdentifier(),
    runtimeVersion: "1.0.0",
  },
  web: {
    bundler: "metro",
    output: "static",
    favicon: "./assets/images/favicon.png",
  },
  plugins: [
   // all the plugins configurations will go here/ some will appear here during installion
  ],
  experiments: {
    typedRoutes: true,
  },
  updates: {
     //configs for OTA update
    },
  extra: {
   // may include your project id for eas build

  },
});

Export a function that returns your config

This makes the file dynamic, you can compute values first, then return them, Allowing you to add your own custom config.

export default ({ config }) => ({
  ...config,
  // ...all your fields
});

Read the environment & set helpers

You can have different configuration in development, staging, and production environments. These flags drive everything that changes per build. To accomplish this, you can use app.config.js along with environment variables

const IS_DEV = process.env.APP_VARIANT === "development";
const IS_PREVIEW = process.env.APP_VARIANT === "preview";

Change the app name per environment

Visible on-device so you don’t tap the wrong one. I love to have a helper function that return the App name based on the environment i am working on.

const getAppName = () => {
  if (IS_DEV) return "TKT APP (Dev)";
  if (IS_PREVIEW) return "TKT APP (Preview)";
  return "TKT APP"; // production
};

Change the native identifiers (the key to parallel installs)

const getUniqueIdentifier = () => {
  if (IS_DEV) return "com.mbuguacode.tktapp.dev";
  if (IS_PREVIEW) return "com.mbuguacode.tktapp.preview";
  return "com.mbuguacode.tktapp"; // production
};

All your Bluetooth permissions, splash config, and plugins remain the same, dynamic config only overrides what must differ.

A quick: how Expo turns this into separate apps

You run a build with APP_VARIANT=development (or preview/production).
app.config.js returns an object with unique name + unique bundleIdentifier/package.
EAS/CLI generates native projects with those identifiers.
The OS treats each identifier as a different app → they install side-by-side.

Conclusion

My take is: this isn’t about fancy tooling, it’s about mindset. Treating config as code has been the quiet upgrade that changed my day-to-day coding. I hope this article sparks something for you too maybe it’s setting up that second environment, maybe it’s finally badging your icons, or just tightening your release path.Kudos!🙌

Learn more on the official Expo Docs

Implementing JWT Authentication in Node.js

john mbugua — Fri, 05 Jul 2024 04:52:53 +0000

Page Content

Introduction to JSON Web Token
What is JSON Web Token
Why use JSON Web Token
When You Should Use JSON Web Token
The Structure of JSON Web Token
Setting Up JSON Web Token in a Node.js Application
Using JSON Web Token with a Node.js Application
Securing Routes with JSON Web Token in a Node.js Application
Conclusion

Introduction to JSON Web Token

What's up, techies? 👋In this guide, we are going to explore the magic of JSON Web Tokens (JWT) and how they can make your authentication process secured. Buckle up,and get ready to implement robust authentication in your Node.js apps. Let's get started!

What is JSON Web Token

JSON Web Token (JWT) is a compact and self-contained way to securely transmit information between parties as a JSON object. It is an open standard (RFC 7519) that ensures the information can be verified and trusted because it is digitally signed. JWTs can be signed using a secret (HMAC) or a public/private key pair (RSA or ECDSA).

Why use JSON Web Token

JWT is stateless, meaning they don't require server-side session storage, making them highly scalable. They provide a secure way to transmit information and can be easily verified. JWT are also versatile, working well for authentication, authorization, and information exchange in web applications.

When You Should Use JSON Web Token

Authorization:

JWT are ideal for authorization. Once logged in, users can access routes, services, and resources with their JWT. Single Sign-On (SSO) commonly uses JWT due to its small overhead and cross-domain capabilities.

Information Exchange:

JWT securely transmit information between parties. With digital signatures, you can verify the sender's identity and ensure the content has not been tampered with.

The Structure of JSON Web Token

JWT consists of three parts separated by dots (.):

Header

Specifies the token type (JWT) and signing algorithm (e.g., HS256). Encoded in Base64Url.

{
  "alg": "HS256",
  "typ": "JWT"
}

Payload

Contains claims about an entity (usually the user). There are three types of claims:

Registered claims: Predefined, optional claims like iss (issuer), exp (expiration), sub (subject), and aud (audience).
Public claims: Custom claims defined in the IANA JWT Registry or as a URI to avoid collisions.
Private claims: Custom claims agreed upon by parties using the token.

{
  "sub": "1234567890",
  "name": "John Doe",
  "admin": true
}

3.Signature

Verifies the token's integrity. Created using the encoded header, encoded payload, a secret, and the specified algorithm.

HMACSHA256(
  base64UrlEncode(header) + "." +
  base64UrlEncode(payload),
  secret)

The resulting JWT looks like this: xxxxx.yyyyy.zzzzz. This format is compact and easily used in web environments.

Setting Up JSON Web Token in a Node.js Application

Before we dive into implementing JSON Web Tokens (JWT) in your Node.js application, let's start with the basics, installation. To get started with JWT, you will need to install the jsonwebtoken package. This library will help you create, sign, and verify JWTs in your application.

Installation

First, you need to install the jsonwebtoken package using npm. Run the following command in your Node.js project directory

npm install jsonwebtoken

This will add the jsonwebtoken package to your project's dependencies.

Next Steps

Now that we have JWT installed, we are ready to implement it in our Node.js application. In the next section, we will cover how to use JSON Web Tokens for user authentication, including creating and verifying tokens using instance methods. Stay tuned!

Using JSON Web Token with a Node.js Application

I know this article is not about Mongoose, schemas, and models, but to effectively implement JSON Web Tokens (JWT) in our Node.js application, we will need to touch on these concepts briefly. Let's assume you have already set up your schema logic using Mongoose. For example:


const mongoose = require('mongoose');
const Schema = mongoose.Schema;


const UserSchema = new Schema({
  name: {
    type: String,
    required: [true, "Please insert your name"],
    minLength: [3, "Your name is too short"],
  },
  email: {
    type: String,
    required: [true, "Please insert your email"],
    match: [
      /^(([^<>()[\]\\.,;:\s@"]+(\.[^<>()[\]\\.,;:\s@"]+)*)|(".+"))@((\[[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\])|(([a-zA-Z\-0-9]+\.)+[a-zA-Z]{2,}))$/,
    ],
    unique: true,
  },
  password: {
    type: String,
    required: [true, "Please insert  password"],
    minLength: [8, "Password is less than 8 character"],
  },
});

Now, we will focus on creating a JWT using an instance method.

Creating a JSON Web Token Using an Instance Method

To start, we will create an instance method in our Mongoose model that will generate a JWT for a user. This instance method will be defined in the file where we have our model logic based on Mongoose.

const mongoose = require('mongoose');
const Schema = mongoose.Schema;
const jwt = require("jsonwebtoken");


const UserSchema = new Schema({
  // your schema logic code
});

UserSchema.methods.createToken = function () {
  return jwt.sign(
    { userId: this._id, userName: this.name },
    process.env.SECRET,
    { expiresIn: process.env.JWT_LIFETIME }
  );
};

Explanation

We assume your schema for example my case UserSchema is already defined in your Mongoose model. We add an instance method createToken ** to the UserSchema. This method uses **jwt.sign to create a token with the user's ID and name ** as **payload, a secret key from environment variables, and an expiration time also from environment variables.

This instance method can be called on any user document to generate a JWT, making it easy to handle user authentication in your application.

Integrating JWT with Login and Registration

Now that we have the instance method to create JWTs, let us see how we can use it in the login and registration logic of our Node.js application. Here is how you can integrate the createToken method:

User registration

During user registration, once the user is successfully created, we can generate a JWT and send it back to the client.

const UserModel = require("../models/User");
const { StatusCodes } = require("http-status-codes");
const { BadRequestError, UnauthenticatedError } = require("../errors");

const register = async (req, res) => {
  const { name, email, password } = req.body;

  // Create a new user
  const user = await UserModel.create({ ...req.body });

  // Generate a JWT
  const token = user.createToken();

  // Respond with the user name and token
  res.status(StatusCodes.CREATED).json({ user: { name: user.getName() }, token });
};

module.exports = {
  register,
};

User login

For user login, after validating the user's credentials, we can generate a JWT and send it back to the client.

const UserModel = require("../models/User");
const { StatusCodes } = require("http-status-codes");
const { BadRequestError, UnauthenticatedError } = require("../errors");

const login = async (req, res) => {
  const { email, password } = req.body;

  // Validate the request
  if (!email || !password) {
    throw new BadRequestError("Please provide email and password");
  }

  // Find the user by email
  const userLogin = await UserModel.findOne({ email });

  // If user is not found
  if (!userLogin) {
    throw new UnauthenticatedError("Invalid credentials");
  }

  // Check if the password is correct
  const isPasswordCorrect = await userLogin.comparePassword(password);

  // If the password is incorrect
  if (!isPasswordCorrect) {
    throw new UnauthenticatedError("Invalid credentials");
  }

  // Generate a JWT
  const token = userLogin.createToken();

  // Respond with the user name and token
  res.status(StatusCodes.OK).json({ user: { name: userLogin.getName() }, token });
};

module.exports = {
  login,
};

In these examples, after a user registers or logs in successfully, we generate a JWT using the createToken instance method and send it back in the response. This token can then be used by the client to authenticate subsequent requests.

Next Steps

With the instance method in place and integrated into your login and registration logic, you can now secure your routes and verify tokens in your Node.js application. In the following section, we will cover how to use this token for securing routes. Stay tuned!

Securing Routes with JSON Web Token in a Node.js Application

With our JWT creation logic in place, the next step is to secure our routes. To do this, we will create a file to store our authentication logic and use it as middleware in our application.

Creating Middleware for Securing Routes

We will create a middleware function that will verify the JWT in incoming requests. This middleware will check the authorization header, verify the token, and attach the user information to the request object if the token is valid.

const UserModel = require("../models/User");
const jwt = require("jsonwebtoken");
const { UnauthenticatedError } = require("../errors");

const auth = async (req, res, next) => {
  const authHeader = req.headers.authorization;

  if (!authHeader || !authHeader.startsWith("Bearer ")) {
    throw new UnauthenticatedError("Authentication invalid");
  }

  const token = authHeader.split(" ")[1];

  try {
    const payload = jwt.verify(token, process.env.SECRET);
    req.user = { userId: payload.userId };
    next();
  } catch (err) {
    console.log(err);
    throw new UnauthenticatedError("Authentication invalid");
  }
};

module.exports = auth;

Using the Middleware

Now that we have our authentication middleware, we can use it to secure our routes in various ways. Here are three different ways to apply the middleware:

1. Applying Middleware to Specific Routes

const express = require('express');
const router = express.Router();
const auth = require('../middleware/auth');
const { getUserInfo } = require('../controllers/userController');

router.get('/user-info', auth, getUserInfo);

module.exports = router;

2. Applying Middleware to All Routes in a Router

const express = require('express');
const router = express.Router();
const auth = require('../middleware/auth');
const { getUserInfo, getJobs } = require('../controllers/userController');

router.use(auth);

router.get('/user-info', getUserInfo);
router.get('/jobs', getJobs);

module.exports = router;

3. Applying Middleware in the Main File

const express = require('express');
const app = express();
const auth = require('./middleware/auth');
const jobRoutes = require('./routes/jobRoutes');

app.use("/api/v1/jobs", auth, jobRoutes);

Conclusion

In this article, we covered the basics of JSON Web Tokens (JWT) and how to use them in a Node.js application. We discussed what JWT is, why and when to use it, and how to implement it for user authentication. We also looked at securing routes using middleware in different ways. With these steps, you can enhance the security of your Node.js applications by ensuring only authenticated users can access protected resources.

For more detailed information on JSON Web Tokens, you can visit the jsonwebtoken documentation.

How to Use Bcrypt for Password Hashing in Node.js

john mbugua — Mon, 01 Jul 2024 04:43:28 +0000

Page Content

Introduction to Bcrypt
Getting Started with Bcrypt
Using Bcrypt with Mongoose Pre Save Middleware
Implementing Password Comparison with Instance Methods in a Nodejs and Mongoose Application
Password Verification in Nodejs Using Bcrypt with Mongoose Instance Methods
Conclusion

Introduction to Bcrypt

Securing user data has become paramount, and one of the most critical aspects of this security is password protection. This is where password hashing comes into play.

Password hashing: is a process of transforming a plain text password into a fixed length string of characters, which is typically a cryptographic hash.

Bcrypt: A library to help you hash passwords.

Getting started with Bcrypt

To start using bcrypt in your Node.js application, you first need to install it. Below are the instructions for installing bcrypt:

npm install bcrypt

Using Bcrypt with Mongoose Pre-Save Middleware

In this section, we will explore how to use bcrypt with Mongoose pre save middleware to securely hash passwords before saving them to the database. This approach ensures that plain text passwords are never stored in the database, enhancing the security of your Node.js application.

Before we begin, make sure you have installed both mongoose and bcrypt in your project:

npm install mongoose bcrypt

Importing required modules

const mongoose = require('mongoose');
const bcrypt = require('bcrypt');

The pre save middleware is a function that runs before a document is saved to the database. This method it is an important way to hash the user's password:

// pre save middleware
UserSchema.pre("save", async function () {
  //    hashing the password
  const salt = await bcrypt.genSalt(15);
  this.password = await hash(this.password, salt);
});

Implementing Password Comparison with Instance Methods in a Node.js and Mongoose Application

In this section, we will discuss how to use instance methods in Mongoose to compare passwords using bcrypt. This approach is particularly useful for verifying user credentials during the login process. Here is the code for the instance method, followed by an explanation of how it works:

UserSchema.methods.comparePassword = async function (mainpassword) {
  return await bcrypt.compare(mainpassword, this.password);
};

Explanation

Instance Method Definition

UserSchema.methods.comparePassword: This line defines a new instance method called comparePassword on the Mongoose schema UserSchema. Instance methods are functions that operate on individual documents instances of the model.

Async Function

async function (mainpassword) { ... } : The method is defined as an asynchronous function that takes mainpassword as an argument. mainpassword represents the plain text password that needs to be compared with the stored hashed password.

Password Comparison

return await bcrypt.compare(mainpassword, this.password); : This line uses bcrypt compare function to compare the provided plain text password mainpassword with the hashed password stored in the current document this.password . The compare function returns a promise that resolves to true if the passwords match and false otherwise.

Password Verification in Node.js Using Bcrypt with Mongoose Instance Methods

In this section, we will focus on how to use the comparePassword instance method within the login logic of a Node.js application to securely verify user passwords using bcrypt. Please note that the validation and error handling in this example are not the primary focus and are included for completeness.

const login = async (req, res) => {
  const { email, password } = req.body;

  //   validation
  if ((!email, !password)) {
    throw new BadRequestError("Please provide email and password");
  }

  const userLogin = await UserModel.findOne({ email });

  if (!userLogin) {
    throw new UnauthenticatedError("Invalid credentials");
  }

  const isPasswordCorrect = await userLogin.comparePassword(password);

  if (!isPasswordCorrect) {
    throw new UnauthenticatedError("Invalid credentials");
  }

  const token = userLogin.createToken();
  res
    .status(StatusCodes.OK)
    .json({ user: { name: userLogin.getName() }, token });
};

Explanation of comparePassword Usage

Finding the User

The code first retrieves the user document from the database using UserModel.findOne({ email })
If the user is not found, it throws an error indicating invalid credentials.

Comparing Passwords

const isPasswordCorrect = await userLogin.comparePassword(password);

This line uses the comparePassword instance method defined on the user schema.
The method compares the provided plain text password password with the hashed password stored in the database userLogin.password .
comparePassword uses bcrypt compare function/method and returns true if the passwords match, or false otherwise.

Handling Incorrect Passwords

If the password comparison fails !isPasswordCorrect , an error is thrown indicating invalid credentials.

Generating and Returning a Token

If the password comparison succeeds, a token is generated using userLogin.createToken()
The response includes the user name and the generated token

Conclusion

In this article, we explored how to use bcrypt in a Node.js application with Mongoose to securely hash and verify passwords. We covered the installation of bcrypt, the implementation of password hashing using Mongoose pre save middleware, and the use of Mongoose instance methods for password comparison during login. By following these steps, you can enhance the security of your application authentication system, ensuring that user passwords are properly protected.

Getting Started with Mongoose

john mbugua — Fri, 28 Jun 2024 10:35:35 +0000

PAGE CONTENT

Introduction to Mongoose
Connecting to the database
Creating Models and Schemas.
Using Your Model in Controller Functions.
Conclusion.

Introduction to Mongoose

Mongoose is an ODM (Object Data Modeling) library designed to streamline the interaction between your MongoDB database and Node.js applications.It is designed to work with asynchronous environments and offers a powerful set of features that simplify data manipulation and validation.

Connecting to the database

Before diving into Mongoose, you need to establish a connection to your MongoDB database. Here’s a step-by-step guide to get you started:

1.Installing Mongoose

npm install mongoose

2. Importing Mongoose and creating a connection file

Create a file called connect.js and place the connection logic there. This function returns a promise, which allows you to handle the connection success or failure in your main file.:

//connect.js
const mongoose = require('mongoose')

const connectDB = (url) => {
  return mongoose.connect(url)
}

module.exports = connectDB

3. Use the Connection in Your Main File:

In your main application file for example app.js, import and use the connection logic:

//app.js
require('dotenv').config();
const express = require('express');
const app = express();

// connectdb
const connectDB = require("./db/connect"); //Add the path to the connection logic file.

// Get the MongoDB connection string from environment variables
const MONGODB_STRING = process.env.MONGODB_STRING;

app.get("/", (req, res) => {
  res.send("Hello Heroku app");
});


const port = process.env.PORT || 4040;

// Function to start the server
const start = async () => {
  try {
    // Connect to the database. Pass the MongoDB String as an arguement of the connectDB function.
    await connectDB(MONGODB_STRING)
    app.listen(port, () =>
      console.log(`Connected to the database and listening on port ${port}...`)
    );
  } catch (error) {
    console.log(error);
  }
};

start();

Explanation

Environment Variables: Use dotenv to load MONGODB_STRING and PORT.
Database Connection: connectDB in db/connect.js in my case returns a promise for the database connection.
Async/Await: Use async/await in app.js to ensure the server starts only after a successful database connection.
Error Handling: Handle connection errors with a try/catch block.

Creating Models and Schemas

In Mongoose, models and schemas are fundamental for defining and interacting with data in MongoDB.

Schema: Defines the structure of your data. It specifies the shape that each document (instance) will have in the database. Think of it as a blueprint.
Model: Once you have a schema, you compile it into a model. A model is a JavaScript class that represents a collection in MongoDB. It is responsible for creating and reading documents from the database.
Document: An instance of a model is called a document. Each document is a record in your MongoDB collection, based on the schema you defined.

Create a file called job.js and place to place your logic there.

const mongoose = require("mongoose");
const Schema = mongoose.Schema;

const JobSchema = new Schema(
  {
    company: {
      type: String,
      required: [true, "Please the field can't be empty"],
    },
    position: {
      type: String,
      required: [true, "Please the field can't be empty"],
    },
    status: {
      type: String,
      required: [true, "Please the field can't be empty"],
      enum: ["interview", "declined", "pending", "accepted"],
      default: "pending",
    },

  },
  { timestamps: true }
);

const JobModel = mongoose.model("Job", JobSchema);

module.exports = JobModel;

Explanation

Schema Definition: *JobSchema * defines fields company, position, status _ and their types. It includes validations (required, enum) and a default value _default.

Model Creation: *JobModel * is created using mongoose.model(), linking Job as the collection name in MongoDB.

Using Your Model in Controller Functions

In an Express application using Mongoose, it's common to separate your model definitions from your controller logic. This promotes modularity and improves code organization. So you can create a file and place your logic there for controller functions.

Controller Functions: These functions getAllJobs, createJob, getJob, updateJob, deleteJob handle CRUD operations for jobs. They interact with the imported (JobModel) to perform database operations based on HTTP requests.
You will export this controller function and map them to the routes.

const JobModel = require("../models/Job");
const { StatusCodes } = require("http-status-codes");
const { BadRequestError, NotFoundError } = require("../errors/bad-request");

const getAllJobs = async (req, res) => {

  const jobs = await JobModel.find({ createdBy: req.user.userId });
  res.status(StatusCodes.CREATED).json({ jobs });
};

const createJobs = async (req, res) => {
  req.body.createdBy = req.user.userId;
  const jobs = await JobModel.create(req.body);

  res.status(StatusCodes.CREATED).json({ jobs });
};

const getJob = async (req, res) => {
  const {
    user: { userId },
    params: { id: job_id },
  } = req;

  const job = await JobModel.findOne({ _id: job_id, createdBy: userId });
  if (!job) {
    throw new NotFoundError(`No job with id: ${job_id}`);
  }

  res.status(StatusCodes.OK).json({ job });
};

const updateJob = async (req, res) => {
  const {
    body: { company, position },
    params: { id: job_id },
    user: { userId },
  } = req;

  if (company === "" || position === "") {
    throw new BadRequestError("company and position cannot be found");
  }

  const job = await JobModel.findByIdAndUpdate(
    { _id: job_id, createdBy: userId },
    req.body,
    { new: true, runValidators: true }
  );

  res.status(StatusCodes.OK).json({ job });
};

const deleteJob = async (req, res) => {
  const {
    params: { id: job_id },
    user: { userId },
  } = req;

  const job = await JobModel.findByIdAndDelete({
    _id: job_id,
    createdBy: userId,
  });

  if (!job) {
    throw new NotFoundError(`No user with id: ${job_id}`);
  }

  res.status(StatusCodes.OK).json({ msg: "Job deleted successfully" });
};

module.exports = {
  getAllJobs,
  createJobs,
  getJob,
  updateJob,
  deleteJob,
};

Import Controller Functions:

Import controller functions getAllJobs, createJob, getJob, updateJob, deleteJob from the path your controller function login is located.

Mapping Routes: Each HTTP method GET, POST, PUT, DELETE is mapped to its corresponding controller function getAllJobs, createJob, getJob, updateJob, deleteJob.

const express = require('express');
const router = express.Router();
const auth = require("../middleware/authentication");

const {
  getAllJobs,
  getJob,
  createJobs,
  updateJob,
  deleteJob,
} = require("../controllers/jobs");

router.use(auth);
router.route('/').get(getAllJobs).post(createJobs);
router.route('/:id').get(getJob).patch(updateJob).delete(deleteJob);


module.exports = router;

Importing your router in your main file.

In an Express application, routers are used to organize and handle different sets of routes. Here is how you integrate a router into your main application file.

Import the router in your main file (app.js)

const jobRoutes = require("./routes/jobs");

Applying Router Middleware in your main file (app.js)

//app.js
require('dotenv').config();
const express = require('express');
const app = express();

//imported router
const jobRoutes = require("./routes/jobs");
// connectdb
const connectDB = require("./db/connect"); //Add the path to the connection logic file.

// Get the MongoDB connection string from environment variables
const MONGODB_STRING = process.env.MONGODB_STRING;

app.get("/", (req, res) => {
  res.send("Hello Heroku app");
});


const port = process.env.PORT || 4040;

// Function to start the server
const start = async () => {
  try {
    // Connect to the database. Pass the MongoDB String as an arguement of the connectDB function.
    await connectDB(MONGODB_STRING)
    app.listen(port, () =>
      console.log(`Connected to the database and listening on port ${port}...`)
    );
  } catch (error) {
    console.log(error);
  }
};

start();

Conclusion

Integrating Mongoose in Node.js simplifies MongoDB interactions through schema based modeling, enhancing data structure and validation. Explore more in the mongoosejs.com official documentation.

Getting started with Git and Github

john mbugua — Sat, 30 Apr 2022 15:45:52 +0000

Intro

version control

Version control is also known as revision control /source control is a class of systems responsible for managing changes to your files.

Types of version control system

Centralize version control systems
Distributed version control systems

Centralized version control system

CVCS have only one central repository. Repository is basically a server which all the file and history are stored. The machine can access the repository via LAN and WAN.

Example of CVCS:

Concurrent version system (CVS)
Subversion (SVN)

Distributed version control system

DVCS don't require a central server that contain repository. Every user has its own repository called local repository.

Example of DVCS:

GIT
Bit-keeper

What is git ?

GIT is a decentralized version control system used to keep changes of your file.

GIT was developed by Linus Torvalds in 2005 for efficient code management and version control of their project. Understanding basic commands of git could help you in storing your projects in your local repository and pushing them into your remote repository.

Git installation

.Windows

Download git for windows

.Mac

Download git for mac

.Linux (Debian)

$sudo apt-get install git

Git commands

The following are basics commands of git.

git config

This command is used to set user configuration such as user-name and user-email as shown below:

git init

This is one of the common git command you will be using. Its used to initialize local git repository.

git add

The command git add is used to add the file into local repository for example below the .index will be added to local repository:

git status

This git status command is used to check status of working tree. Below you see three file which are untracked:

git commit

The git commit command is used to commit in the staging area. The committed changes will now go to remote repository. Example:

git push

Once the files have been committed the git push command is used to push the files to remote repositories:

git pull

The command git pull is used to fetch/merge content in remote repository into local repository:

git pull

git clone

This command is used to download existing git repository into your local repository. For example below the git clone command will download the files from existing remote repository to local repository(basics of git):

git rm

The command git rm will delete or remove the file from repository: Below we can see the file .index removed:

git branch

This command is used to create a new branch. Example git branch will create new branch called myapp:

git checkout

This command help you to navigate from one branch to another. Example we used git checkout to navigate from master branch to myapp branch:

git merge

The git merge is used to integrate two branches together. It will merge one branch to another active branch. Below we have merge myapp to master branch:

DEV Community: john mbugua

[Boost]

Local vs Cloud Builds in Expo: What expo prebuild and eas build Really Do

john mbugua ・ Feb 7

Local vs Cloud Builds in Expo: What expo prebuild and eas build Really Do

Introduction

What is Continuous Native Generation (CNG)?

Local Builds vs EAS Builds

Local Builds (Dev Client Builds)

A quick but important note about modifying native files

EAS Build (Cloud Builds)

How EAS Build works with CNG

What EAS Build is really good at

The key takeaway

Happy coding

React Render vs Commit: What Actually Happens (DOM vs React Native)

React Render vs Commit: What Actually Happens (DOM vs React Native)

What causes a component to render?

The two-phase model: render phase & commit phase

Render phase

1) JSX becomes React elements

2) Current tree vs Work-in-progress tree

3) Reconciliation

4) Output of render phase

Commit phase

React Native commit

React DOM commit

Unnecessary renders

The setup

What happens in the render phase (and why children get involved)

The “unnecessary render” moment

Why unnecessary renders matter in profiling

[Boost]

React Native Optimization: Stop Recreating Functions in Large Lists (FlatList, Flashlist, LegendList...)

React Native Optimization: Stop Recreating Functions in Large Lists (FlatList, Flashlist, LegendList...)

Why inline functions hurt list performance

Why does that matter?

Memoize renderItem with useCallback

Cool — but what about row actions?

The common trap: inline callbacks per row

Conclusion

[Boost]

Two Apps, One Device: Dynamic app.config.(js|ts) in Expo

Two Apps, One Device: Dynamic app.config.(js|ts) in Expo

Table of contents

Introduction

What is app.config.(js|ts), app.json?

A quick story

Why this matters

Conclusion

Implementing JWT Authentication in Node.js

Page Content

Introduction to JSON Web Token

What is JSON Web Token

Why use JSON Web Token

When You Should Use JSON Web Token

The Structure of JSON Web Token

Setting Up JSON Web Token in a Node.js Application

Using JSON Web Token with a Node.js Application

Integrating JWT with Login and Registration

Securing Routes with JSON Web Token in a Node.js Application

Conclusion

How to Use Bcrypt for Password Hashing in Node.js

Page Content

Introduction to Bcrypt

Getting started with Bcrypt

Using Bcrypt with Mongoose Pre-Save Middleware

Importing required modules

Implementing Password Comparison with Instance Methods in a Node.js and Mongoose Application

Explanation

Password Verification in Node.js Using Bcrypt with Mongoose Instance Methods

Explanation of comparePassword Usage

Conclusion

Getting Started with Mongoose

PAGE CONTENT

Introduction to Mongoose

Connecting to the database

1.Installing Mongoose

2. Importing Mongoose and creating a connection file

3. Use the Connection in Your Main File:

What is `app.config.(js|ts), app.json`?