构建类似Scan2Info的移动端条码扫描系统：技术选型与架构优化咨询

Hey there! Let's dive into each of your technical questions with practical advice tailored to your project of building a Scan2Info-like system for in-store price queries.

1. Best JavaScript Barcode Scanning Libraries for Mobile Browsers #

Here are my top picks, all tested well for EAN/UPC scanning on mobile:

• Zxing-js: A port of the popular ZXing library to JavaScript. It’s lightweight, supports all major barcode formats including EAN-13/UPC-A, and works reliably across most mobile browsers. You can use the @zxing/library npm package directly, or the browser-friendly CDN version.
• QuaggaJS: A pure JavaScript library that runs entirely client-side. It has excellent EAN/UPC detection and allows you to configure scan regions (useful for focusing on barcode areas in mobile cameras). Note that it might be slightly heavier than Zxing-js, but offers more customization.
• Native BarcodeDetector API: If you’re targeting modern mobile browsers (Chrome, Edge, Android WebView), this browser-native API is the fastest option. It leverages device hardware for scanning, reducing CPU usage. Just check compatibility first—Safari has partial support as of now.

For implementation, make sure to handle camera permission requests gracefully, and add fallback logic if the user denies access or their browser doesn’t support the library/API.

2. PWA vs. Native Mobile App: Which is Better? #

For your use case (customers scanning barcodes in-store to check prices), PWA is the clear winner—here’s why:

• Low barrier to entry: Customers don’t need to download an app from an app store; they can just open your web app in their browser, or add it to their home screen for app-like access.
• Cross-platform efficiency: You can build once with Blazor or standard web tech and deploy to both iOS and Android, avoiding the cost and maintenance of separate native codebases.
• Easy updates: Push updates to your PWA without waiting for app store approvals, which is critical if you need to tweak features or fix bugs quickly.

That said, go native only if you need:

• Ultra-high-performance camera scanning (though modern PWAs are already quite good)
• Deep integration with device features like offline storage beyond PWA’s capabilities
• Strict app store distribution requirements (unlikely for in-store customer tools)

Blazor PWA is a great fit here—you can reuse your existing .NET skills, and it supports offline caching for static assets, making it work smoothly even in spotty store Wi-Fi.

3. Optimizing Response Time for Near-Real-Time Queries #

To get that instant feel when users scan a barcode, focus on these areas:

Backend & API Optimizations #

• Use parameterized queries with ADO.NET: This avoids SQL injection and helps SQL Server cache query plans, speeding up repeated lookups.
• Implement caching: Cache frequently scanned items using IMemoryCache (for single-server setups) or Redis (for distributed systems). Set a short TTL (like 5-10 minutes) to ensure price updates reflect quickly.
• Async API endpoints: Use async/await in your ASP.NET Core controllers to free up threads and handle more concurrent requests without bottlenecks.
• Trim response payloads: Only return the data you need (price, name, key details) instead of full database records—this reduces network transfer time.

Database Optimizations #

• Add a unique index on the barcode field: Since your queries are always based on EAN/UPC, this index will make lookups almost instant, even with large datasets.
• Avoid unnecessary joins: If your product data is in a single table, keep it that way. If you need related data, denormalize where possible or use covering indexes to avoid key lookups.
• Consider read replicas: If you expect high traffic, set up SQL Server read replicas to offload query traffic from the primary database.

Frontend Optimizations #

• Preload camera resources: Initialize the scanner when the page loads, so it’s ready to go when the user taps "scan".
• Minimize UI latency: Show a loading indicator immediately after scanning, then update the UI as soon as the API response arrives—avoid any unnecessary delays in rendering.
• Use PWA Service Workers: Cache static assets (like JS libraries, CSS) so the app loads faster on subsequent visits.

4. Scalable Architecture Recommendations #

As your system grows (e.g., more stores, more products, higher traffic), here’s a scalable architecture to consider:

• Layered Web API: Keep your ASP.NET Core API clean with separation of concerns:
  1. Presentation layer (API endpoints)
  2. Business logic layer (process barcode requests, validate data)
  3. Data access layer (ADO.NET calls to SQL Server)
• API Gateway: Add an API gateway (like Ocelot for .NET) to handle routing, rate limiting, authentication, and request aggregation. This makes it easier to add new services later.
• Distributed Caching: Use Redis as a central cache to share cached product data across multiple API servers—this reduces database load and ensures consistent responses.
• Containerization & Orchestration: Package your API and frontend into Docker containers, then use Kubernetes to manage scaling. Kubernetes can automatically spin up new instances during peak traffic (like busy shopping hours) and scale down when demand drops.
• Asynchronous Processing: For non-critical tasks (like logging scan events, updating usage metrics), use a message queue (RabbitMQ or Azure Service Bus) to offload work from your main API. This prevents slow background tasks from affecting real-time query performance.
• Monitoring & Observability: Set up tools like Application Insights (for .NET) or Prometheus to track API response times, database query latency, and error rates. This helps you identify bottlenecks before they impact users.

内容的提问来源于stack exchange，提问作者AHMAD ALMAJALI