Technical Analysis Report: MQTT Device

Integration in React Web Application

Date: December 20, 2025
Subject: Architecture Comparison for Integrating MQTT Device Management UI with
React Web Platform
Prepared for: Executive Review

Executive Summary
This report evaluates three architectural approaches for integrating an existing Flutter
mobile application (with MQTT device control capabilities) into a larger React-based web
platform. The analysis examines functional feasibility, performance implications,
development timeline, and long-term maintainability for each approach.
Key Finding: Pure React implementation with native MQTT over WebSockets is
recommended for production; Flutter Web embedded via iframe is acceptable as a
pragmatic short-term solution if existing code reuse is prioritized over performance
optimization.

Problem Statement
Business Context
An organization has developed a Flutter mobile application that connects to MQTT IoT
devices and provides real-time device control and monitoring. The application is being
integrated into a larger React-based web platform. Three primary technical solutions are
under evaluation:
1. Option A: Pure React client with MQTT over WebSockets
2. Option B: Flutter Web embedded in React via iframe with postMessage
communication
3. Option C: Flutter Web as standalone hosted application with routing link from React

Integration Requirements
Support MQTT device connectivity without server-side gateway
Client-side device management and state synchronization
Seamless integration with existing React site styling and navigation
Performance-friendly for end users and infrastructure
Technical Analysis
Option A: Pure React with MQTT Over WebSockets
Architecture Overview
React application directly connects to MQTT broker using JavaScript MQTT library (mqtt.js
or react-mqtt-client). All device logic, state management, and UI are implemented natively
in React using TypeScript and modern state management patterns (Zustand, Recoil, Redux,
etc.)[web:47][web:48][web:49].

How It Works
React component establishes WebSocket connection to MQTT broker
Subscriptions to device topics maintained in React state
State updates trigger UI re-renders automatically
Device commands published directly from React event handlers
Connection status and errors handled through React context or centralized store

Pros
Bundle Size: Minimal; only MQTT.js (~50KB gzipped) added to React bundle
Performance: Single JavaScript runtime, zero inter-process communication
overhead
User Experience: Fast initial load (~2-3s for typical React app), responsive
interaction
Development Velocity: Reuses existing React ecosystem patterns; developers
familiar with React can implement MQTT logic quickly
Integrated Navigation: Seamless routing, styling consistency, shared state
management across entire site
SEO & Accessibility: Native React components support standard HTML semantics
and accessibility attributes
Debugging: Single DevTools context; full visibility into all state changes and network
requests
Maintenance: Single technology stack (JavaScript/TypeScript); easier for teams to
maintain long-term

Cons
Code Rewrite Required: Existing Dart/Flutter device logic must be translated to
TypeScript/JavaScript; estimated effort 20-40% of original project size depending on
complexity
Dart Knowledge Becomes Obsolete: Team loses investment in Dart ecosystem
knowledge for this feature
Testing Overhead: New unit tests and integration tests must be written; cannot
directly reuse Flutter test suite
Technical Considerations
MQTT Broker Setup:
Broker must expose WebSocket endpoint (e.g., wss://mqtt-broker.example.com:8883)
Requires proper TLS/SSL configuration for production
CORS headers must allow browser connections if cross-domain
Security & Authentication:

Credentials (username, password, tokens) must be managed securely; recommend

JWT tokens with server-side validation
Consider proxy layer to validate and refresh tokens rather than embedding long-
lived credentials in browser
Performance Metrics (typical):
Page load: 1.5-2.5 seconds (React) + 200-500ms (MQTT connection establishment)
Message delivery latency: 50-200ms (typical MQTT + network)
Memory footprint: 15-25MB (React + MQTT client + UI state)

Use Case Suitability

✓ Recommended for: Production web applications, public sites, large user bases, long-term
maintenance
✗ Not ideal for: Rapid prototyping, minimal upfront engineering budget

Option B: Flutter Web Embedded in React via iframe + postMessage

Architecture Overview
Flutter Web application is built separately and embedded within React page using an
<iframe>. Communication between React (parent) and Flutter Web (child) is managed
through window.postMessage() API for bidirectional messaging[web:70][web:83][web:86].

How It Works
React Side:
1. Render iframe element pointing to Flutter Web build (<iframe src="https://device-
control.app/flutter.html">)
2. Listen for message events from iframe
3. Send device commands via iframe.contentWindow.postMessage({ type:
'updateDevice', payload: {...} })
Flutter Side:

1. Initialize JavaScript interop listener to receive messages from parent

2. Forward incoming messages to Dart code via JS bridge
3. Handle MQTT connection and device control using existing mqtt_client Dart
package
4. Send status updates back to parent via window.parent.postMessage()
Pros
Code Reuse: Existing Flutter MQTT logic, UI, and state management can be reused
with minimal changes
Rapid Time-to-Market: Avoids complete rewrite; estimated effort 5-15% (mostly
WebSocket adaptation)
Isolation: Flutter app runs in separate browsing context; reduces risk of conflicts
with React code
Fallback Option: If React integration fails, can fall back to standalone Flutter app
Team Continuity: Dart developers can continue maintaining MQTT/device logic
without learning JavaScript

Cons
Bundle Size & Load Time: Flutter Web engine (~2.5-3.5MB gzipped) loads on every
page visit[web:93][web:101]
Full page load time: 4-8 seconds (React 2s + Flutter 4-6s)
Slower user experience compared to pure React
Memory Overhead: Separate V8 isolate for Flutter; 20-30% higher memory usage
than pure React solution[web:112][web:115]
Integration Complexity: Communication via postMessage adds latency and
requires careful error handling
Message passing introduces 5-15ms additional latency per message[web:87]
[web:89]
Risk of desynchronization if parent and child state diverge
Styling & Layout Challenges:
Flutter styling isolated; cannot directly share React CSS variables or theme
system
Responsive iframe sizing requires custom JavaScript handling
Font rendering may differ from native React components
Development Friction:
Two separate build processes and deployment artifacts
Debugging across iframe boundary requires coordinated DevTools usage
postMessage contract must be maintained; breaking changes affect both sides

Technical Considerations
Security in postMessage:
Must validate event.origin to prevent XSS attacks from malicious domains
Avoid sending sensitive credentials through postMessage; prefer token-based auth
Ensure CSRF protection for any state-changing operations
Message Protocol Example:

// React → Flutter
{
type: 'command',
payload: {
deviceId: 'dev_123',
action: 'turnOn',
parameters: { intensity: 75 }
}
}
// Flutter → React
{
type: 'status',
payload: {
deviceId: 'dev_123',
state: 'on',
intensity: 75,
timestamp: 1734697200000
}
}

Performance Metrics (typical):

Page load: 2-3 seconds (React) + 4-6 seconds (Flutter engine + app)
Message latency: 5-15ms per round-trip
Memory footprint: 35-50MB (includes separate V8 context for Flutter)
Network: ~3.5MB additional download on first visit

Use Case Suitability

✓ Recommended for: Short-term integration, time-constrained projects, teams with strong
Dart expertise
✗ Not ideal for: User-facing SaaS products, mobile web users, bandwidth-constrained
networks

Option C: Flutter Web Standalone with Routing Link

Architecture Overview
Flutter Web application is built and deployed as independent domain or subpath. React site
links to Flutter app via standard navigation (anchor tag or programmatic navigation). No
cross-iframe communication; users transition between React and Flutter contexts.

How It Works
React site hosts main navigation and public-facing content
Dedicated route (e.g., /device-control) serves Flutter Web build
User navigates from React to Flutter context via link
Browser context switches; no shared state between React and Flutter

Pros
Simplicity: No integration complexity; treated as external application
Code Reuse: Full Flutter app reused without modification
Independent Scaling: Flutter app can scale separately from React infrastructure
Clear Boundaries: Separate concerns; reducing coupling between systems
Cons
Poor User Experience: Hard navigation break; page reload, loss of context
No Shared State: Cannot synchronize state between React and Flutter
Navigation Friction: Requires explicit links/buttons for transitions
Inconsistent Branding: Flutter styling/navigation separate from React site
Development Complexity: Maintains two separate deployment pipelines and
domains

Use Case Suitability

✗ Not recommended for: Integrated web applications, feature-critical components
✓ May work for: Completely separate product offerings, documentation sites

Comparative Analysis Matrix

 Option B
Option A Option C
Aspect (Flutter
(Pure React) (Standalone)
iframe)
Initial Load 1.5–2.5s (with
1.5–2.5s 6–9s
Time context switch)
Message N/A (separate
<5ms 5–15ms
Latency contexts)
15–25MB +
Memory Usage 15–25MB 35–50MB Flutter
overhead
Bundle Size
~50KB ~3.5MB ~3.5MB
Added
High
Development Low (reuse Low (no
(rewrite
Effort code) integration)
logic)
Time to
2–4 weeks 3–5 days 2–3 days
Production
Long-term
Maintainabilit Excellent Good Fair
y
User
Excellent Good Poor
Experience
Code Reuse
Low High High
Potential
Styling Requires
Seamless Separate
Integration workarounds
State
Native Via
Synchronizatio None
(React state) postMessage
n
Risk Assessment
Option A: Pure React

Likeli Imp
Risk Mitigation
hood act
Rewrite effort Mediu Detailed code audit; break into
High
exceeds estimate m sprints; parallel development
JavaScript MQTT Medi Evaluate mqtt.js + alternatives
Low
library limitations um early; create PoC
WebSocket broker Medi Use managed MQTT service
Low
setup complexity um (EMQX Cloud, AWS IoT Core)
Team learning Training time already
Low Low
curve (JavaScript) budgeted; JS is approachable

Option B: Flutter iframe

Likel
Imp
Risk ihoo Mitigation
act
d
Establish versioned
postMessage contract Medi Hig
message schema;
breaks um h
comprehensive testing
Performance
Medi Med Message batching; rate
bottleneck with high-
um ium limiting; load testing
frequency messages
Establish iframe styling
Styling inconsistencies Medi
Low guidelines; CSS framework
emerge um
coordination
Test in Chrome, Firefox,
Cross-browser Med
Low Safari, Edge; consider
compatibility issues ium
polyfills
Option C: Standalone

Likeli Imp
Risk Mitigation
hood act
Poor user adoption Reconsider this approach;
High High
due to UX friction not recommended

Recommendation
Primary Recommendation: Option A (Pure React)
Rationale:

1. Production-Ready Performance: Bundle size, load time, and latency meet modern
web standards for SaaS and consumer applications
2. Long-Term Maintainability: Single technology stack reduces technical debt and
makes hiring/training simpler
3. Future Flexibility: Native React implementation allows easier adoption of new
features, third-party integrations, and performance optimizations
4. User Experience: Seamless integration with React site; consistent styling, instant
responsiveness, professional appearance
5. Cost of Ownership: Lower support burden and faster feature velocity offset initial
rewrite investment
Implementation Path:
Phase 1 (Week 1-2): Analyze Flutter MQTT logic; design TypeScript interfaces and
state schema
Phase 2 (Week 2-3): Implement MQTT client + device manager in React using mqtt.js
Phase 3 (Week 3-4): Develop UI components and integrate with existing React site
Phase 4 (Week 4-5): Testing, security hardening, performance optimization

Estimated Effort: 3–4 weeks (1–2 engineers)

Cost: ~$15,000–$25,000 USD (assuming $50K/month engineering cost)

Secondary Recommendation: Option B (Flutter iframe)

When to Use: If timeline is critical or if project scope is unclear, use Option B as a
temporary bridge with a planned migration to Option A within 3–6 months.

Rationale:
Allows shipping MQTT feature quickly without rewrite
Buys time for team to plan and execute proper React implementation
Can be deployed in parallel to production Option A rollout
Implementation Path:

Phase 1 (1–2 days): Build Flutter Web with WebSocket MQTT config
Phase 2 (2–3 days): Develop postMessage protocol + React wrapper component
 Phase 3 (1–2 days): Testing and deployment
Estimated Effort: 3–5 days (1 engineer)
Cost: ~$2,500–$5,000 USD

Deprecation Plan: Schedule React rewrite (Option A) for next sprint; flag iframe
implementation as temporary; communicate sunset timeline to stakeholders.

Implementation Checklist (Option A Recommended)

[ ] Audit existing Flutter MQTT code; document business logic
[ ] Design React state schema and context structure
[ ] Evaluate MQTT.js vs. alternative libraries (capacitor-mqtt, react-mqtt)
[ ] Set up MQTT broker with WebSocket endpoint (or use managed service)
[ ] Implement connection lifecycle (connect, subscribe, publish, disconnect)
[ ] Build React component library for device controls
[ ] Integrate with existing React routing and layout
[ ] Write unit tests for MQTT client and device manager
[ ] Test browser compatibility (Chrome, Firefox, Safari, Edge)
[ ] Load test with simulated device traffic
[ ] Security audit: credential handling, token validation, CORS
[ ] Performance profiling: bundle size, load time, runtime memory
[ ] Documentation: MQTT topic structure, API contracts, deployment guide
[ ] Deploy to staging; UAT with stakeholders
[ ] Deploy to production with rollback plan

Conclusion
Pure React with native MQTT over WebSockets (Option A) is the recommended
approach for production integration. While it requires upfront engineering investment
to rewrite MQTT and device-management logic from Dart to TypeScript, the resulting
system is faster, more maintainable, and better integrated with the existing React platform.
For teams with extreme time constraints, Option B (Flutter iframe) provides a viable
short-term solution, but should be planned as a temporary measure with a defined
migration timeline to Option A.
Option C (standalone application) is not recommended due to poor user experience and
lack of integration.

The choice between Option A and Option B ultimately depends on organizational priorities:
Option A prioritizes quality and long-term efficiency; Option B prioritizes speed and code
reuse at the expense of performance and user experience.
References
[1] MDN Web Docs. (2025, May 22). Window: postMessage() method. Retrieved from https://
developer.mozilla.org/en-US/docs/Web/API/Window/postMessage
[2] EMQX. (2024, November 11). How to use MQTT in the React project. Retrieved from http
s://www.emqx.com/en/blog/how-to-use-mqtt-in-react

[3] MQTT.js Contributors. (2025, October 26). MQTT.js: The MQTT client for Node.js and the
browser. GitHub. Retrieved from https://github.com/mqttjs/MQTT.js
[4] Surma. (2020). Is postMessage slow? Retrieved from https://surma.dev/things/is-postmess
age-slow/
[5] Appmixer. (2024, December 31). Comparing embedding methods: JavaScript SDK vs.
iFrame. Retrieved from https://www.appmixer.com/blog/javascript-sdk-vs-iframe

[6] Embeddable. (2025, October 1). Why you should not use iframes for embedded
dashboards. Retrieved from https://embeddable.com/blog/iframes-for-embedding
[7] CloudAMQP. (2025). MQTT over WebSockets documentation. Retrieved from https://ww
w.cloudamqp.com/docs/mqtt_over_websockets.html
[8] Flutter Development. (2024, November 11). How to use MQTT in the Flutter project. EMQ.
Retrieved from https://www.emqx.com/en/blog/using-mqtt-in-flutter

[9] HiveMQ. (2024, March 4). Implementing MQTT in JavaScript. Retrieved from https://ww
w.hivemq.com/blog/implementing-mqtt-in-javascript/
[10] GitHub. (2024, July 24). Two way communication with iframe in Flutter Web app.
Retrieved from https://gist.github.com/kenzieschmoll/36211ccaf7e1c16dca43c3fbf60243f1