DEV Community: Gajendra Paliwal

How to Reconcile Nested ePOS and ERP Data Arrays Natively in the Browser

Gajendra Paliwal — Fri, 18 Sep 2026 13:00:09 +0000

As a data engineer or developer working with retail or enterprise architectures, you’ve likely faced the classic reconciliation headache: matching sales records from an electronic Point of Sale (ePOS) system against entries in a massive Enterprise Resource Planning (ERP) database (like SAP or Oracle).
The data formats rarely align out of the box. ePOS logs are often flat, high-volume JSON streams or CSVs, while ERP exports come as deeply nested arrays containing multiple layers of procurement, tax, and inventory metadata.
When you need to match these files to find discrepancies, missing values, or quantity gaps, the traditional approach is to build a custom Python script or upload the files to an online utility.
But uploading sensitive corporate transaction records to a random, remote server is a compliance nightmare.
Here is how you can handle deep, nested array reconciliation natively in the client-side browser using JavaScript—keeping your business data private while eliminating server infrastructure bottlenecks.

The Problem: The Nested Structure Bottleneck
When you try to map flat transaction data against a nested ERP structure, standard array lookup methods like .find() or .filter() scale terribly ((O(N \times M)) time complexity). If you drop a 50MB file into the browser, it will instantly freeze the main UI thread.
Consider this common ERP nested array structure:
json
[
{
"order_id": "ERP_99812",
"metadata": {
"store_id": "ST_04",
"line_items": [
{ "sku": "SKU-882", "quantity": 10, "unit_price": 15.00 },
{ "sku": "SKU-104", "quantity": 2, "unit_price": 5.50 }
]
}
}
]
Use code with caution.
To reconcile this efficiently on the client side, we must flatten the data structure into a single-pass lookup index (O(1) lookup time) using an in-memory Map before running our matching loops.

The Solution: A High-Performance Browser Flattener
By extracting the nested items into a normalized key structure, we can easily process tens of thousands of rows locally. Here is a clean, dependency-free JavaScript function to flatten nested records for instant reconciliation:
javascript
function flattenNestedData(erpOrders) {
const flattenedIndex = new Map();

for (const order of erpOrders) {
const orderId = order.order_id;
const storeId = order.metadata?.store_id;
const items = order.metadata?.line_items || [];

for (const item of items) {
  // Create a unique composite key for precise matching
  const compositeKey = `${orderId}_${item.sku}`;

  flattenedIndex.set(compositeKey, {
    orderId,
    storeId,
    sku: item.sku,
    quantity: item.quantity,
    totalValue: item.quantity * item.unit_price
  });
}

}
return flattenedIndex;
}
Use code with caution.
Once your data is indexed into a standard map, your reconciliation loop can run through your ePOS file in a single pass (O(N)), comparing values, flagging missing entries, and calculating variances instantly without any server roundtrips.

Why Local Browser Processing Changes the Game

Absolute Privacy: Enterprise invoices, procurement data, and POS transactions never leave the client device. This completely eliminates data exposure risks and complies with strict corporate data governance rules.
Zero Upload Penalties: Moving large text payloads over the network takes time. Local array manipulation reads raw text straight from a file input element, executing formatting scripts at the machine's native processing speed.
No Infrastructure Overhead: Client-side computation runs on the user's processor. As a developer, this allows you to scale a utility tool to thousands of concurrent users with effectively $0/month in backend server or cloud function costs. ________________________________________ Try it Live (100% Offline) I am currently building https://formatforge.org/ around these exact architecture patterns—creating high-utility, browser-first tools for data engineers and developers. If you want to validate payloads, cross-reference records, or format complex datasets without exposing internal company code to external databases, you can try out our collection of local utilities: • Try the Live Tool: FormatForge Data and Invoice Reconciliation Workspace (https://formatforge.org/ ) • Privacy Model: Your payloads, scripts, and data arrays remain strictly in-browser and are never transmitted to a backend network. Have you built local processing pipelines for large datasets? What framework bottlenecks do you run into when handling file parsing entirely inside client-side web workers? Let's discuss in the comments below!

FormatForge.org

Why I’m Building FormatForge.org as a Browser-First Data Tools Platform

Gajendra Paliwal — Fri, 14 Aug 2026 17:41:48 +0000

As developers and data engineers, we regularly use online tools to convert, validate, compare, reconcile, and inspect data.

JSON to Excel.
CSV transformations.
PDF utilities.
Diff and comparison tools.
Invoice reconciliation.
Data validators.

These tools are convenient.

But there is a question I think we should ask more often:

Where is the data actually being processed?

The usual online-tool workflow

A typical online utility can work like this:

Your File → Upload → Remote Server → Processing → Download Result

For many tasks, that architecture is unnecessary.

Modern browsers are capable of doing a surprising amount of processing locally using JavaScript, Web APIs, Web Workers, and client-side libraries.

That led to one of the principles I’m following while building FormatForge.org:

If a task can reasonably be completed in the browser, process it in the browser.

The workflow becomes:

Your Data → Your Browser → Your Result

Why does this matter?

Privacy

Consider the kinds of data we regularly work with:

Excel and CSV exports
JSON API responses
invoices
procurement data
PDFs
images
API payloads
reconciliation files
business reports

Even when a file doesn't contain passwords or obviously sensitive information, it may still contain internal business data.

If the transformation can happen locally, there is no reason to unnecessarily send that data somewhere else.

Reduced data exposure

Browser-side processing reduces the number of places through which the data has to travel.

Instead of:

Browser → Network → Server → Storage/Memory → Network → Browser

a local utility can often perform:

Browser → Process → Result

That's a much simpler data path.

Performance

Local processing can also remove the upload/download cycle.

For relatively small and medium-sized datasets, that can make tools feel almost instant.

This is particularly useful for utilities such as:

JSON ↔ CSV/Excel conversion
text comparison
format validation
calculations
data cleanup
image transformations
reconciliation and matching
developer utilities

Simpler infrastructure

There is another benefit from the developer's perspective.

If processing happens client-side, I don't necessarily need to build:

upload endpoints
temporary file storage
file cleanup jobs
processing queues
additional database storage
scaling infrastructure for every transformation

That can significantly reduce both infrastructure complexity and operating cost.

Browser-first doesn't mean building thin tools

This has been another important lesson while building FormatForge.org.

Running something in the browser isn't enough.

A tool still needs to solve the complete user problem.

For example, a reconciliation tool shouldn't simply tell me that two files are different.

A useful workflow should help answer:

What matched?

What's missing?

What's extra?

What quantity is remaining?

Can I export the reconciliation result?

Similarly, a JSON-to-Excel tool should do more than dump JSON into a spreadsheet if the real-world data contains nested ERP or ePOS structures.

This is why I've recently been spending more time improving existing tools instead of simply adding new ones.

A principle I'm trying to follow

The architecture is becoming quite simple conceptually:

Input
↓
Validate
↓
Process locally
↓
Show transparent results
↓
Allow export/download

And the product philosophy behind it is even simpler:

Don't move user data when the job can be done where the data already is.

For a utility platform, I think this is a useful default.

Building FormatForge.org

I'm building FormatForge.org around practical browser-based utilities for developers, data engineers, business users, procurement teams, and everyday users.

The focus is increasingly on:

real problem → complete workflow → local processing → useful result

rather than:

keyword → page → another thin tool

My current approach to growing the project is:

Quality → Indexing → Traffic → Revenue

There is still a lot to improve, but browser-first processing is becoming an important part of how I think about the platform.

Useful tools. Browser-based processing. Privacy by design.

FormatForge.org

How I Built a Privacy-First Image to PDF Converter in Next.js (Without Uploading Files on server)

Gajendra Paliwal — Mon, 27 Jul 2026 06:11:44 +0000

When I started building document utilities, I noticed something that bothered me.

Most online Image to PDF converters require users to upload their personal images to a server before generating a PDF.

For resumes, passports, certificates, invoices, and other sensitive documents, that isn't always ideal.

So I decided to build an Image to PDF converter that works entirely in the browser.

No server-side file processing.
No file uploads.
Just your browser.

Why Browser-Side Processing?

Modern browsers are much more powerful than they were a few years ago.

Instead of sending images to a backend, everything can be processed locally.

That provides several advantages:

🔒 Better privacy (files stay on your device)
⚡ Faster processing
💰 Lower hosting costs
🌍 Better scalability
📱 Works well on desktop and mobile

For utility websites, this approach is often a better user experience.

Tech Stack

I built the tool using:

Next.js
React
TypeScript
Tailwind CSS
Browser File API
Canvas API
pdf-lib

Everything happens inside the browser.

Features

The latest version includes:

Multiple image upload
Drag & Drop support
Drag-to-reorder pages
Image rotation
A4 & Letter page sizes
Margin settings
Image quality selection
Browser-based PDF generation
Download
Native Share API support (where available)
Biggest Challenges

Generating the PDF wasn't actually the hardest part.

The real challenge was creating a smooth experience that works across different browsers and devices.

Some areas required extra attention:

Handling large, high-resolution images efficiently
Keeping memory usage under control
Maintaining image quality
Supporting mobile browsers
Creating reusable UI components instead of duplicating logic

Those improvements made a much bigger difference than simply adding more features.

What I Learned

One lesson became very clear:

Users value a polished workflow more than a long feature list.

Simple improvements like:

consistent buttons
drag-and-drop uploads
progress indicators
printable layouts
native sharing

can significantly improve the overall experience.

Live Demo

If you'd like to try it yourself:

👉 Image to PDF Tool
https://formatforge.in/tools/image-to-pdf

You can also explore the full collection of browser-based utilities here:

🌐 FormatForge
https://formatforge.in

The platform focuses on browser-based tools for:

PDF
Images
JSON
YAML
Developer Utilities
Business & Productivity
I'd Love Your Feedback

I'm continuing to improve FormatForge with a focus on:

Performance
Privacy
Browser-first processing
Better developer and user experience

I'm curious:

Do you prefer browser-side or server-side document processing?
Which PDF library has worked best for your projects?
What's one feature you think every PDF tool should include?

I'd love to hear your thoughts and suggestions in the comments.

From Enterprise Procurement Systems to Building Browser-Based Developer Tools

Gajendra Paliwal — Wed, 22 Jul 2026 06:46:54 +0000

Over the last 14+ years, I've been working with the Microsoft technology stack, designing and delivering enterprise applications for procurement, inventory management, warehouse operations, and EPOS systems.

As a Tech Lead, I've worked on projects involving:

Procurement & Purchase Order Management
Inventory & Warehouse Management
EPOS integrations
Accounting integrations
REST APIs & Microservices
Azure cloud solutions
Performance optimization and secure application design

While enterprise software has always been my primary focus, I've recently been expanding my work with Next.js, React, and TypeScript by building browser-based productivity tools.

One of my goals is to build applications that are fast, privacy-friendly, and solve real business problems directly in the browser whenever possible.

Some of the tools I've been building include:

YAML Studio for Kubernetes, Docker Compose, GitHub Actions, Azure DevOps, Helm, Prometheus, and Grafana configuration generation.
JSON ↔ Excel Converter with support for nested JSON, multi-sheet exports, and parent-child relationships.
Multilingual OCR for business documents.
PDF to Excel with structured table extraction.
JSON Formatter & Validator.
CSV, Excel, and other data conversion tools.

One thing I've learned while building document-processing tools is that file conversion is the easy part.

The real challenge is preserving document structure—detecting tables, handling multi-line descriptions, reconstructing wrapped product codes, and generating output that users can actually work with instead of spending time cleaning it up.

My experience in procurement has made this especially interesting because Purchase Orders, Delivery Notes, Goods Receipts, and Invoices all have different layouts and business rules. Building reliable tools requires understanding both the technology and the business process behind the documents.

Alongside application development, I'm also continuing to strengthen my DevOps knowledge with Docker, Azure DevOps, Azure Container Registry (ACR), YAML Pipelines, and Kubernetes (AKS).

It's been a rewarding journey moving from enterprise business applications to browser-based developer tools. Although the technologies are different, the objective remains the same:

Build software that solves real problems in a simple, reliable, and user-friendly way.

I'm always interested in connecting with developers working on enterprise software, document processing, cloud-native applications, or developer productivity tools.

What engineering challenge are you currently working on? I'd love to hear about it.

Technologies

Instead of hashtags in the body, use a simple section like this:

Backend: C#, .NET, ASP.NET Core, Web API, SQL Server

Frontend: Next.js, React, TypeScript, Tailwind CSS

Cloud & DevOps: Azure, Azure DevOps, Docker, Kubernetes (AKS), Azure Container Registry (ACR), YAML Pipelines

Document Processing: OCR, PDF Processing, JSON, YAML, Excel, CSV

Domain Experience: Procurement, Inventory Management, Warehouse Management, EPOS