DEV Community: Abdalla Emad

Sharing State Across Packages and Apps in a React Monorepo (Web + Mobile)

Abdalla Emad — Tue, 17 Mar 2026 01:20:33 +0000

Article

Introduction

If you're building a modern app, chances are you’re not just building one thing.

You might have:

a web app (Next.js)
a mobile app (React Native)
shared UI packages
multiple internal modules

And if you're using a monorepo (with tools like Turborepo, Nx, or Lerna), you’ll quickly run into this problem:

How do you share state across packages… and across apps?

The Real Problem

Sharing state inside a single React app is easy.

Sharing it across:

packages
apps
platforms (web + mobile)

is where things break down.

You start dealing with:

duplicated stores
inconsistent state
complex syncing logic
unnecessary API calls

Common Approaches (and Their Limits)

Prop drilling / Context

Only works inside one React tree.

Shared packages

You can move state into a shared package…
but now everything is tightly coupled.

Redux / Zustand across apps

Tools like Redux Toolkit or Zustand work great inside a single app.

But across packages and apps?

You end up writing a lot of glue code.

APIs for syncing state

Works… but:

adds latency
increases complexity
feels like overkill for local state

What We Actually Want

Something like this:

const auth = getBridge("auth")

From:

any package
any app
web or mobile

Same state. Same source of truth.

Introducing `shared-state-bridge`

I built shared-state-bridge to solve this exact problem.

It’s a cross-package + cross-app state store for React monorepos.

What Makes It Different

1. Share state across packages

Create a named store once:

createBridge("auth", { user: null })

Access it anywhere:

getBridge("auth")

No prop drilling. No wiring.

2. Share state across apps (Web + Mobile)

This is where it gets powerful.

You can sync state between:

Next.js apps
React Native apps
multiple clients

Using built-in WebSocket sync.

That means:

login state shared between web and mobile
real-time updates across apps
consistent user experience everywhere

3. React 18 optimized

Uses useSyncExternalStore for:

fine-grained updates
minimal re-renders

4. Persistence built-in

Works out of the box with:

localStorage (web)
AsyncStorage (React Native)

5. Tiny and dependency-free

~1.2 KB core
zero dependencies
fully tree-shakeable

6. Full TypeScript support

Everything is typed:

state
setters
selectors
plugins

Why This Matters

Modern apps are no longer single-platform.

You’re building:

web + mobile
multiple frontends
shared ecosystems

And state becomes fragmented across:

apps
packages
environments

shared-state-bridge gives you:

One shared state layer across everything.

How It Works (Conceptually)

Each state is registered globally by name:

createBridge("auth", initialState)

Then resolved anywhere:

getBridge("auth")

Internally, it uses Symbol.for so it works even when:

multiple builds exist
packages are duplicated in node_modules

Comparison

Feature	shared-state-bridge	Zustand	Redux Toolkit
Cross-package state	✅	❌	❌
Cross-app (web + mobile)	✅	❌	❌
Real-time sync	✅	❌	❌
Boilerplate	Minimal	Minimal	High

When You Should Use It

This is perfect if you have:

a React monorepo
multiple apps (web + mobile)
shared runtime state
real-time requirements

Try It Out

Check it here:

https://www.npmjs.com/package/shared-state-bridge

Final Thoughts

State management is hard.

Cross-package state is harder.

Cross-app state (web + mobile) is where things usually fall apart.

Instead of adding more complexity, a better approach is:

make state globally accessible — across packages and apps.

Feedback

I’d love to hear:

how you're handling cross-app state
whether you've faced this issue
what you think about this approach

Debugging Webhooks During Development: A Simple Workflow

Abdalla Emad — Tue, 17 Mar 2026 01:01:09 +0000

Article

Introduction

Webhooks are everywhere.

Modern platforms rely on webhooks to send real-time events between services.

Examples include:

payment events
repository updates
messaging events
automation triggers

If you've ever worked with platforms like GitHub, Stripe, or Slack, you've probably used webhooks.

But debugging them during development can be frustrating.

The Problem with Webhooks

When building webhook integrations, developers often face these issues:

events are sent to local servers
requests are hard to inspect
payloads can be large JSON objects
debugging requires logging everything

When something breaks, it's difficult to see exactly what payload was sent.

What Developers Usually Do

Most developers end up doing things like:

exposing a local server
printing request logs
manually inspecting JSON payloads

But this isn't always convenient.

A much easier solution is using a webhook inspection endpoint.

Webhook Inspection Endpoints

Webhook inspection tools give you a temporary URL that receives requests and shows you the payload.

When an event is sent, you can immediately see:

request headers
request body
JSON payload
timestamps

This makes debugging webhook integrations much easier.

Example Webhook Payload

A webhook request might look like this:

{
  "event": "payment.succeeded",
  "amount": 100,
  "currency": "USD"
}

Without inspection tools, you would need to log this manually.

With a webhook debugger, you can see the full payload instantly.

A Simple Webhook Debugging Tool

To simplify webhook debugging, I built a small tool called Outworx Hooks.

It gives you an instant webhook URL where incoming requests are captured and displayed in real time.

You can:

inspect webhook payloads
view headers and bodies
debug API integrations
test webhook triggers

The goal was to create a simple and lightweight webhook testing workflow.

You can try it here:

https://hooks.outworx.io

When This Is Useful

Webhook inspection tools are useful when working with services like:

payment systems
CI/CD events
automation platforms
Git repository events

Instead of guessing what was sent, you can see the exact request instantly.

Final Thoughts

Webhooks are powerful, but debugging them shouldn't be difficult.

Using a webhook inspection endpoint can save a lot of time during development.

If you're building webhook integrations, feel free to try:

https://hooks.outworx.io

I'd love feedback from developers working with APIs and integrations.

How to Generate Interactive API Documentation from OpenAPI in Under 60 Seconds

Abdalla Emad — Tue, 17 Mar 2026 00:54:08 +0000

Article

Introduction

If you build APIs, you already know how important good documentation is.

The problem is that maintaining API documentation manually is painful.
It quickly gets outdated, requires extra work, and often ends up being ignored by developers.

Luckily, tools like OpenAPI and Swagger allow you to describe your API in a structured way so documentation can be generated automatically.

In this article, I'll show you how you can turn an API specification into interactive documentation with a live API playground in less than a minute.

Why API Documentation Is Hard

Most teams struggle with API docs because:

Docs are written manually
They become outdated quickly
Developers forget to update them
Setting up documentation platforms can be complicated

When documentation drifts away from the actual API, developers stop trusting it.

That's why spec-driven documentation became popular.

Using an API Specification

Instead of writing docs manually, many teams define their APIs using specifications like:

OpenAPI
Swagger
GraphQL schemas

These specs describe:

endpoints
parameters
responses
authentication
request formats

Once you have a spec, documentation can be generated automatically.

Turning a Spec into Interactive Documentation

With a documentation generator, you can convert a spec into a full developer portal that includes:

interactive endpoint documentation
request/response examples
live API playground
code snippets
hosted documentation pages

This allows developers to test APIs directly from the docs, which improves the developer experience dramatically.

Example Workflow

The workflow is surprisingly simple.

1️⃣ Generate or export your API spec
2️⃣ Upload the spec
3️⃣ The documentation is generated automatically

For example, this OpenAPI snippet:

{
  "paths": {
    "/users": {
      "get": {
        "summary": "Get all users"
      }
    }
  }
}

can instantly become a full interactive documentation page.

Instant API Docs

To simplify this workflow, I built a small tool called Outworx Docs.

It allows you to:

Upload an OpenAPI / Swagger / GraphQL spec
Generate interactive documentation instantly
Get a hosted documentation page
Enable a live API playground

The goal was simple:

spec → live documentation in under 60 seconds

You can try it here:

https://docs.outworx.io

Why Interactive Docs Matter

Interactive documentation dramatically improves developer experience because developers can:

test endpoints directly
explore request formats
copy ready-to-use code snippets

This reduces integration time and helps teams adopt APIs faster.

Final Thoughts

Spec-driven documentation is quickly becoming the standard for API development.

If you already use OpenAPI or Swagger, generating interactive documentation is one of the easiest ways to improve your API experience.

If you're interested in trying it out, feel free to check out:

https://docs.outworx.io

And I'd love to hear feedback from developers building APIs.

DEV Community: Abdalla Emad

Sharing State Across Packages and Apps in a React Monorepo (Web + Mobile)

Article

Introduction

The Real Problem

Common Approaches (and Their Limits)

Prop drilling / Context

Shared packages

Redux / Zustand across apps

APIs for syncing state

What We Actually Want

Introducing shared-state-bridge

What Makes It Different

1. Share state across packages

2. Share state across apps (Web + Mobile)

3. React 18 optimized

4. Persistence built-in

5. Tiny and dependency-free

6. Full TypeScript support

Why This Matters

How It Works (Conceptually)

Comparison

When You Should Use It

Try It Out

Final Thoughts

Feedback

Debugging Webhooks During Development: A Simple Workflow

Article

Introduction

The Problem with Webhooks

What Developers Usually Do

Webhook Inspection Endpoints

Example Webhook Payload

A Simple Webhook Debugging Tool

When This Is Useful

Final Thoughts

How to Generate Interactive API Documentation from OpenAPI in Under 60 Seconds

Article

Introduction

Why API Documentation Is Hard

Using an API Specification

Turning a Spec into Interactive Documentation

Example Workflow

Instant API Docs

Why Interactive Docs Matter

Final Thoughts

Introducing `shared-state-bridge`