DEV Community: Max Bantsevich

Building a Custom E-commerce Analytics Dashboard in Hours with Admiral

Max Bantsevich — Tue, 13 Jan 2026 11:48:32 +0000

The Challenge

Recently, we needed to add seller analytics to our e-commerce project. You know the drill: key metrics, charts, data exports, order funnels — the usual set of features that clients expect in their admin panels.

Typically, building a custom analytics dashboard from scratch takes weeks. But we managed to put it together in just a couple of hours using Admiral, our open-source framework for admin panels.

What is Admiral?

Admiral is an open-source framework for rapidly building admin panels that works with any backend. Most people use it for quick CRUD operations, but it's capable of much more.

The key advantage: you're not locked into a specific stack or architecture. Admiral adapts to your backend, not the other way around.

What We Built

Here's what we assembled for our seller analytics dashboard:

📈 Key Metrics

Revenue tracking
Order count
Average order value
Repeat sales
Week-over-week trends with historical data

🔄 Business Process Visualization

Order funnel by status
Aggregated counts and totals
Visual representation of the sales pipeline

🛍️ Sales by Category

Breakdown of all orders by product categories
Visual charts for quick insights

↩️ Returns & Cancellations

Dedicated analytics block
Counts and monetary amounts

🎟️ Promo Code Analytics

Usage statistics
Application counts
Total discount amounts

📊 Data Export

One-click export to XLSX and CSV for every block

The Secret Sauce: Cursor Rules

What made this fast? We've developed cursor rules specifically for Admiral that speed up the development of custom interfaces dramatically.

With these rules, building beautiful and functional dashboards isn't just quick — it's actually enjoyable. The rules handle the boilerplate, letting you focus on the business logic specific to your project.

Why This Matters

This isn't an out-of-the-box feature that comes with Admiral. This is a custom dashboard we built for specific project needs in a couple of hours.

That's the point: Admiral gives you the flexibility to build arbitrary interfaces quickly:

Custom dashboards
Complex data visualizations
Tailored analytics
Whatever your project actually needs

No fighting with pre-built components that almost fit your use case. No compromising on features because extending the framework is too painful.

Try It Yourself

Admiral is open source and works with any backend. Whether you need simple CRUDs or complex custom interfaces, it adapts to your needs.

Check it out: https://github.com/dev-family/admiral

What kind of admin interfaces are you building? Have you found a framework that gives you the right balance of speed and flexibility?

UX/UI in 2026: Why Beautiful Design No Longer Guarantees Success

Max Bantsevich — Wed, 17 Dec 2025 12:10:36 +0000

TL;DR: AI commoditized "pixel-perfect" design. In 2026, designers compete on strategy and metrics, not aesthetics. Here's what actually works now.

Hi Dev.to! 👋

I'm a product designer who just spent 3 weeks deep-diving into what's actually working in UX/UI 2026. Not what looks pretty on Dribbble, but what moves business metrics and helps developers ship better products.

The main thesis? Design is becoming infrastructure, not decoration.

🤖 The AI Shift: What Changed for Designers

The reality:
Tools like Figma AI, Galileo AI, and Magician now generate clean layouts in seconds. I can literally type "dashboard for restaurant management app" and get 5 professional-looking variants instantly.

What this means:

"Pixel-perfect" is no longer a competitive advantage
Visual styling is commoditized
Designers must compete on strategy, not aesthetics

The new value:
Understanding user behavior, metrics, and business logic. AI handles the pixels; humans handle the "why."

// Old designer value proposition
const designer = {
  skill: "making things beautiful",
  output: "pretty screens"
}

// New designer value proposition
const designer = {
  skill: "understanding behavior + metrics",
  output: "interfaces that move numbers"
}

📊 Outcome-Driven UX: Every Screen Needs a Metric

In 2026, every screen you build must answer:

What behavior are we changing?
Which metric are we moving?
How quickly will we see results?

Mandatory metrics:

Activation
→ Time to first value
→ How fast does user "get it"?

Retention
→ Day 1, Day 7, Day 30
→ Do they come back?

Conversion
→ Free → Paid, Browse → Buy
→ Actual revenue impact

NPS
→ Would they recommend?
→ Real satisfaction metric

LTV
→ Long-term user value
→ Are we building sustainable business?

Real example from our work:

We redesigned an onboarding flow for a SaaS product:

BEFORE:
- 7 steps to first value
- 35% completion rate
- Day 7 retention: 18%

AFTER (outcome-driven approach):
- 3 steps to first value  
- 67% completion rate
- Day 7 retention: 34%

The design wasn't "prettier" - it was more strategic.

🌍 Regional UX Models Going Global

One-size-fits-all UX is dead. Products now adapt interfaces based on regional patterns:

Asia (Grab, Gojek, WeChat)

.interface {
  density: high;
  whitespace: minimal;
  features-per-screen: many;
  style: "super-app";
}

Why: Users expect everything immediately accessible. Dense = efficient.

India (Zomato, Paytm)

.interface {
  trust-signals: prominent;
  explanations: detailed;
  language: hyper-localized;
  style: "trust-first";
}

Why: Users approach new products cautiously. Design must explain and build trust.

US/Europe (Notion, Linear, Apple)

.interface {
  whitespace: generous;
  visual-noise: minimal;
  flow: calm;
  style: "minimalist";
}

Why: Users value clarity and breathing room. Less = more.

The key insight: Modern products detect user location/context and adapt UI accordingly. Same backend, different front-end patterns.

🥽 New Platforms = New UX Patterns

As developers, you're probably already building for these:

AR/VR (Apple Vision Pro, Meta Quest)

// Traditional UI thinking
const button = {
  type: "clickable",
  interaction: "tap/click"
}

// Spatial UI thinking
const button = {
  type: "spatial-object",
  interaction: "gaze + pinch",
  depth: "floating-at-50cm",
  physics: "gravity-affected"
}

Wearables (Apple Watch, smart glasses)

// Screen-based thinking
const notification = {
  display: "full-screen modal",
  dismiss: "button tap"
}

// Wearable thinking
const notification = {
  display: "glanceable-card",
  dismiss: "auto-after-3s",
  interaction: "quick-action-only"
}

Key differences:

Gesture-first flows (not tap/click)
Eye-control navigation (gaze as input)
Zero-UI (ambient, contextual interfaces)
Spatial design (3D, depth, physical space)

🎨 Visual Trends That Actually Work

Not just "looks cool" - these drive behavior:

1. Motion-First Design

Animations aren't decoration - they're explanation.

/* Bad: Decoration */
.button {
  transition: all 0.3s ease;
}

/* Good: Behavioral signal */
.button:hover {
  transform: translateY(-2px);
  box-shadow: 0 4px 12px rgba(0,0,0,0.15);
  /* Communicates: "I'm clickable and will respond" */
}

.loading-state {
  animation: pulse 1.5s ease-in-out infinite;
  /* Communicates: "I'm working, wait for me" */
}

2. Warm Minimalism

Less noise, more breathing room, warmer palettes.

/* Old minimalism: cold */
:root {
  --background: #FFFFFF;
  --text: #000000;
  --accent: #0066FF;
}

/* Warm minimalism: human */
:root {
  --background: #FAFAF9;
  --text: #1A1A1A;
  --accent: #FF6B35;
  --surface: #F5F5F4;
}

3. Liquid Glass + Depth

Borrowed from visionOS, now everywhere:

.glass-panel {
  background: rgba(255, 255, 255, 0.1);
  backdrop-filter: blur(20px);
  border: 1px solid rgba(255, 255, 255, 0.2);
  box-shadow: 
    0 8px 32px rgba(0, 0, 0, 0.1),
    inset 0 1px 0 rgba(255, 255, 255, 0.3);
}

4. Accessibility as Base Layer

Not optional anymore:

// Automated checks in CI/CD
const accessibilityChecks = {
  colorContrast: ">=4.5:1", // WCAG AA minimum
  focusVisible: true,
  keyboardNav: "complete",
  screenReaderLabels: "all-interactive-elements",
  motionPreference: "respect-prefers-reduced-motion"
}

🛠️ Practical Implementation for Developers

1. Integrate UX Metrics in Your Code

// Track UX metrics like features
const trackUXMetric = (metric, value) => {
  analytics.track('ux_metric', {
    metric_type: metric, // 'activation' | 'retention' | 'conversion'
    value: value,
    timestamp: Date.now(),
    component: getCurrentComponent()
  });
}

// Example: Track time to first value
const onboardingStart = Date.now();
// ... user completes onboarding ...
trackUXMetric('activation', {
  time_to_value: Date.now() - onboardingStart,
  completed: true
});

2. Build Adaptive Interfaces

// Detect and adapt to regional patterns
const getUXDensity = (userLocale) => {
  const densityMap = {
    'asia': 'high',      // More content per screen
    'india': 'medium',   // Balanced with trust signals  
    'us': 'low',         // Generous whitespace
    'eu': 'low'
  };

  const region = getRegion(userLocale);
  return densityMap[region] || 'medium';
}

// Apply density to layout
const spacing = {
  high: '8px',
  medium: '16px', 
  low: '24px'
}[getUXDensity(userLocale)];

3. Respect Familiar Patterns

// Don't reinvent the wheel
const navigation = {
  mobile: 'bottom-tab-bar',     // Familiar to everyone
  desktop: 'sidebar',            // Expected pattern
  // NOT: 'gesture-only-hidden-menu' (users will struggle)
}

// Innovation through details, not structure
const enhancedNavigation = {
  ...navigation,
  transitions: 'smooth-60fps',
  feedback: 'haptic-on-tap',
  state: 'persisted-across-sessions'
}

📈 Companies Doing This Right

Real examples to learn from:

Notion

Familiar patterns (blocks, pages, database views)
Wins on details (smooth animations, smart defaults)
Every feature tied to engagement metrics

Linear

Super predictable structure
Fast keyboard shortcuts (developer-focused)
Minimal visual noise, maximum clarity

Duolingo

Gamification based on retention data
A/B tests everything (3-5 day cycles)
Bright accents guide behavior

Shopify

Clean merchant dashboard
Regional payment method adaptation
Onboarding optimized for activation

🎯 The Controversial Part

If you design based on "beauty" or "speed to ship," AI will likely win.

Designers who focus on:

User behavior patterns
Business metrics
Strategic thinking
Collaboration with developers

...will be in the top 5% of the market.

✅ Quick Implementation Checklist

For your next feature:

- [ ] Define which metric this feature should improve
- [ ] Choose familiar patterns over novel ones
- [ ] Add smooth transitions (not just instant state changes)
- [ ] Ensure 4.5:1+ color contrast (WCAG AA)
- [ ] Test with keyboard navigation
- [ ] Add loading/error states with clear feedback
- [ ] Track actual usage metrics (not just launches)
- [ ] Run quick A/B test (3-5 days, not months)
- [ ] Adapt for regional patterns if targeting multiple markets

🔮 Bottom Line

2026 isn't about making prettier interfaces.

It's about:

Understanding behavior
Moving metrics
Building adaptable systems
Collaborating strategically

AI can generate the pixels. Developers + designers who understand the "why" behind the "what" will build products that actually work.

Full deep-dive (18 min read): https://dev.family/blog/article/uxui-ai-and-trends-that-actually-work-in-2026

What's your experience?

Are you tracking UX metrics in your projects?
Have you adapted interfaces for different regions?
How do you use AI in your design/dev workflow?

Let's discuss in the comments! 👇

P.S. If you're building products and want to dive deeper into any of these patterns, happy to answer questions in the comments.

Why Security Updates Still Matter More Than Ever

Max Bantsevich — Wed, 10 Dec 2025 12:02:37 +0000

Over the past few days, the tech community has been discussing a new wave of automated attacks exploiting a recently disclosed critical vulnerability in Next.js.

Events like these serve as a reminder of something we all know — yet too often postpone:
security isn’t a one-time setup. It’s a constant, ongoing responsibility.

When a major vulnerability goes public, automated scanners begin sweeping the entire internet within minutes. They detect unpatched versions and immediately attempt to deploy malicious payloads. These aren’t targeted attacks — they’re fully automated systems that exploit any available opening.

Here are a few practices that can prevent most of the damage:

Keep dependencies up to date.

Even a single outdated library can open the door to automated exploitation.

Install security patches as soon as they’re released.

Time is critical. Attackers automate everything — we need to react fast.

Monitor your infrastructure continuously.

Unexpected files, strange processes, unusual traffic patterns — early detection is key.

Treat security as ongoing maintenance, not a checkbox.

A secure application requires constant attention.

Situations like the current global attack wave highlight the same truth every time:

your product stays secure only as long as it stays maintained.

🧠 How Different AI Agents Write Code from the Same Instructions: Cursor vs Copilot vs Windsurf

Max Bantsevich — Mon, 29 Sep 2025 10:38:42 +0000

We recently ran an experiment: we took the same set of coding instructions and gave them to three different AI coding agents — Cursor, Copilot, and Windsurf — to see how each would handle the task.
The results turned out to be pretty interesting, showing the strengths and weaknesses of each tool in terms of rule compliance, accuracy, and developer experience.

What’s inside the article:

A breakdown of how each tool handles rules (types, activation, nesting, etc.)
Testing code generation (CRUD) from the same description
Detailed comparison: who nailed it, and who missed the mark
Insights on when Cursor is the best choice — and when Windsurf might be a solid alternative
Why Copilot still struggles with custom rule handling

➡️ Key takeaways:

Cursor followed the rules most accurately and delivered the cleanest results.
Windsurf required a bit more effort to “guide” it, but it performed reasonably well with adjustments.
Copilot, with its current rule support, wasn’t able to produce results close to the intended structure.

Want to dive deeper, check the code samples, and see the detailed comparison? Read the full article here:

👉 Cursor vs Copilot vs Windsurf: How Different AI Agents Write Code from the Same Instructions

I’d love to hear your thoughts:

Which of these tools have you used in your workflow?
Do you have your own coding rules or prompt strategies?
Did anything in the results surprise you?

How to verify your cookie consent is working 🍪🍪

Max Bantsevich — Thu, 08 May 2025 07:59:28 +0000

Got your cookie banner set up with Google Consent Mode? Now comes the critical step – verifying that it’s actually respecting user choices.

Here’s how to ensure everything is working smoothly:
1️⃣ Use Browser DevTools. Before and after consent, check cookies and requests to ensure compliance. Is Google Analytics firing only after consent? Are non-essential cookies blocked before? Make sure your users’ privacy is protected.
2️⃣ Google Tag Assistant. This Chrome extension shows consent status changes in real time, so you can track whether analytics and ads are only enabled when users say "yes".

And don’t forget about a detailed cookie policy that aligns with regional laws (GDPR, CCPA).

📘 Learn more in our full guide with examples of cookie policy for EU and US

The Evolution of Architectural Patterns in Back-End Development: From MVC to Microservices

Max Bantsevich — Thu, 08 May 2025 07:51:48 +0000

An architectural pattern is the foundation of any large-scale software project, and the choice of pattern significantly impacts how successfully a back-end system can evolve and be maintained. For a long time, the traditional MVC (Model-View-Controller) pattern was considered the go-to approach for building web applications.

Modern MVC implementations often incorporate advanced concepts like dependency injection (DI) and inversion of control (IoC), making it possible to extend and scale the architecture far beyond its original simplicity. However, even these more complex MVC structures come with limitations – especially when it comes to scalability and maintaining increasingly complex business logic.

Despite the capabilities of today’s MVC frameworks, many teams still rely on basic, unextended MVC.

In this article, we’ll take a closer look at how back-end architectural patterns have evolved – from the classic MVC model, commonly used in early-stage projects, to more advanced approaches like SOA (Service-Oriented Architecture), DDD (Domain-Driven Design), Modular Monoliths, and ultimately, Microservices.

Our goal is to highlight how transitioning between architectures can address real-world issues around maintenance, testability, and scalability, and to offer guidance on choosing the right architecture based on your project’s specific needs.

Challenges of Traditional MVC

The main advantages of MVC are fast development and a low entry barrier. It’s a straightforward and intuitive architectural pattern that developers can quickly learn and implement. Additional time costs are caused by the distribution of business logic across controllers, project growth, testing difficulties, and duplication of logic.

The primary issues arise from the scattering of business logic across controllers, project growth, testing difficulties, and code duplication. This problem becomes especially apparent when there are no modular tests, or when parts of the code base cannot be reused in different parts of the application.

In large-scale projects, this typically results in a set of large controllers, where business logic is either not reused at all or offloaded into static utility functions or domain models. This approach often leads to developer frustration, as modifying any part of the system can trigger unforeseen consequences.

Today’s MVC frameworks offer modern capabilities that mitigate many of these issues:

IoC and DI integration – frameworks like ASP.NET MVC, Laravel, and Spring MVC come with built-in dependency injection containers, increasing modularity and simplifying testing;
Clear separation between views and controllers – using ViewModels, templating systems, and dedicated service layer helps structure communication between layers more cleanly;
Extensibility through additional layers – when it’s necessary, MVC can be augmented with separate layers for business logic, domain modeling, and infrastructure, resulting in a more flexible and scalable architecture.

However, despite these improvements, there are still some limitations:

Scattered business logic – even with service layers and repository patterns in place, logic often ends up split between controllers, models, and other components, making long-term maintenance more difficult;
Scaling challenges – as the project grows, managing dependencies and introducing new features can lead to tangled codebases, requiring frequent refactoring to stay manageable;
Testing limitations – although DI helps, tight coupling between layers sometimes results in a reliance only on integration testing, rather than clean unit tests.

Now that we’ve identified the core issues, let’s walk through how project architecture typically evolves. We'll explore when a shift to a different pattern may become necessary, whether it’s possible to anticipate that transition, and how to proactively prepare for it.

Stages of Architectural Evolution

As a project grows, it accumulates new features, more data, and an increasing number of users. To keep the system from becoming overly complex or difficult to maintain, its architecture needs to evolve accordingly.

Let’s say we start a project using the previously discussed MVC pattern and successfully launch an MVP. As the product gains traction, the client decides to continue development. Over time, we begin to encounter growing pain – maintaining and updating both existing and new business logic becomes increasingly challenging. At this stage, it often makes sense to consider switching to a more robust architectural approach in order to speed up development and reduce bugs.

Below are some architectural models that, in my experience, are well-suited for fast-scaling products.

Adopting Domain-Driven Design (DDD)

Domain-Driven Design focuses on a deep understanding of the business domain. The core idea behind DDD is to build a rich domain model and leverage concepts like bounded contexts, aggregates, entities, and value objects to organize and encapsulate business logic. While DDD helps structure internal application logic, it doesn’t prescribe specific deployment strategies or component interaction models.

Key benefits and characteristics of transitioning to DDD include:

Reduced complexity through a clearly and explicitly described domain layer. Each domain has a specific responsibility, and its interactions are confined within defined Bounded Contexts;
Easier integration of new features if domain layer are properly structured – new logic naturally fits into existing domain boundaries;
Changes require deep domain understanding, encouraging developers to model real business processes rather than just code for functionality;
Minimized risk of chaotic logic – when built around DDD principles, the system can absorb changes in a consistent and predictable way;
Feature expansion happens naturally, either by creating new domains or extending existing ones within their context.

Transitioning to a Modular Monolith

The Modular Monolith architectural approach defines clear boundaries and dependencies between modules while keeping the application as a single deployable unit. It offers many of the benefits of modularity—such as improved maintainability, testability, and scalability at the development level—without introducing the complexity of a fully distributed system.

Key advantages and characteristics of adopting a Modular Monolith include:

Reduced complexity through separation into well-defined modules with clear interfaces, each of which can be developed and tested independently;
Lower risk of regression– when modules are properly isolated, changes made to one area are less likely to unintentionally break others;
A natural path to microservices – a well-structured module can eventually be extracted into an independent service with minimal effort;
Safe refactoring and updates – while modifications may require tests across modules, a clean modular structure minimizes risk;
Simplified code maintenance thanks to clearly separated concerns and encapsulated logic within each module.

Choosing the Right Approach

Ultimately, the choice of architectural approach depends on the specifics of the project, the team, and how comfortable they are with concepts like DDD. However, the comparison table below outlines key differences based on several aspects:

As the project evolves, contextual models or modules tend to grow in complexity or become increasingly independent. At some point, these components may even require different runtime environments or programming languages. That’s when microservices or SOA (Service-Oriented Architecture) come into play.

Moving to Microservices and SOA

The main advantage of this approach is the ability to split the application into independent services, each responsible for a specific task – such as email notifications or payment processing. This enables high flexibility, scalability, and independent deployment of individual components.

However, this approach requires a well-thought-out infrastructure for orchestration, monitoring, and inter-service communication.
While SOA and Microservices aim for the same goal – decomposition of systems into separate components – they differ in scale, implementation style, and operational complexity.

Transitioning to a microservices or SOA-based system allows each component to be tailored to a specific task independently of the rest of the system. For instance, a dedicated data processing service can be optimized for handling high-throughput workloads, while an analytics service might run sophisticated algorithms.

Because components operate autonomously, changes to one service don’t disrupt the whole system. In contrast, modular monoliths and DDD often rely on conceptual boundaries (like Bounded Contexts), and changes in one module can still affect others.

Another key benefit is technology flexibility. You can use Python for data processing, Go for high-performance services, and Node.js for rapid prototyping – all within the same system.

Workloads in real-world systems are rarely uniform. The ability to scale individual services helps manage resources more effectively and can significantly reduce infrastructure costs.

And here are all the transitioning benefits:

Both approaches have their strengths, and the choice between them should be driven by your system’s specific needs. Here's an additional comparison between SOA and Microservices:

Own experience and project examples

From my own experience, I’ve worked on two major projects where architectural issues and technical debt forced teams to rethink their systems. Both have decided to move to a different architecture. But the path wasn’t easy.

Case 1: Migrating to a Modern MVC Structure

This was a medium sized project where the architecture transition took about three months and was handled by only two developers. The main task was a full refactor to align the codebase with a modern MVC structure and upgrade the framework from Laravel 5.8 to Laravel 8.0.
Before the migration, the application used a classic setup: a REST API with logic embedded directly in models, and overloaded controllers handling routing and business logic. Reusability attempts were limited to helper functions, which eventually led to tight coupling.

Key challenges during the transition:

Bug spikes after redistributing logic due to changes in architectural principles;
Pressure from the business for fast delivery, making iteration and debugging more difficult;
Separating concerns into services and layers to reduce coupling and achieve atomicity logic.

The most difficult part was splitting business logic. Over the years, various teams contributed to the codebase, resulting in duplicated logic and inconsistencies. Business logic existed at every level – from middleware to models – making refactoring extremely complex. As we progressed, new edge cases emerged that required expanding or modifying existing solutions, triggering cascades of service rewrites and test updates. Some services grew to 1,000-2,000 lines of code and had to be split, which impacted dependencies and revealed issues with recursive DI chains.

Despite these difficulties, the migration brought significant benefits: cleaner architecture, improved test coverage, and easier maintenance accelerated feature development. Overall development speed increased by approximately 25%, and the bug rate dropped by 30%, validating the value of the refactor.

Case 2: A Journey Through Compromise

This project had over 450 controllers but only 90 services – a sign of inconsistent architecture caused by multiple large teams working with different standards. As a result, it was nearly impossible to trace where business logic existed.

The project suffered from frequent bugs, low maintainability, poor scalability, and optimization bottlenecks. Despite the clear need for change, aligning over 100 developers across more than five teams (plus separate groups of managers, analysts, architects, DevOps, etc.) was a massive challenge. It took over six months just to move from idea to action. As usual, the business was reluctant to allocate resources for addressing technical debt.

Instead of a full microservices rewrite, a compromise was reached: each team would begin migrating their components to microservices. The legacy monolith remained operational, with integrations to new services handled through databases, Redis, Prometheus, and dedicated microservice APIs.

The DevOps team faced a steep learning curve, particularly around service orchestration in Go, which was new to them. To minimize risk, low-traffic components were migrated first.

Key challenges in this case:

Learning and adaptation – Go was unfamiliar to the team. A lead engineer was hired, and internal upskilling programs were launched, but inexperience led to data inconsistencies, system crashes, and even revenue losses;
Bottlenecks – high-load areas exposed critical failure points requiring urgent fixes;
Team stress – constant bugs, unstable infrastructure, and a flood of problems led to a sense of looming failure.

After a painful stabilization phase – including bug fixes and bottleneck optimizations – the situation began to improve. The architecture became more transparent, development accelerated, and testing helped catch issues early. Teams gained autonomy, scalability increased, and API standardization brought clarity and independence.

✍ Key takeaway. Migrating to a new architecture is always challenging – for developers, managers, DevOps, and product owners alike. But the payoff is real: autonomous teams, resilient services, and a more flexible system benefit both engineering and the business.

How to Choose the Right Architecture Pattern

When selecting an architectural pattern, consider the following criteria:

Testability – the architecture should support unit and integration testing across functional blocks;
Readability & Maintainability – a well-structured codebase makes changes easier and reduces the likelihood of bugs;
Logic Reusability – dividing functionality into atomic components prevents duplication and accelerates new feature development;
Flexibility & Scalability – The system must be adaptable to evolving project requirements, allowing incremental enhancements.

Based on the architectural models discussed, here’s a breakdown to help guide your decision:

Purpose and scope of use differ between the approaches – DDD focuses on modeling business logic, while SOA and Modular Monolith are aimed at structuring the application from the perspective of deployment and dependency management;
Deployment – SOA is built around independently deployable services. In contrast, a Modular Monolith is deployed as a single application, even though it has a well-defined internal modular structure. DDD, on the other hand, does not prescribe a specific deployment strategy;
Communication SOA happens over the network – typically via REST or SOAP – which introduces concerns like latency, reliability, and security. A Modular Monolith avoids these issues since modules interact with each other directly within the same process;
When it comes to managing complexity, DDD helps by clearly separating domain logic into bounded contexts, making business logic easier to reason about. SOA and Modular Monolith, however, manage complexity through technical separation and deployment boundaries.

While all three approaches aim to split a system into logical components, they each serve a different purpose: DDD is about domain modeling, SOA is about building distributed systems, and Modular Monolith is about maintaining a modular yet unified application structure.

It's important to remember that choosing an architectural pattern depends on the specifics of the project, the available budget, and the client’s long-term goals. In some cases, it makes sense to start with a simpler architecture – like MVC – and gradually move toward DDD as the project grows and the business logic becomes more complex.

Conclusion

Modern MVC implementations using IoC and DI are powerful and well-suited for small to mid-sized projects. However, as systems grow and business logic becomes more complex, challenges arise around scalability, code fragmentation, and maintainability.

Alternative architectures – such as SOA, DDD, Modular Monolith, and Microservices – offer clear boundaries, component isolation, and development flexibility, making them better suited for large and fast-evolving products.

When choosing your architecture, weigh the specifics of your project: testability, scalability, long-term maintainability, and business goals. There’s no one-size-fits-all, and sometimes it makes sense to start with a simpler MVC model and evolve to DDD or microservices as the product matures.

In the next article I’ll dive into real-world use cases for each architectural pattern and compare them in practice.

Here was dev.family!

The future of voice commerce: how to use speech recognition and voice search in 2025

Max Bantsevich — Thu, 13 Mar 2025 11:24:28 +0000

🗣️66% of businesses see a voice-enabled customer experience as critical to their future, yet only 28% of businesses have adopted it.

From drive-thru automation to personalized orders – voice commerce is changing the way customers interact with brands.
On the one hand business got:
👌🏻 Automated service support
👌🏻Smart and personalized offerings
👌🏻Increased conversion rate

On the other hand, there are still bugs and errors in speech processing that result in:
🫠 Errors in speech interpretation
🫠🫠 Privacy concerns
🫠🫠🫠 Customer frustration with glitches

See how voice tech is reshaping restaurant & retail in our new article

Telegram mini-app development and testing specifics: from initialisation to launch

Max Bantsevich — Tue, 11 Mar 2025 10:58:06 +0000

We receive more and more requests for Telegram mini apps development. Why is this happening? Telegram continues to grow actively, and companies want to reach this audience by offering convenient solutions within the messenger, where their customers spend a significant part of their time.
The dev.family team has already talked about these and other benefits for business in one of our articles.

From a technical point of view, mini apps also have their advantages: they allow full-fledged applications to be launched directly in Telegram, without the need to develop separate native mobile versions. This significantly reduces development and support costs and speeds up the product's time to market.

In this article, I will share my own experience of developing Telegram mini apps and answer the following questions:

What are Telegram mini apps?
How are they different from other platforms?
What are the development prospects for Telegram mini apps?
How to properly test Telegram mini apps, taking into account the peculiarities of the platform?
How to set up the environment for a future application and initialise the Telegram apps SDK?
What are the nuances of Telegram mini apps development?

What are Telegram mini apps and why are they so popular

Today, Telegram mini apps allow us to open any website from within the messenger. The technology is implemented with the help of a special WebView browser shell – a system component that is responsible for integrating web pages into other applications and adapting to the device's operating system.

A Telegram mini app can be any application that can be written in JavaScript or any tool that can be compiled into it. For example, React, Next.js, Angular or even React Native for Web.

The product can either be a standalone solution or part of a business ecosystem. We have already told you in our Telegram mini app tutorial how to integrate a ready-made React Native application into Telegram using the react-native-web package.

Development prospects for Telegram mini apps
The number of Telegram users is gradually approaching one billion. Imagine giving them access to a cross-browser application that runs on any operating system, be it iOS, Android, Windows, macOS or Linux. And it doesn't require any mobile development. Now you can add the mini app to the desktop of your device and open it full screen as a standalone application. And it seems we are only at the beginning of its development path.

The functionality of Telegram mini apps and the possibility of integrating additional services and tools is quite wide: we can use accelerometer, gyroscope, biometrics, have access to geolocation, receive push notifications and much more.

Of course, many things can be done using the standard browser API. But Telegram simplifies user interaction, permissions, payments, data exchange and bot management by providing all the necessary tools. And thanks to Telegram's built-in security, mini apps can be more secure than traditional web apps.

I am sure that in the future Telegram will develop the mini apps format towards mobile development. There will be more and more opportunities to access the hardware features of devices, such as Bluetooth, NFC, Wi-Fi, flashlight, contacts, calendar and so on.

Working with Telegram mini apps is also very convenient for the user: if the messenger is already installed on the device with a connected account, there is no need to download anything additional. All the functionalities are already available in Telegram.

Businesses, in turn, get a convenient mobile app without having to resort to mobile development, which is usually more expensive than web development. Once we write an app competently, we can run it in the browser, mobile and desktop versions of Telegram, getting more opportunities and conversions for less cost.

How to properly test and debug the Telegram mini app

Let's go ahead and start with the peculiarities of testing Telegram mini apps, because we'll talk about them later in the development section. So it is important to set the context. The main difficulty is the inability to launch the project as easily as in a browser via localhost, and the lack of a developer console. However, these problems are easily solved.

As we have already seen, the Telegram mini app is a website that, when linked to, will run in the Telegram environment. So we need to pass a link that displays the development environment. This is done using port forwarding.

There are two ways of doing this.

In the first case, we use the third-party utility ngrok. But it only has a monthly limit on the number of connections, so this option is not very suitable for development.

In the second case we can use VSCode, where we need to open our project and run it as localhost. Next, open the terminal, go to the 'Ports' tab, type in the port number and you will get a link to the redirected port, which can now be used to access our localhost. We will use this link as the link to the mini app in the chatbot.
It looks like this: https://d0etr6gh-3000.euw.devtunnels.ms.

A redirected port can be created as follows:

Private – no one but you will be able to access it;
Public – the port will be available to everyone if we want to share the link to the application with others.

So we can launch our Telegram mini app and follow the development process in real time, because Hot Reload works just like in a browser.

But how do you debug an application without access to the developer console? To do this, let's learn about Eruda.

Eruda is a mobile development console that can be launched in any environment. All you need to do is click on the button that is embedded in your application after initialising this library.
This is what it looks like:

Below we'll go through how to create a mini app in Telegram from scratch and set up an initial template to initialise the telegram-apps/sdk-react package and the app itself. We will see how easy it is to integrate the Eruda package into our project.

You can also read the documentation and connect the package in a different way. Either way, it will only take a few lines of string.
In addition, I would like to mention one more thing that relates to testing.

If you try to open the app in a browser, you will see the following error:
“Unable to retrieve launch parameters from any known source. Perhaps, you have opened your app outside Telegram?”

The message says that the mini app cannot be launched outside the Telegram environment.

Let's move from theory to practice.

However, we can configure our application to open in a browser. We will not be able to get real data from Telegram, but we will add mock data that will mimic the environment we need.

Development of Telegram mini app from scratch

We have already described the process of creating a chatbot in Telegram using BotFather in this article.

So let's move on to the code itself.

The next step is to initialise the mini app project. In general, the Telegram developers have gone to the trouble of preparing a selection of ready-made template that you can use depending on the technology. For example, here are variants for Next.js and React.js.

✍ Does it make sense to use Next.js? Unfortunately, mini apps are not currently able to fully adapt to SSR, ISR and other rendering methods. Communication with Telegram happens through the use of a window object, which is impossible to get on the server side.

So if your application involves user identification or a chatbot, you will not be able to do this on the server and queries will have to be executed on the client. However, this does not change the fact that Next.js has additional benefits, features and optimisations over React and can still be used for mini app development.

Let's go back to the code. We took one of the ready-made templates and adapted it for our purposes, removing anything unnecessary and adding additional logic. To work with Telegram mini apps, we used the @telegram-apps/sdk-react package. Let's talk about it in a bit more detail.

We have a provider that is used in the root barkout to initialise this package and wrap the whole app.

It looks something like this:

<html lang={locale} className={`${GeologicaFont.variable}`}>
<body>
         <TelegramSDKInitProvider>
           <AppInitProvider>
               <div className={styles.layout}>{children}</div>
           </AppInitProvider>
         </TelegramSDKInitProvider>
     </body>
   </html>

What happens here and why do we need two providers?

First, all the logic is executed inside TelegramSDKInitProvider: the package is initialised so that we can get the user data and use the Telegram API in our application. We check the environment and mock the data if we are in development mode. This is to imitate the Telegram environment to run the application in the browser.

If we are in a production environment, it makes more sense to show an error or inform the user that the app needs to run inside Telegram. And ideally, add a link and QR code to the interface to go directly to the messenger.

'use client'

import { type PropsWithChildren } from 'react'

import { useClientOnce } from '@/src/hooks/useClientOnce'
import { useTelegramMock } from '@/src/hooks/useTelegramMock'

import { telegramSDKInit } from './init'

export function TelegramSDKInitProvider({ children }: PropsWithChildren) {
 if (process.env.NODE_ENV === 'dev') {
   useTelegramMock()
 }

 useClientOnce(() => {
   telegramSDKInit(false)
 })

 return children
}

Inside the useTelegramMock hook we use a check provided by the package itself – isTMA. This allows us to determine if we are in the Telegram environment. If we are not, we mock the data, if we are, we exit the function.

import { isTMA, mockTelegramEnv, parseInitData } from '@telegram-apps/sdk-react'

import { useClientOnce } from './useClientOnce'

export function useTelegramMock(): void {
 useClientOnce(() => {
   let shouldMock: boolean
   const MOCK_KEY = '____mocked'

   if (isTMA('simple')) {
     shouldMock = !!sessionStorage.getItem(MOCK_KEY)
   } else {
     shouldMock = true
   }

   if (!shouldMock) {
     return
   }

   const initDataRaw = new URLSearchParams([
     [
       'user',
       JSON.stringify({
         id: 99281932,
         first_name: 'Arthur',
         last_name: 'Mocked',
         username: 'arthurmocked',
         language_code: 'en',
         is_premium: true,
         allows_write_to_pm: true,
         photoUrl:
           'https://t.me/i/userpic/320/haNXSpRmeucJyo-oXFbNrifxZ-Au0PjvhpJ2l6h4ozcTbTT8yvNKIZABSCLpjtIp.svg',
       }),
     ],
     ['hash', '89d6079ad6762351f38c6dbbc41bb53048019256a9443988af7a48bcad16ba31'],
     ['auth_date', '1716922846'],
     ['start_param', 'debug'],
     ['chat_type', 'sender'],
     ['chat_instance', '8428209589180549439'],
   ]).toString()

   mockTelegramEnv({
     themeParams: {
       accentTextColor: '#6ab2f2',
       bgColor: '#17212b',
       buttonColor: '#5288c1',
       buttonTextColor: '#ffffff',
       destructiveTextColor: '#ec3942',
       headerBgColor: '#17212b',
       hintColor: '#708499',
       linkColor: '#6ab3f3',
       secondaryBgColor: '#232e3c',
       sectionBgColor: '#17212b',
       sectionHeaderTextColor: '#6ab3f3',
       subtitleTextColor: '#708499',
       textColor: '#f5f5f5',
     },
     initData: parseInitData(initDataRaw),
     initDataRaw,
     version: '8',
     platform: 'tdesktop',
   })
   sessionStorage.setItem(MOCK_KEY, '1')

   console.info(
     '⚠️ As long as the current environment was not considered as the Telegram-based one, it was mocked. Take a note, that you should not do it in production and current behavior is only specific to the development process. Environment mocking is also applied only in development mode. So, after building the application, you will not see this behavior and related warning, leading to crashing the application outside Telegram.',
   )
 })
}

We can use our own data. For example, from your Telegram account.
Now we can run our app both in Telegram and in any browser.

Next, we run telegramSDKInit, which initialises the SDK package and performs the initial configuration of the application. For example, configuring the full screen mode or the behaviour of closing the app with vertical swipes.

This is also where we initialise the Eruda mobile console that I mentioned in the testing section. The initialisation happens only once – when the app is launched, which is controlled by the useClientOnce hook.

import {
 $debug,
 backButton,
 expandViewport,
 init as initSDK,
 initData,
 miniApp,
 swipeBehavior,
 themeParams,
 viewport,
} from '@telegram-apps/sdk-react'

export function telegramSDKInit(debug: boolean): void {
 $debug.set(debug)

 initSDK()
 expandViewport()

 if (backButton.isSupported()) {
   backButton.mount()
 }

 miniApp.mount()
 themeParams.mount()
 swipeBehavior.mount()
 initData.restore()

 void viewport
   .mount()
   .then(() => {
     viewport.bindCssVars()
     miniApp.bindCssVars()
     themeParams.bindCssVars()
     viewport.requestFullscreen()
     swipeBehavior.disableVertical()
   })
   .catch((e: unknown) => {
     console.error('Something went wrong mounting the viewport', e)
   })

 debug && import('eruda').then((lib) => lib.default.init()).catch(console.error)
}

Then the AppInitProvider logic is executed, where we show the download status instead of the content, as our app is not ready to use yet. Here we already have access to the Telegram API, so we get the data we need (e.g. user data). Next, we will either record the user ID in cookies or perform an authorisation request, passing the necessary data from Telegram.

Once all the manipulations are done, we can display the rest of the application.

An AppInitProvider could look like this:

'use client'

import { initData, useSignal } from '@telegram-apps/sdk-react'
import { setCookie } from 'cookies-next'
import type { PropsWithChildren } from 'react'
import { useCallback, useEffect, useState } from 'react'

import { postAuthLogin } from '@/src/api/schema'
import TelegramMiniAppLoader from '@/src/components/ui/TelegramMiniAppLoader'
import Title from '@/src/components/ui/Title'
import { AUTH_TOKEN, TELEGRAM_USER_ID } from '@/src/constants'

const AppInitProvider = ({ children }: PropsWithChildren) => {
 const [isAppReady, setIsAppReady] = useState(false)
 const [error, setError] = useState(null)

 const initDataState = useSignal(initData.state)
 const initDataStateRaw = useSignal(initData.raw)

 const userId = initDataState?.user?.id

 const logError = useCallback((message: string) => {
   console.error(message)
   setError(message)
 }, [])

 const authenticateUser = useCallback(
   async (rawData: string) => {
     try {
       const { data } = await postAuthLogin({ init_data: rawData })

       if (data) {
         setCookie(AUTH_TOKEN, data.token)
         setIsAppReady(true)
       } else {
         logError(`Auth token is missing. Response: ${JSON.stringify(data)}`)
       }
     } catch (err) {
       logError(
         `Authentication failed: ${err instanceof Error ? err.message : JSON.stringify(err, null, 2)}`,
       )
     }
   },
   [logError],
 )

 const initApp = useCallback(() => {
   if (!userId) {
     logError(`Telegram user ID is absent. User ID: ${userId}`)
     return
   }

   setCookie(TELEGRAM_USER_ID, userId)

   if (!initDataStateRaw) {
     logError('Telegram raw data is undefined.')
     return
   }

   authenticateUser(initDataStateRaw)
 }, [userId, initDataStateRaw, authenticateUser, logError])

 useEffect(() => {
   console.log('Initializing app with raw data:', initDataStateRaw)
   initApp()
 }, [initApp, initDataStateRaw])

 if (error) {
   return {error}
 }

 return isAppReady ? <>{children} : 
}

export default AppInitProvider

Our application is now fully initialised and ready to run.

Specifics of Telegram mini app development

Let's look at the key issues and challenges you need to understand to ensure a stable application and user experience.

WebView limitations

Since Telegram mini apps are based on the WebView interface, not all of the features we use in browsers will work here.

In our app we use iFrame. And if we want to open it in full screen, we can use the requestFullScreen method. Unfortunately, this doesn't work for WebView. Also, some icons may display differently or not at all. Especially if gradients are used inside. Problems can also occur when using WebSocket, which might requires additional configuration. It is therefore important to spend extra time on development to fix any bugs.

Also, I have often seen comments on forums that using WebView causes performance degradation. Especially on low-power devices and when there are a lot of complex animations. Some developers even include the ability to disable animations in the app so users don't experience performance issues.

Dependency on Telegram API

Despite the popularity of Telegram, the platform also has its own bugs that can affect your app. Here's a case study example.
Telegram automatically handles situations where a virtual keyboard is opened on mobile devices and automatically moves content so that they do not overlap. On the one hand, this is very convenient – developers don't have to write additional logic if, for example, the input field is at the bottom of the screen. On the other hand, at the time of writing, this feature still does not work correctly on iOS devices, which can lead to some limitations for users.

Limitation in working with query parameters

If you try to pass initial parameters to a mini app link, Telegram will simply cut them out. According to the Telegram mini app documentation, we can only pass one parameter called startapp. The process looks like this: https://t.me/botusername/appname?startapp=someParamValue
But if you need to pass multiple parameters, you can use the following trick: we still pass one parameter in the reference, but it has many other parameters nested within it with a specific delimiter. For example, '_ _'.

https://t.me/botusername/appname?startapp=param1value__param2value__par
am3value
const [param1, param2, param3] = lp.startParam.split("__");

Client-side nature of app

It is also important to remember that mini apps run primarily on the client side. This limits the use of server-side rendering (SSR), because to use the Telegram API you need access to the window object, which is only available on the client.

Peculiarities of the Telegram platform

To create a Telegram mini app, you need to understand the specifics of the platform itself and the specifics of working with WebView.
For beginners, I recommend to pay attention to the following:

Telegram WebApp API – interact with buttons, events, get user data. Study the library documentation if you plan to use it to work with Telegram;
Permission handling – proper handling of initData and signature verification. Authorisation is taken to a new level here, eliminating the need to constantly create and store tokens on the client side;
Platform limitations – specifics of rendering, navigation and integration with front-end frameworks (e.g. Next.js);

Interface customisation – working with dark and light themes, WebView customisation, and developing workarounds for platform limitations.

✍ This may seem complicated and time-consuming, but learning new things is an important part of being a programmer. In the future, Telegram will certainly continue to develop its API and expand support for device hardware capabilities.

The sooner you start working with this format, the sooner you'll learn to develop cross-platform solutions, get a deeper understanding of external API integration, and gain experience with scalable applications for an audience of billions.

The dev.family team has been in touch 💜💚
See you soon!

P.S. As per tradition, here are the links to the artefacts:
Telegram mini apps documentation:

https://core.telegram.org/bots/webapps
The documentation of the package for interacting with the Telegram API is telegram-apps/sdk-react: https://docs.telegram-mini-apps.com/packages/telegram-apps-sdk-react/2-x
Templates from Telegram developers: https://github.com/Telegram-Mini-Apps#templates
Telegram mini apps template for Next.js: https://github.com/Telegram-Mini-Apps/nextjs-template
Telegram mini apps template for React.js. https://github.com/Telegram-Mini-Apps/reactjs-template
Eruda documentation: https://github.com/liriliri/eruda
ngrok: https://ngrok.com/docs/pricing-limits/free-plan-limits/

How to add a card to Apple Wallet and Google Wallet 📱 in React Native?

Max Bantsevich — Thu, 07 Nov 2024 12:30:21 +0000

Mobile developers can use Apple Wallet and Google Wallet integrations for different types of apps:

Boarding pass storage and hotel reservations;
Card for short-term rental;
Passes for buildings or events;
Scan tickets for travel or subscriptions;
Store loyalty cards and gift vouchers;
Providing contactless payment, etc.

Once we already wrote our own library for Apple Wallet in React Native because we couldn't find anything ready to use. As true open source enthusiasts, we have already shared this version with you. But now that Google Wallet is fully released, it's time to update it.

Now, this library provides integration with both Apple Wallet on iOS and Google Wallet on Android. It allows you to add, remove, and check for existing passes on iOS, and add passes to Google Wallet on Android.

Readme

To download the library go here.

You can find out more about disruptive with React Native you’ll find in our blog.

How to build a Web App: Deploying Telegram mini-app

Max Bantsevich — Thu, 31 Oct 2024 14:45:33 +0000

Hi there, it's the dev.family team again! We're continuing our experiment with building an app in React Native that works as as a Telegram Web App. In our previous episodes, we discussed:

The specifics of building a React Native web application using react-native-web and where we deviated from the documentation. You can find all the code and details of the process in the first part;
The reasons why companies choose to run web applications on messenger apps.

Now, let's focus on installing the web app itself within the Telegram bot.

Web AppDeployment

In the last part we finished the preparatory work. Now let's deploy our site.

We will use Firebase to deploy the clicker. There are two options:

The first (and easiest) is a simple command line deploy;
The second (a bit more complicated) is a commit/merge/PR deploy via github actions.

For the purposes of this article, let's look at the fastest option.

Let's create a project in the Firebase Console. Follow the link and click on the 'Create Project' button.

Specify the name of our project:

Next, click ‘Continue’ several times, select Default Firebase Account (if you have a different one, you can select it), and click Create Project.

The new project is successfully established:

Now go to the project and click the 'Add Web Application' button:

Next, enter the name of the project:

You can leave the 'Set up Firebase hosting too' checkbox unchecked. Click on the 'Register application' button and you will see two options with instructions on how to install the Firebase tools in our project.

We won't use the option via npm, but via the script tag, as we don't need it for the mobile application. You can choose any convenient option.

This completes our work with Firebase Console, let's return to the application.

Note: It is not recommended to put all these keys directly in the html file. It is better to create an .env file and put them there.

.env

VITE_FIREBASE_API_KEY=
VITE_FIREBASE_AUTH_DOMAIN=
VITE_FIREBASE_PROJECT_ID=
VITE_FIREBASE_STORAGE_BUCKET=
VITE_FIREBASE_MESSAGING_SENDER_ID=
VITE_FIREBASE_APP_ID=
VITE_FIREBASE_MEASUREMENT_ID=

Notice that all of the keys we use start with the word ‘Vite’. We do this because we are using Vite as an assembler. And when accessing environment variables via import.meta.env, it may not recognise them without this.

Next, let's edit our index.html a bit, taking into account what we've written above.

index.html

<html>
<body>
...
<script type="module">
 import { initializeApp } from "https://www.gstatic.com/firebasejs/10.13.0/firebase-app.js";
 import { getAnalytics } from "https://www.gstatic.com/firebasejs/10.13.0/firebase-analytics.js";
  const firebaseConfig = {
   apiKey:import.meta.env.VITE_FIREBASE_API_KEY,
   authDomain: import.meta.env.VITE_FIREBASE_AUTH_DOMAIN,
   projectId:  import.meta.env.VITE_FIREBASE_PROJECT_ID,
   storageBucket: import.meta.env.VITE_FIREBASE_STORAGE_BUCKET,
   messagingSenderId: import.meta.env.VITE_FIREBASE_MESSAGING_SENDER_ID,
   appId: import.meta.env.VITE_FIREBASE_APP_ID,
   measurementId: import.meta.env.VITE_FIREBASE_MEASUREMENT_ID,
 };


 const app = initializeApp(firebaseConfig);
 const analytics = getAnalytics(app);
</script>
<script src="./index.web.js" type="module"></script>
</body>
</html>

Open a terminal, go to the root of the project and type the command:

firebase login

Then we go to the browser window and authorise through the Firebase console.

firebase init

Select the highlighted item and press Space, then Enter.

The next step is to resolve a number of configuration issues. Add the following:

Please select an option – here we select Use an existing project. And from the list below – a recently created project;
What do you want to use as your public directory? – select dist (this is where our unit will be located);
Configure as a single-page app (rewrite all urls to /index.html)? – y;
Set up automatic builds and deploys with GitHub? (y/N) – N (we don't need it at this stage);
File dist/index.html already exists. Overwrite? (y/N) – N.

Go to firebase.json and modify it a bit.

firebase.json

"hosting": {
   "public": "dist",
   "ignore": [
     "firebase.json",
     "**/.*",
     "**/node_modules/**",
     //past here
     "**/android/**",
     "**/ios/**"
   ],
   "rewrites": [
     {
       "source": "**",
       "destination": "/index.html"
     }
   ]
 }
}

Add the Android and iOS directories to ignore during deployment. Since we have a web application, we don't need to send all the files to a hosting service. Also, they're quite heavy and you won't be able to download them without some sort of subscription.

So, we're nearing the finish line. There's just one more command to write.

firebase deploy

Now click on the link below. Our application is already hosted!

All you have to do is deploy the app on Telegram.

Installing a web app in a Telegram bot

Let's take a look at what's currently available:

A working app on iOS;
A working app on Android;
A working web app, already hosted.

With one last tap, you can add an app to the list in a messenger app. Open a bot called BotFather in Telegram and start a dialogue.

Choose the option /newbot:

Give our bot a name. This will create an API key for interacting with our bot via HTTP.

Next, write the command /mybots and choose the currently created bot. Go to bot settings.

Choose the point Configure Mini App.

You may see a message saying that the Mini App is disabled for our Telegram bot. That's fine. Just click on the Enable Mini App button.

Now we just pass the URL where our web application is hosted.

Now let's configure the menu button. To do this, go back to the bot settings and select Configure Menu Button. Again, you may be told that the button is currently disabled and offered the option to enable it. Accept and give it a name.

The time has come: let's see how our guy works. Let's go to the bot – @ReactNativeWebClickerBot (you can rate it too, we'd appreciate it 😌). We open it up and make sure it works!

All theme settings are synchronised, as is the username. If you enter the bot from the mobile app and click on a coin, you can feel how well the haptic response works.

Conclusion

In this experiment, we break down in detail how you can:

Build a web app based on a mobile app written in React Native using react-native-web;
Deploy it via Firebase;
Use it in a Telegram mini-app;
Interoperate with the Telegram client in our shared codebase.

The technologies described can be used not only for Telegram, but also for other platforms. So you can create cross-platform solutions that work on the same code.

Why it's good:

Your app will work across channels and be featured in multiple stores, allowing you to reach more users;
The speed of product development will increase significantly – the average time to release will be reduced by 20%, meaning a faster time to market;
Most of the code base can be reused, making updates and bug fixes easier.

The main thing is to remember the specifics of each platform and take them into account when developing.

We've deliberately left some parts of the code unwritten so that you can fill them in yourself. If you like, add Telegram user validation, check if the user is present in the mobile app and set up a Firebase deployment via GitHub Actions. In short, experiment to get the best results.

As usual, we leave links to the useful resources:

React Native Web documentation;
Telegram mini-app documentation;
Link to Firebase
All code in Github
@ReactNativeWebClickerBot itself.

What if we told you that you don't need an app or a website to sell online? Go to Messenger and launch your Telegram WebApp.

Max Bantsevich — Thu, 24 Oct 2024 16:26:56 +0000

Companies are moving to web apps in messengers. And here are the reasons why you should join them:
🟣 Increase market share by entering the channel with a constantly active audience;
🟢 Boost sales with an easy ordering process in just a few clicks;
⚪️ Keep users engaged by communicating with them in one channel.

It only takes a few seconds for customers to order food from the restaurant, pay for services and book the time to visit your establishment in messengers like WhatsApp or WeChat. Find more ideas for web applications in our article

Using BLE technology when working with beacon in React Native

Max Bantsevich — Thu, 10 Oct 2024 13:41:59 +0000

If you decide that you want to use this solution in your project, you will need:

Beacon: Select a suitable BLE beacon that meets your range requirements. You can find a large number of beacons on Aliexpress, we used HOLY-IOT.
BLE-enabled smartphone or tablet: A device to test and use your application that is compatible with Bluetooth Low Energy technology. For our solution, iPhone with iOS 9.0 and higher, Android with 7 and higher are suitable.
Development tools for your application, such as VSCode, as well as React Native and the react-native-ble-plx library.

Now you can start implementation.

Data collection
To collect RSSI data we will use the react-native-ble-plx library. We use the startDeviceScan method. This method allows you to scan BLE devices within range and obtain information about them, including RSSI. Here's an example of how you can implement RSSI data collection for specific devices:

import { BleManager } from "react-native-ble-plx";

const NAME = "HOLY-IOT";

const bleManager = new BleManager();

// Function to start scanning BLE devices
function startScanning() {
  // The first parameter is the UUIDs of services (null if you want to scan all devices)
  // Second parameter - scanning options
  // The third parameter is a callback called when a device is detected
  bleManager.startDeviceScan(null, null, (error, scannedDevice) => {
    if (error) {
      console.warn(error);
      return;
    }

    if (scannedDevice && scannedDevice.name === NAME) {
      console.log(scannedDevice.name, scannedDevice.rssi); // to find the device we need
      // hereinafter we will process RSSI
    }
  });
}
// Stop scanning if necessary
function stopScanning() {
  bleManager.stopDeviceScan();
}

Also be sure to request location permissions if you're on Android, as this is required to scan BLE devices starting with Android 6.0 (API level 23).

In this example, all available BLE devices are scanned every time a device with a given UUID is detected. The console will display the device name and its RSSI.

Please note that Bluetooth on iOS and Android may require permissions and privacy settings, including a request for location access and an explanation of why your app needs this permission in the Info.plist (iOS) and AndroidManifest.xml files (Android) respectively.

Distance estimation based on RSSI

To calculate the distance between the BLE device and the beacon based on the RSSI value, we use this formula:

d — distance to the device (beacon),
TX Power — signal power measured at a standard distance (usually 1 meter) from the beacon,
RSSI — signal strength,
n — is the signal attenuation factor (environmental factor), reflecting the loss of the signal in the environment; typical values range from 2 to 4.

This formula allows you to estimate the distance between two devices using the logarithmic relationship between the change in signal strength and distance.

The value of the signal attenuation coefficient n depends on the specific environmental conditions in which the signal is transmitted.

Open space without obstacles: An n value of about 2. This condition assumes minimal signal attenuation when there are no significant obstacles between devices and the signal can travel in a straight line.

**Indoors with obstacles: **The n value can vary from 2.5 to 3.5 or even higher. Indoors, the signal can be reflected from walls, ceilings and other objects, which increases attenuation. Higher values of n are used to account for this additional attenuation.

Challenging environments with many obstacles: In environments with a high density of obstacles, such as warehouses, manufacturing facilities, or urban environments with many reflective surfaces, the n value can be set in the range of 4 to 5. These environments require a higher attenuation factor to compensate for significant signal losses.

It is important to understand that determining the most appropriate value for n often requires an empirical approach. This means running tests in the target environment to measure the actual signal distribution and tailoring the attenuation factor to achieve the best accuracy in distance estimation.

What will this look like in practice?

We have already obtained RSSI values from scanning devices as shown in the previous example. Now let's add a function to calculate the distance:

function calculateDistance(rssi, measure = -69, multiplier = 2) {
  return Math.pow(10, (measure - rssi) / (10 * multiplier));
}

bleManager.startDeviceScan(null, null, (error, scannedDevice) => {
  if (error) {
    console.warn(error);
    return;
  }
  if (scannedDevice && scannedDevice.name === NAME) {
    const distance = calculateDistance(scannedDevice.rssi);
  }
});

Increasing measurement accuracy

Factors such as physical obstructions, interference from other signal sources, and hardware differences can distort RSSI. Various filtering techniques are used to improve measurement accuracy.

We will use a simple moving average method, which is used to smooth out time series data and reduce random fluctuations.

To implement this technique, we will store the last few RSSI measurements for the device and calculate the average of them.

const rssiValues = {}; // object for storing arrays of RSSI values

function addRssiValueAndGetAverage(deviceId, newValue, maxSize = 3) {
  if (!rssiValues[deviceId]) {
    rssiValues[deviceId] = []; // Initialize the array if this is the first value
  }
  const values = rssiValues[deviceId];
  values.push(newValue); // Add a new value

  // Remove the oldest value if the maximum array size is exceeded
  if (values.length > maxSize) {
    values.shift();
  }

  // Calculate the average value
  const averageRssi = values.reduce((acc, value) => acc + value, 0) / values.length;
  return averageRssi;
}

bleManager.startDeviceScan(null, null, (error, scannedDevice) => {
  if (error) {
    console.warn(error);
    return;
  }
  if (scannedDevice && scannedDevice.name === NAME) {
    const averageRssi = addRssiValueAndGetAverage(scannedDevice.id, scannedDevice.rssi);
    console.log(`Average RSSI value for device ${scannedDevice.name}: ${averageRssi}`);
  }
}); // Here you can use the average RSSI value to estimate the distance } });

Why did we do all this?

It is worth noting that this method allows you to achieve an approximate estimate of the distance to the beacons. Despite the introduction of algorithms to improve measurement accuracy, it must be recognized that the results obtained remain approximate. Also, a feature of this implementation is that it works only when the application is in the active state (foreground state), which imposes certain restrictions on the scope of its application.

However, even in its current form, this system can find wide application in various scenarios. Examples include localization and navigation indoors, such as shopping malls, museums, warehouses, where it is important to provide users or employees with information about nearby objects and traffic routes.

In the future, we plan to develop an improved version that will be able to function not only when the application is active, but also in the background state. This will expand the scope of the technology, making it suitable for real-time monitoring and tracking tasks without the need for constant user interaction with the application.

The development and improvement of the tracking system using BLE and RSSI opens up new prospects for creating effective and convenient solutions in a variety of areas, from retail to food tech, providing a new level of user experience.