Forem: Dmitriy Kasperovich

How We Saved 600 Hours of Support Work with AI in a Ticketing System

Dmitriy Kasperovich — Tue, 16 Sep 2025 23:04:32 +0000

This isn’t just another “we taught AI to answer reviews and now everything is magic ✨” story. Nope. This is about building a custom ticketing system for a support team—complete with business rules, multiple LLMs (ChatGPT and Gemini), and real humans doing quality control (because let’s be honest, AI still occasionally hallucinates
).

Why feedback matters

User feedback is basically free consulting. Entire industries (gaming, foodtech, SaaS, e-com, delivery—you name it) thrive or crash based on what customers type into a review box: ratings, rants, bug reports, thank-you notes, and sometimes, full-blown essays. Each one is a signal telling you whether your product is a rocket ship 🚀 or a sinking boat 🛶.

And those signals? Yeah, they’re multiplying faster than npm packages. According to HubSpot’s Annual State of Customer Service Report, 75% of support pros saw the biggest tidal wave of inquiries ever in 2025.

When request volume is chill, no problem. But drop a flagship product, or let a bug slip into your checkout flow, and boom—you’ll get more reviews than your support team has caffeine to process.

And here’s the kicker: every customer, happy or mad, expects a reply. Silence costs more than an AWS bill left running over the weekend:

75% of customers will pay more for excellent service (Zendesk Benchmark Data).
43% of customers say one bad support experience = never buying again (Salesforce).
Negative vibes put \$3.7 trillion of global sales at risk every year (Qualtrics).

So yeah - systematic feedback management isn’t a “nice-to-have,” it’s survival mode.

Ticketing systems and help desks exist to bring order to chaos. They take in requests, turn them into structured tickets, assign them to humans, track status, and spit out analytics.

But businesses still wonder:

“Can we find a system that hoovers up reviews from app stores, emails, smoke signals, whatever, and turns them into tickets instantly?”
“Do we really need two different platforms for analytics and ticketing, or can someone please mash them together?”
“Why the heck do we always have to choose between automation and analytics when obviously we need both?”

For our client, Malpa Games, we built a system that did exactly that: review aggregation + analytics in one place. First release? Already useful. Then came the fun question:

Could AI cut repetitive support work while boosting team productivity?

Spoiler: yup. Big time.

AI and Ticketing Systems: From Review Processing to Product Analytics

Customer support effectiveness is usually judged by three key CX metrics (2025 data drop incoming):

CSAT (Customer Satisfaction Score): top priority for 31% of businesses.
Customer retention (aka the real money metric): also 31%.
Response time (nobody likes waiting): 29% (HubSpot).

In gaming, reviews are basically endless:

Some are short “⭐️⭐️⭐️⭐️⭐️ great game lol” posts.
Others are multi-paragraph rage dumps.
Many are direct “support me please” questions.

Handling this by hand? Absolute time sink. Businesses really care about two things here: speed and consistency. If you’re slow, CSAT tanks. If your answers are inconsistent, retention tanks. Either way, you lose.

Automation is now mandatory. Even players agree: 46% say they’re cool with AI support if it just solves the problem (Salesforce).

So, Malpa Games plugged AI into their shiny ticketing system to solve four real-world challenges:

Detect sentiment (negative/positive/neutral). Prioritize angry users first. Close happy ones fast.
Identify root cause of bad feedback (ads, bugs, crashes). Product teams love this—it’s basically free QA.
Auto-tag reviews for clean analytics. Goodbye manual labeling.
Draft replies (or pull from templates) for standard cases. Humans only step in for tricky tickets that need empathy.

To test this, we wired in ChatGPT and Gemini side by side. The goal: compare classification accuracy and “reply style” in the wild. One model will eventually win the Hunger Games, but for now we’re letting them battle it out.

Full Malpa Games case study has more juicy details.

How Ticket Automation with AI Works

We started small (but impactful). Right now, AI closes:

Empty tickets (just a star rating + metadata).
Short positive reviews with zero questions.

The model scans, checks rules, and picks a reply from our directory of auto-templates.

Bonus: we store several templates per ticket group and pick randomly—because nothing screams “I’m a bot” like copy-pasting the exact same thank-you note 10,000 times.

Example flow:

User leaves: ⭐️⭐️⭐️⭐️⭐️ Everything’s great!
AI detects: English, <50 chars, rating=5, no question.
System replies (in user’s language), picking one of these:
- “Thanks for the review! Glad you’re enjoying the game 😊”
- “Thanks for the high rating! Enjoy!”
- “Thanks for playing – it really motivates us!”

Ticket closed. No humans harmed in the process. Player gets a quick, friendly reply.

The flow:

Ticket enters system. If it’s just stars, auto-reply + close.
If positive rating + text → AI finds language + context → both models suggest replies.
Support manager can regen/translate → copy → send → close.

Automation Rules

We didn’t let AI run wild. Instead, we gave it strict parenting rules via the auto-reply directory.

Rules control everything:

By language → only reply in supported languages.
By text length → short = auto, long = human.
By rating → positive = auto, negative = human.

You can also assign project-specific rules, because one-size-fits-all is for socks, not ticketing.

Integration Results

Year one stats:

10,000 empty tickets closed.
8,000 short reviews closed.
Total = 18,000 tickets out of 47,000 (~40% of flow).

Each simple ticket normally eats 2 minutes of a human’s life (open → read → tag → reply → send). AI did all that 18,000 times.

That’s 600 hours saved—basically 4 months of one full-time support manager. Not bad for a sidekick that never takes coffee breaks. ☕

Three Lessons from Automating Support with AI

Malpa Games showed us:

Even simple automation matters. Closing empty/short reviews shaved hundreds of hours and stabilized response times.
Classification = product insights. Sentiment + root cause tagging helps product prioritize bugs, not just support.
AI augments, doesn’t replace. Draft replies cut response time, freeing humans to handle complex cases with empathy.

What’s next? Smarter stuff: forecasting workload, auto-routing tickets, dynamically generating answers from KBs or user data. That’s when AI stops being a helper bot and becomes a strategic weapon for scaling support.

Building Extendable CRUD: How I Use Admiral to Create Flexible Admin Interfaces

Dmitriy Kasperovich — Tue, 16 Sep 2025 22:47:01 +0000

I’ve been getting more and more requests lately to build custom booking systems with admin panels that manage records and directories. This comes up a lot in B2C services — think beauty studios or clinics — where the admin panel has to be quick to build, affordable, and seamlessly integrated into existing workflows. Nobody wants to spend weeks training staff or risk disrupting daily operations.

Most aggregator platforms stick to a linear model: one specialist, one service, one time slot. Sounds simple — until you need to handle group bookings or overlapping workflows where one staff member is involved in multiple stages of a procedure.

Throw in the constant stream of changes — cancellations, reschedules, service swaps — and you quickly realize: the system has to react instantly and update the interface in real time.

That’s why so many businesses turn to custom-built solutions. But as a developer, I kept asking myself:

Which frameworks are actually good for booking-system admin panels?
What do I do if a standard CRUD generator can’t handle the business logic?
How do I build a custom UI without breaking system compatibility?
And most importantly: how do I reduce dev time without sacrificing flexibility?

Why I Built Admiral Instead of Using Standard CRUD Generators

Like most devs, I started out with off-the-shelf CRUD generators. The “ready-to-go in 10 minutes” promise is tempting. But every time, I hit the same wall: they were too rigid. Their structures were locked down, and whenever I tried to implement custom business logic, it felt like fighting the framework instead of working with it.

That frustration is exactly what pushed me to build Admiral — a framework we now use in over 70% of our projects. It’s open source, and you can check it out here: https://github.com/dev-family/admiral.

What makes Admiral different?

I can build workflows that go way beyond standard CRUD logic.
I can spin up interactive dashboards with charts, metrics, and widgets that are actually useful to the client.

Admiral doesn’t force the business to adapt to the framework. It adapts to the business.

How It Works Under the Hood

Instead of generating static files with rigid templates, Admiral gives me an extensible architecture with a flexible routing system and modular components. This means I can inject custom UI and logic wherever I need.

The result? A powerful toolset that doesn’t box me in.

Let me walk you through how I used Admiral to customize CRUD for one of my recent projects — a chain of spa salons.

Their admins needed two things:

Create and manage bookings.
Monitor staff workload via a calendar.

Here’s how I built it.

Managing Bookings Page

I started by building a custom page for creating and editing bookings. I used a mix of my own components and Admiral’s built-in ones to keep everything consistent.

import React, { useCallback } from 'react'
import { Page, Form, Notification } from '@devfamily/admiral'
import { RecordSection, ClientSection, DiscountSection, PaymentSection } from './components'
import api from './api'

export enum RecordPageType {
    CREATE = 'create',
    EDIT = 'edit',
}

const RecordPage = ({ type }: { type: RecordPageType }) => {
    // Function to get default data if this is an edit page
    const fetchInitialData = useCallback(async () => {
        if (type === RecordPageType.EDIT) {
            let data = {}
            try {
                // Connect API request to get record data
            } catch (err) {
                // Displaying an error notification
                Notification({
                    message: `Error getting record: ${err?.message}`,
                    type: 'error',
                })
            }

            return Promise.resolve({
                data, 
                values: {},
            })
        } else {
            // Return empty data for the new record
            return Promise.resolve({
                data: {},  // Сan use default data
                values: {},
            })
        }
    }, [type, idRecord])

    // Function for submitting form data
    const onSubmit = useCallback(async (values) => {
        // Connect API request to create or edit record
    }, [])

    return (
        <Page title={type === RecordPageType.CREATE ? 'Add record' : `Edit record`}>
            <Form submitData={onSubmit} fetchInitialData={fetchInitialData}>
                {/* Include custom form sections as separate components */}
                <RecordSection />
                <ClientSection />
                <DiscountSection />
                <PaymentSection />
            </Form>
        </Page>
    )
}

export default RecordPage

Once that was done, I wired it into Admiral’s routing system with create.tsx, [id].tsx, and index.tsx.

// create.tsx
import React from 'react'
import RecordPage, { RecordPageType } from '../RecordPage'

const CreateRecordPage = () => {
    return <RecordPage type={RecordPageType.CREATE} />
}

export default CreateRecordPage

// [id].tsx
import React from 'react'
import RecordPage, { RecordPageType } from '../RecordPage'

const EditRecordPage = () => {
    return <RecordPage type={RecordPageType.EDIT} />
}

export default EditRecordPage

// index.tsx
import { CRUD } from '@/src/crud/records'
export default CRUD.IndexPage

With just that, I had a CRUD interface with a table of records plus custom create/edit pages.

Creating a Booking Calendar

Of course, a CRUD table alone wasn’t enough for the client. They needed a calendar view where admins could track workloads, open slots, and rescheduled bookings.

In Admiral, I just created another custom page, same as with CRUD.

import React, { useEffect, useState } from 'react'
import { CalendarHeader, CalendarTable, CalendarRecordNote } from './ui'
import { TCalendarHeaderData, TGroupedServices, TCalendarHeaderData } from './ts'
import styles from './CalendarPage.module.scss'

const CelendarPage = () => {
    const [isLoading, setIsLoading] = useState<boolean>(false)
    const [timeSlots, setTimeSlots] = useState<string[]>([])
const [services, setServices] = useState<Array<TGroupedServices> | null>(null)
    const [calendarHeaderData, setCalendarHeaderData] = useState<Array<TCalendarHeaderData>>([])
    const [comment, setComment] = useState<string>('')

    const fetchCalendarData = async ({date}: {date: string}) => {
// Connect API request to get data
}

   useEffect(() => {
            fetchCalendarData({
                date: urlState.date || new Date()
            })
    }, [])

    return <Page title="Main page">
            <div className={styles.calendar_page}>
                <CalendarHeader />
                <CalendarRecordNote comment={comment} />
                <CalendarTable
                    isLoading={isLoading}
                    timeSlots={timeSlots}
                    services={services}
                    calendarHeaderData={calendarHeaderData}
                />
            </div>
</Page>

}

export default EditRecordPage

This gave the admins a clean, visual way to see workloads and manage bookings.

Adding Pages to Navigation

Finally, I added the new pages to the project’s menu so they were easy to access.

import React from 'react'
import { Menu, MenuItemLink } from '@devfamily/admiral'
import { FiUsers, FiUser, FiSettings } from 'react-icons/fi'

const CustomMenu = () => {
    return (
        <Menu>
            <MenuItemLink icon="FiUsers" name="Main" to="/main" /> // navigate to custom page
            <MenuItemLink icon="FiUser" name="Records" to="/records" /> // navigate to page with custom components
   <MenuItemLink icon="FiSettings" name="Services" to="/services" />
   <MenuItemLink icon="FiSettings" name="Masters" to="/masters" />
        </Menu>
    )
}

export default CustomMenu

Wrapping Up

After using Admiral in multiple projects, here’s what I’ve learned firsthand:

It’s built for complex logic — where typical CRUD generators give up, Admiral keeps going.
It’s flexible without the overhead — I can plug in whatever I want: custom UI, business logic, calendars, widgets.
It’s fast to launch and easy to scale — start with a simple CRUD table, then keep layering on complexity.

For me, Admiral has saved dozens of dev hours and let me focus on delivering actual business value instead of hacking around framework limitations.

How I Built My Own Chat Instead of Using Jivo or LiveChat

Dmitriy Kasperovich — Sun, 24 Aug 2025 23:20:14 +0000

So I recently had a project where I needed a chat feature. My first thought was whether to just integrate an existing tool like Jivo or LiveChat, but I didn’t want to depend on third-party products for something that could be built directly into my admin panel.

In this post, I’ll go through how I built it: the architecture, the contexts for sockets and state, and the UI components that tied it all together.

Why Admiral?

Admiral is designed to be extensible. With file-based routing, hooks, and flexible components, it doesn’t lock you in—it gives you space to implement custom features. That’s exactly what I needed for chat: not just CRUD, but real-time messaging that still fit seamlessly into the panel.

Chat Architecture

Here’s how I structured things:

Core components

ChatPage – the main chat page
ChatSidebar – conversation list with previews
ChatPanel – renders the selected chat
MessageFeed – the thread of messages
MessageInput – the input with file upload

Context providers

SocketContext – manages WebSocket connections
ChatContext – manages dialogs and message state

Main Chat Page

With Admiral’s routing, setting up a new page was straightforward.

// pages/chat/index.tsx

import ChatPage from '@/src/crud/chat'
export default ChatPage

That was enough to make the page available at /chat.

The main implementation went into src/crud/chat/index.tsx:

// src/crud/chat/index.tsx

import React from 'react'

import { Card } from '@devfamily/admiral'
import { usePermissions, usePermissionsRedirect } from '@devfamily/admiral'
import { SocketProvider } from './contexts/SocketContext'
import { ChatProvider } from './contexts/ChatContext'
import ChatSidebar from './components/ChatSidebar'
import ChatPanel from './components/ChatPanel'
import styles from './Chat.module.css'

export default function ChatPage() {
  const { permissions, loaded, isAdmin } = usePermissions()
  const identityPermissions = permissions?.chat?.chat

  usePermissionsRedirect({ identityPermissions, isAdmin, loaded })

  return (
    <SocketProvider>
      <ChatProvider>
        <Card className={styles.page}>
          <PageTitle title="Corporate chat" />
          <div className={styles.chat}>
            <ChatSidebar />
            <ChatPanel />
          </div>
        </Card>
      </ChatProvider>
    </SocketProvider>
  )
}

Here I wrapped the page in SocketProvider and ChatProvider, and used Admiral’s hooks for permissions and redirects.

Managing WebSocket Connections with SocketContext

For real-time chat, I chose Centrifuge. I wanted all connection logic in one place, so I created SocketContext:

// src/crud/chat/SocketContext.tsx

import React from 'react'

import { Centrifuge } from 'centrifuge'
import { createContext, ReactNode, useContext, useEffect, useRef, useState } from 'react'
import { useGetIdentity } from '@devfamily/admiral'

const SocketContext = createContext(null)

export const SocketProvider = ({ children }: { children: ReactNode }) => {
    const { identity: user } = useGetIdentity()
    const [lastMessage, setLastMessage] = useState(null)
    const centrifugeRef = useRef(null)
    const subscribedRef = useRef(false)

    useEffect(() => {
        if (!user?.ws_token) return

        const WS_URL = import.meta.env.VITE_WS_URL
        if (!WS_URL) {
            console.error('❌ Missing VITE_WS_URL in env')
            return
        }

        const centrifuge = new Centrifuge(WS_URL, {
            token: user.ws_token, // Initializing the WebSocket connection with a token
        })

        centrifugeRef.current = centrifuge
        centrifugeRef.current.connect()

        // Subscribing to the chat channel
        const sub = centrifugeRef.current.newSubscription(`admin_chat`)

        sub.on('publication', function (ctx: any) {
               setLastMessage(ctx.data);
        }).subscribe()

        // Cleaning up on component unmount
        return () => {
            subscribedRef.current = false
            centrifuge.disconnect()
        }
    }, [user?.ws_token])

    return (
        <SocketContext.Provider value={{ lastMessage, centrifuge: centrifugeRef.current }}>
            {children}
        </SocketContext.Provider>
    )
}

export const useSocket = () => {
    const ctx = useContext(SocketContext)
    if (!ctx) throw new Error('useSocket must be used within SocketProvider')
    return ctx
}

This context handled connection setup, subscription, and cleanup. Other parts of the app just used useSocket().

Managing Chat State with ChatContext

Next, I needed to fetch dialogs, load messages, send new ones, and react to WebSocket updates. For that, I created ChatContext:

// src/crud/chat/ChatContext.tsx

import React, { useRef } from "react";

import {
  createContext,
  useContext,
  useEffect,
  useState,
  useRef,
  useCallback,
} from "react";
import { useSocket } from "./SocketContext";
import { useUrlState } from "@devfamily/admiral";
import api from "../api";

const ChatContext = createContext(null);

export const ChatProvider = ({ children }) => {
  const { lastMessage } = useSocket();
  const [dialogs, setDialogs] = useState([]);
  const [messages, setMessages] = useState([]);
  const [selectedDialog, setSelectedDialog] = useState(null);
  const [urlState] = useUrlState();
  const { client_id } = urlState;

  const fetchDialogs = useCallback(async () => {
    const res = await api.dialogs();
    setDialogs(res.data || []);
  }, []);

  const fetchMessages = useCallback(async (id) => {
    const res = await api.messages(id);
    setMessages(res.data || []);
  }, []);

  useEffect(() => {
    fetchMessages(client_id);
  }, [fetchMessages, client_id]);

  useEffect(() => {
    fetchDialogs();
  }, [fetchDialogs]);

  useEffect(() => {
    if (!lastMessage) return;

    fetchDialogs();

    setMessages((prev) => [...prev, lastMessage.data]);
  }, [lastMessage]);

  const sendMessage = useCallback(
    async (value, onSuccess, onError) => {
      try {
        const res = await api.send(value);
        if (res?.data) setMessages((prev) => [...prev, res.data]);
        fetchDialogs();
        onSuccess();
      } catch (err) {
        onError(err);
      }
    },
    [messages]
  );

  // Within this context, you can extend the logic to:
  // – Mark messages as read (api.read())
  // – Group messages by date, and more.

  return (
    <ChatContext.Provider
      value={{
        dialogs,
        messages: groupMessagesByDate(messages),
        selectedDialog,
        setSelectedDialog,
        sendMessage,
      }}
    >
      {children}
    </ChatContext.Provider>
  );
};

export const useChat = () => {
  const ctx = useContext(ChatContext);
  if (!ctx) throw new Error("useChat must be used within ChatProvider");
  return ctx;
};

This kept everything—fetching, storing, updating—in one place.

API Client Example

I added a small API client for requests:

// src/crud/chat/api.ts

import _ from '../../config/request'
import { apiUrl } from '@/src/config/api'

const api = {
    dialogs: () => _.get(`${apiUrl}/chat/dialogs`)(),
    messages: (id) => _.get(`${apiUrl}/chat/messages/${id}`)(),
    send: (data) => _.postFD(`${apiUrl}/chat/send`)({ data }),
    read: (data) => _.post(`${apiUrl}/chat/read`)({ data }),
}

export default api

UI Components: Sidebar + Panel + Input

Then I moved to the UI layer.

ChatSidebar

// src/crud/chat/components/ChatSidebar.tsx

import React from "react";

import styles from "./ChatSidebar.module.scss";
import ChatSidebarItem from "../ChatSidebarItem/ChatSidebarItem";
import { useChat } from "../../model/ChatContext";

function ChatSidebar({}) {
  const { dialogs } = useChat();

    if (!dialogs.length) {
    return (
      <div className={styles.empty}>
        <span>No active активных dialogs</span>
      </div>
    );
  }

  return <div className={styles.list}>
      {dialogs.map((item) => (
        <ChatSidebarItem key={item.id} data={item} />
      ))}
    </div>
}

export default ChatSidebar;

ChatSidebarItem

// src/crud/chat/components/ChatSidebarItem.tsx

import React from "react";

import { Badge } from '@devfamily/admiral'
import dayjs from "dayjs";
import { BsCheck2, BsCheck2All } from "react-icons/bs";
import styles from "./ChatSidebarItem.module.scss";

function ChatSidebarItem({ data }) {
  const { client_name, client_id, last_message, last_message_ } = data;

  const [urlState, setUrlState] = useUrlState();
  const { client_id } = urlState;

  const { setSelectedDialog } = useChat();

  const onSelectDialog = useCallback(() => {
    setUrlState({ client_id: client.id });
    setSelectedDialog(data);
  }, [order.id]);

  return (
    <div
      className={`${styles.item} ${isSelected ? styles.active : ""}`}
      onClick={onSelectDialog}
      role="button"
    >
      <div className={styles.avatar}>{client_name.charAt(0).toUpperCase()}</div>

      <div className={styles.content}>
        <div className={styles.header}>
          <span className={styles.name}>{client_name}</span>
          <span className={styles.time}>
            {dayjs(last_message_).format("HH:mm")}
            {message.is_read ? (
              <BsCheck2All size="16px" />
            ) : (
              <BsCheck2 size="16px" />
            )}
          </span>
        </div>
        <span className={styles.preview}>{last_message.text}</span>
        {unread_count > 0 && (
            <Badge>{unread_count}</Badge>
          )}
      </div>
    </div>
  );
}

export default ChatSidebarItem;

ChatPanel

// src/crud/chat/components/ChatPanel.tsx

import React from "react";

import { Card } from '@devfamily/admiral';
import { useChat } from "../../contexts/ChatContext";
import MessageFeed from "../MessageFeed";
import MessageInput from "../MessageInput";
import styles from "./ChatPanel.module.scss";

function ChatPanel() {
  const { selectedDialog } = useChat();

  if (!selectedDialog) {
    return (
      <Card className={styles.emptyPanel}>
        <div className={styles.emptyState}>
          <h3>Choose the dialog</h3>
          <p>Choose the dialog from the list to start conversation</p>
        </div>
      </Card>
    );
  }

  return (
    <div className={styles.panel}>
      <MessageFeed />
      <div className={styles.divider} />
      <MessageInput />
    </div>
  );
}

export default ChatPanel;

MessageFeed

// src/crud/chat/components/MessageFeed.tsx

import React, { useRef, useEffect } from "react";

import { BsCheck2, BsCheck2All } from "react-icons/bs";
import { useChat } from "../../contexts/ChatContext";
import MessageItem from "../MessageItem";
import styles from "./MessageFeed.module.scss";

function MessageFeed() {
  const { messages } = useChat();
  const scrollRef = useRef(null);

  useEffect(() => {
    scrollRef.current?.scrollIntoView({ behavior: "auto" });
  }, [messages]);

  return (
    <div ref={scrollRef} className={styles.feed}>
      {messages.map((group) => (
        <div key={group.date} className={styles.dateGroup}>
          <div className={styles.dateDivider}>
            <span>{group.date}</span>
          </div>
          {group.messages.map((msg) => (
            <div className={styles.message}>
              {msg.text && <p>{msg.text}</p>}
              {msg.image && (
                <img
                  src={msg.image}
                  alt=""
                  style={{ maxWidth: "200px", borderRadius: 4 }}
                />
              )}
              {msg.file && (
                <a href={msg.file} target="_blank" rel="noopener noreferrer">
                  Скачать файл
                </a>
              )}
              <div style={{ fontSize: "0.8rem", opacity: 0.6 }}>
                {dayjs(msg.created_at).format("HH:mm")}
                {msg.is_read ? <BsCheck2All /> : <BsCheck2 />}
              </div>
            </div>
          ))}
        </div>
      ))}
    </div>
  );
}

export default MessageFeed;

MessageInput

// src/crud/chat/components/MessageInput.tsx

import React from "react";

import {
  ChangeEventHandler,
  useCallback,
  useEffect,
  useRef,
  useState,
} from "react";

import { FiPaperclip } from "react-icons/fi";
import { RxPaperPlane } from "react-icons/rx";
import { Form, Button, useUrlState, Textarea } from "@devfamily/admiral";

import { useChat } from "../../model/ChatContext";

import styles from "./MessageInput.module.scss";

function MessageInput() {
  const { sendMessage } = useChat();
  const [urlState] = useUrlState();
  const { client_id } = urlState;
  const [values, setValues] = useState({});
  const textRef = useRef < HTMLTextAreaElement > null;

  useEffect(() => {
    setValues({});
    setErrors(null);
  }, [client_id]);

  const onSubmit = useCallback(
    async (e?: React.FormEvent<HTMLFormElement>) => {
      e?.preventDefault();
      const textIsEmpty = !values.text?.trim()?.length;

      sendMessage(
        {
          ...(values.image && { image: values.image }),
          ...(!textIsEmpty && { text: values.text }),
          client_id,
        },
        () => {
          setValues({ text: "" });
        },
        (err: any) => {
          if (err.errors) {
            setErrors(err.errors);
          }
        }
      );
    },
    [values, sendMessage, client_id]
  );

  const onUploadFile: ChangeEventHandler<HTMLInputElement> = useCallback(
    (e) => {
      const file = Array.from(e.target.files || [])[0];
      setValues((prev: any) => ({ ...prev, image: file }));
      e.target.value = "";
    },
    [values]
  );

  const onChange = useCallback((e) => {
    setValues((prev) => ({ ...prev, text: e.target.value }));
  }, []);

  const onKeyDown = useCallback((e: React.KeyboardEvent<HTMLTextAreaElement>) => {
    if ((e.code === "Enter" || e.code === "NumpadEnter") && !e.shiftKey) {
      onSubmit();
      e.preventDefault();
    }
  }, [onSubmit]);

  return (
    <form className={styles.form} onSubmit={onSubmit}>
      <label className={styles.upload}>
        <input
          type="file"
          onChange={onUploadFile}
          className={styles.visuallyHidden}
        />
        <FiPaperclip size="24px" />
      </label>
      <Textarea
        value={values.text ?? ""}
        onChange={onChange}
        rows={1}
        onKeyDown={onKeyDown}
        placeholder="Написать сообщение..."
        ref={textRef}
        className={styles.textarea}
      />
      <Button
        view="secondary"
        type="submit"
        disabled={!values.image && !values.text?.trim().length}
        className={styles.submitBtn}
      >
        <RxPaperPlane />
      </Button>
    </form>
  );
}

export default MessageInput;

Styling

I styled it using Admiral’s CSS variables to keep everything consistent:

.chat {
  border-radius: var(--radius-m);
  border: 2px solid var(--color-bg-border);
  background-color: var(--color-bg-default);
}

.message {
  padding: var(--space-m);
  border-radius: var(--radius-s);
  background-color: var(--color-bg-default);
}

Adding Notifications

I also added notifications for new messages when the user wasn’t viewing that chat:

import { useNotifications } from '@devfamily/admiral'

const ChatContext = () => {
  const { showNotification } = useNotifications()

  useEffect(() => {
    if (!lastMessage) return

    if (selectedDialog?.client_id !== lastMessage.client_id) {
      showNotification({
        title: 'New message',
        message: `${lastMessage.client_name}: ${lastMessage.text || 'Image'}`,
        type: 'info',
        duration: 5000
      })
    }
  }, [lastMessage, selectedDialog, showNotification])
}

Conclusion

And just like that, instead of using third-party tools, I built it directly into my Admiral-based admin panel. Admiral’s routing, contexts, hooks, and design system made it possible to build a real-time chat that felt native to the panel.

The result was a fully custom chat: real-time messaging, dialogs, file uploads, and notifications—all integrated and under my control.

Check it out and let me know what you think!

How I Built Local-First Apps with React Native + RxDB (and Why Your App Probably Needs This Too)

Dmitriy Kasperovich — Fri, 08 Aug 2025 14:10:43 +0000

You know that moment when you’re in the middle of nowhere, your 4G turns into “E”, and your mobile app decides to become a very expensive paperweight? Yeah. That’s exactly why I wrote this.

Picture a delivery driver staring at a loading spinner because the app can’t load their route without internet. Or a warehouse manager unable to pull the inventory list because the server’s down. That’s not “quirky behavior,” that’s lost time, lost money, and very angry users.

A bunch of our clients hit these connectivity potholes — remote job sites, offsite events, warehouse floors, logistics hubs. Basically, anywhere Wi-Fi goes to die. The fix? Local-first apps: process data locally, sync it when you can. Your users stay happy, and you don’t get midnight “the app’s broken” calls.

In this little adventure, I’ll show you how I built a local-first mobile app with React Native + RxDB. You’ll see:

How two-way sync actually works without melting your server.
How to handle “fun” situations like data conflicts.
What not to forget when designing one of these beasts.

Also — I’ll share one “last update wins” trick. Not always the right choice, but in our case… chef’s kiss.

The Stack (a.k.a. My Chosen Weapons)

For this build, I rolled with:

React Native — cross-platform magic: one codebase, iOS + Android.
react-native-nitro-sqlite — because local storage without SQLite is like pizza without cheese.
RxDB — offline-first, reactive DB that plays nice with sync.
NestJS + TypeORM + PostgreSQL — the backend dream team.

The end result: app works offline, syncs later, and survives dodgy connections without having a meltdown.

Step 1 — Local Storage via SQLite

First up, I needed a local database that RxDB could happily abuse. SQLite is the obvious choice, but I wrapped it with some extra powers — validation and encryption — because data integrity and privacy matter (and also because my future self will thank me).

//storage.ts
import {
  getRxStorageSQLiteTrial,
  getSQLiteBasicsQuickSQLite,
} from 'rxdb/plugins/storage-sqlite';
import { open } from 'react-native-nitro-sqlite';
import { wrappedValidateAjvStorage } from 'rxdb/plugins/validate-ajv';
import { wrappedKeyEncryptionCryptoJsStorage } from 'rxdb/plugins/encryption-crypto-js';
const sqliteBasics = getSQLiteBasicsQuickSQLite(open);
const storage = getRxStorageSQLiteTrial({ sqliteBasics });
const validatedStorage = wrappedValidateAjvStorage({ storage });
const encryptedStorage = wrappedKeyEncryptionCryptoJsStorage({
  storage: validatedStorage,
});
export { encryptedStorage };

Yes, that’s three layers of wrapping. Like an onion. Or an enterprise app with way too many middleware layers.

Step 2 — Creating the Database Instance

Next, I built a RxDatabaseManager singleton. Because if you think having multiple instances of your DB is a good idea… you probably also enjoy merge conflicts in production.

Here’s the class in all its glory:

//Instance.ts
import { addRxPlugin, createRxDatabase, RxDatabase, WithDeleted } from 'rxdb';
import { RxDBDevModePlugin } from 'rxdb/plugins/dev-mode';
import { replicateRxCollection } from 'rxdb/plugins/replication';
import NetInfo from '@react-native-community/netinfo';
import {
  CheckPointType,
  MyDatabaseCollections,
  ReplicateCollectionDto,
} from './types.ts';
import { encryptedStorage } from './storage.ts';
import { defaultConflictHandler } from './utills.ts';
import { usersApi, userSchema, UserType } from '../features/users';
import { RxDBMigrationSchemaPlugin } from 'rxdb/plugins/migration-schema';
import { RxDBQueryBuilderPlugin } from 'rxdb/plugins/query-builder';
import { RxDBUpdatePlugin } from 'rxdb/plugins/update';
// for support query.update method
addRxPlugin(RxDBUpdatePlugin);
// for support chained query methods
addRxPlugin(RxDBQueryBuilderPlugin);
// for enabling data migration
addRxPlugin(RxDBMigrationSchemaPlugin);
export class RxDatabaseManager {
  private static instance: RxDatabaseManager;
  private db: RxDatabase<MyDatabaseCollections> | null = null;
  private isOnline = false;
  private constructor() {}
  public static getInstance(): RxDatabaseManager {
    if (!RxDatabaseManager.instance) {
      RxDatabaseManager.instance = new RxDatabaseManager();
    }
    return RxDatabaseManager.instance;
  }
  public async init(): Promise<RxDatabase<MyDatabaseCollections>> {
    if (this.db) return this.db;
    if (__DEV__) {
      // needs to be added in dev mode
      addRxPlugin(RxDBDevModePlugin);
    }
    this.db = await createRxDatabase<MyDatabaseCollections>({
      name: 'myDb',
      storage: encryptedStorage,
      multiInstance: false, // No multi-instance support for React Native
      closeDuplicates: true, // Close duplicate database instances
    });
    await this.db.addCollections({
      users: {
        schema: userSchema,
        conflictHandler: defaultConflictHandler,
        migrationStrategies: {
          // 1: function (oldDoc: UserType) {},
        },
      },
    });
    this.setupConnectivityListener();
    return this.db;
  }
  public getDb(): RxDatabase<MyDatabaseCollections> {
    if (!this.db) {
      throw new Error('Database not initialized. Call init() first.');
    }
    return this.db;
  }
  private replicateCollection<T>(dto: ReplicateCollectionDto<T>) {
    const { collection, replicationId, api } = dto;
    const replicationState = replicateRxCollection<WithDeleted<T>, number>({
      collection: collection,
      replicationIdentifier: replicationId,
      pull: {
        async handler(checkpointOrNull: unknown, batchSize: number) {
          const typedCheckpoint = checkpointOrNull as CheckPointType;
          const updatedAt = typedCheckpoint ? typedCheckpoint.updatedAt : 0;
          const id = typedCheckpoint ? typedCheckpoint.id : '';
          const response = await api.pull({ updatedAt, id, batchSize });
          return {
            documents: response.data.documents,
            checkpoint: response.data.checkpoint,
          };
        },
        batchSize: 20,
      },
      push: {
        async handler(changeRows) {
          console.log('push');
          const response = await api.push({ changeRows });
          return response.data;
        },
      },
    });
    replicationState.active$.subscribe(v => {
      console.log('Replication active$:', v);
    });
    replicationState.canceled$.subscribe(v => {
      console.log('Replication canceled$:', v);
    });
    replicationState.error$.subscribe(async error => {
      console.error('Replication error$:', error);
    });
  }
  private async startReplication() {
    const db = this.getDb();
    this.replicateCollection<UserType>({
      collection: db.users,
      replicationId: '/users/sync',
      api: {
        push: usersApi.push,
        pull: usersApi.pull,
      },
    });
  }
  private setupConnectivityListener() {
    NetInfo.addEventListener(state => {
      const wasOffline = !this.isOnline;
      this.isOnline = Boolean(state.isConnected);
      if (this.isOnline && wasOffline) {
        this.onReconnected();
      }
    });
  }
  private async onReconnected() {
    this.startReplication();
  }
}

This little beast:

Sets up the DB.
Watches for internet like a clingy ex.
Syncs as soon as we’re back online.

And yes, it logs everything. Future me will be grateful when debugging next time.

Step 3 — Bootstrapping the DB When the App Starts

When the app launches, I spin up my RxDatabaseManager instance. No magic here — just the good ol’ useEffect doing its thing.

If something explodes during init, I log it. Because pretending errors don’t exist is how you get haunted apps.

//App.tsx

useEffect(() => {
  const init = async () => {
    const dbManager = RxDatabaseManager.getInstance();
    dbManager
      .init()
      .then(() => {
        setAppStatus('ready');
      })
      .catch((error) => {
        console.log('Error initializing database:', error);
        setAppStatus('error');
      });
  };
  init();
}, []);

Step 4 — Data Replication (a.k.a. Syncing Without Tears)

When the app goes from “offline cave mode” back online, onReconnected() fires. That kicks off data sync between the local DB and the server via replicateRxCollection.

Here’s the basic pull handler — RxDB sends a checkpoint (updatedAt, id) so the server knows where we left off. Because nobody wants to fetch the entire DB every time.

//instance.ts
async handler(checkpointOrNull: unknown, batchSize: number) {
  const typedCheckpoint = checkpointOrNull as CheckPointType;
  const updatedAt = typedCheckpoint ? typedCheckpoint.updatedAt : 0;
  const id = typedCheckpoint ? typedCheckpoint.id : '';
  const response = await api.pull({ updatedAt, id, batchSize });
  return {
    documents: response.data.documents,
    checkpoint: response.data.checkpoint,
  };
},

On the server, I query only the new/updated stuff since the last checkpoint. Because bandwidth is precious, and so is my patience.

//users.query-repository.ts

async pull(dto: PullUsersDto): Promise<UserViewDto[]> {
  const { id, updatedAt, batchSize } = dto;
  const users = await this.users
    .createQueryBuilder('user')
    .where('user.updatedAt > :updatedAt', { updatedAt })
    .orWhere('user.updatedAt = :updatedAt AND user.id > :id', {
      updatedAt,
      id,
    })
    .orderBy('user.updatedAt', 'ASC')
    .addOrderBy('user.id', 'ASC')
    .limit(batchSize)
    .getMany();
  return users.map(UserViewDto.mapToView);
}

And then the server sends back both the docs and a shiny new checkpoint:

//user.service.ts
async pull(dto: PullUsersDto) {
  const users = await this.usersRepository.pull(dto);
  const newCheckpoint =
    users.length === 0
      ? { id: dto.id, updatedAt: dto.updatedAt }
      : {
          id: users.at(-1)!.id,
          updatedAt: users.at(-1)!.updatedAt,
        };
  return {
    documents: users,
    checkpoint: newCheckpoint,
  };
}

Step 5 — Pushing Local Changes Back to the Server

RxDB also tracks what’s changed locally since the last sync and pushes it up. Think of it like Dropbox for your app’s data — without the random “conflicted copy” files (well… unless you handle conflicts badly).

//instance.ts
async handler(changeRows) {
  const response = await api.push({ changeRows });
  return response.data;
},

On the backend, I check each incoming change:

If there’s no conflict, it goes straight in.
If the server’s version is newer, I throw it into the conflicts pile.

//user.service.ts
async push(dto: PushUsersDto) {
  const changeRows = dto.changeRows;
  const existingUsers = await this.usersRepository.findByIds(
    changeRows.map((changeRow) => changeRow.newDocumentState.id),
  );
  const existingMap = new Map(existingUsers.map((user) => [user.id, user]));
  const toSave: UserViewDto[] = [];
  const conflicts: UserViewDto[] = [];
  for (const changeRow of changeRows) {
    const newDoc = changeRow.newDocumentState;
    const existing = existingMap.get(newDoc.id);
    const isConflict = existing && existing.updatedAt > newDoc?.updatedAt;
    if (isConflict) {
      conflicts.push(existing);
    } else {
      toSave.push(newDoc);
    }
    if (toSave.length > 0) {
      await this.usersRepository.save(toSave);
    }
  }
  return conflicts;
}

Step 6 — Conflict Resolution (The “Last Update Wins” Gambit)

Here’s where people usually overcomplicate things. Yes, you could build a NASA-grade merge strategy. Or… you could go with “last update wins” and call it a day.

It’s not always the right move, but in our case — simple, fast, good enough.

//utills.ts

export const defaultConflictHandler: RxConflictHandler<{
  updatedAt: number;
}> = {
  isEqual(a, b) {
    return a.updatedAt === b.updatedAt;
  },
  resolve({ assumedMasterState, realMasterState, newDocumentState }) {
    return Promise.resolve(realMasterState);
  },
};

Step 7 — Keeping the UI in Sync

After init, the app status flips to Ready, and we just… use it. No weird manual refresh buttons, no “tap to reload” nonsense.

//UsersScreen.tsx
export const UsersScreen = () => {
  const users = useUsersSelector({
    sort: [{ updatedAt: 'desc' }],
  });
  const { createUser, deleteUser, updateUser } = useUsersService();
  return (
    <View style={styles.container}>
      {users.map(user => (
        <Text key={user.id}>{user.name}</Text>
      ))}
      <Button title={'Create new user'} onPress={createUser} />
      <Button
        disabled={users.length === 0}
        title={'Update user'}
        onPress={() => updateUser(users[0].id)}
      />
      <Button
        disabled={users.length === 0}
        title={'Delete user'}
        onPress={() => deleteUser(users[0].id)}
      />
    </View>
  );
};

useUsersSelector subscribes to changes in the DB, so the UI updates itself. This is one of those “works like magic” moments that you shouldn’t think too hard about — just enjoy it.

//user.selector.tsx

export const useUsersSelector = (query?: MangoQuery<UserType>) => {
  const userModel = RxDatabaseManager.getInstance().getDb().users;
  const [users, setUsers] = useState<UserType[]>([]);
  useEffect(() => {
    const subscription = userModel.find(query).$.subscribe(result => {
      setUsers(result);
    });
    return () => subscription.unsubscribe();
  }, [userModel, query]);
  return users;
};

Final Thoughts

We’ve basically built an app that:

Works offline.
Syncs automatically.
Doesn’t care if your Wi-Fi is having an existential crisis.

We used this same setup for Sizl’s dark kitchen riders in Chicago, where connectivity is… let’s just say “urban adventure mode.” Riders can now finish orders, take proof-of-delivery photos, and mark deliveries complete without internet. The app syncs later — no drama.

Sure, real-world cases can get gnarlier — multiple devices updating the same record, related data deletions, massive datasets. But the pattern holds. You just need to extend it with smarter conflict resolution and a more flexible architecture.

Would I recommend going local-first? Absolutely — unless you enjoy user rage tickets that start with “I was offline and…”

Click the link in my bio for more info on this one & other projects!

To check out our open source admin panel on React see our Github.

Service Workers Suck (Unless You Use This)

Dmitriy Kasperovich — Thu, 07 Aug 2025 21:01:36 +0000

I usually build things that I'd actually want to use myself — and I love to share them with everyone who might need it. One of those tools is the shiny new package: next-pwa-pack. It lets you bolt on solid PWA support into your Next.js app in no time.

Why I Built This Thing

Sometimes clients ask us to "just add PWA support" — which is usually code for “lose two days of your life fiddling with service workers and wondering why stuff randomly breaks.” I tried existing packages. Most were bloated, over-engineered, or just didn’t play nice with the App Router in Next.js.

Also, there was always something missing — like support for server actions to control cache, integration with SSR, or even just the ability to plug it cleanly into App Router without needing a spirit guide.

So I’d end up hand-rolling service workers, configuring cache logic from scratch, debugging offline mode across tabs… and every code update meant manually nuking the cache. Plus, no update notifications for users. Fun.

What we needed was a dead-simple, batteries-included PWA solution. No deep dives into service worker specs. No yak shaving.

Building the Package

Step one: I listed every annoying thing I had to do each time someone asked for a PWA. The mission: make it so a developer could get from zero to working PWA with minimal ceremony.

Started with a basic service worker that:

Caches HTML pages with TTL
Caches static assets
Handles offline mode

Then I added a messaging system between the client and the service worker so we could control the cache programmatically. Wrote a couple scripts to auto-copy the required files (sw.js, manifest.json, offline.html) into your project on install.

Also auto-injected a server action called revalidatePWA so you can revalidate cached pages from the server — via server actions, API routes, or server components.

For SSR/Edge Middleware and App Router integration, I built a HOC called withPWA. Now you can plug in server-driven revalidation and cache updates even in gnarly routing setups.

Bonus headache: syncing cache across tabs in SPA-mode. That’s in too — via localStorage + storage events.

In the end, we got a package that just works out of the box. No black magic. No footguns.

Why Use `next-pwa-pack`?

Installing this package gives you:

Auto service worker registration — no need to DIY that boilerplate
Project-specific files auto-copied — tweak them however you want
Cache control utilities — update, nuke, or disable cache easily
Tab sync — keeps caches aligned across browser tabs
Offline mode — yes, your app works without internet
Dev tools — built-in debug panel for dev-mode
Server-side revalidation — works with server actions, API routes, and external systems

Grab it here: https://github.com/dev-family/next-pwa-pack

What Happens on Install

The following files are auto-copied into your public folder:

sw.js – service worker with all the logic you need
offline.html – fallback for when the user’s offline
manifest.json – your PWA config file

⚠️ Already got those filenames? We won’t overwrite them. You can copy manually using:

node node_modules/next-pwa-pack/scripts/copy-pwa-files.mjs
# or
npx next-pwa-pack/scripts/copy-pwa-files.mjs

Also, we auto-create (or update) a server action:

// app/actions.ts OR src/app/actions.ts
"use server";
export async function revalidatePWA(urls: string[]) {
  const baseUrl = process.env.NEXT_PUBLIC_HOST || "http://localhost:3000";
  const res = await fetch(`${baseUrl}/api/pwa/revalidate`, {
    method: "POST",
    headers: { "Content-Type": "application/json" },
    body: JSON.stringify({
      urls,
      secret: process.env.REVALIDATION_SECRET,
    }),
  });
  return res.json();
}

Didn’t get the file? Run:

node node_modules/next-pwa-pack/scripts/copy-pwa-server-actions.mjs

Configuring `manifest.json`

After install, tweak public/manifest.json for your project:

{
  "name": "My App",
  "short_name": "My App",
  "description": "Description of my app",
  "start_url": "/",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#000000",
  "icons": [
    {
      "src": "/icons/icon-192x192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "/icons/icon-512x512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

Put your icons into public/icons/ or update paths in the manifest.

Quick Start

Wrap your app in the PWAProvider. That’s it. It wires up the rest.

import { PWAProvider } from "next-pwa-pack";

export default function layout({ children }) {
  return <PWAProvider>{children}</PWAProvider>;
}

For cache revalidation on the server, wrap your middleware in the HOC:

// /middleware.ts
import { withPWA } from "next-pwa-pack/hoc/withPWA";

function originalMiddleware(request) {
  // your logic here
  return response;
}

export default withPWA(originalMiddleware, {
  revalidationSecret: process.env.REVALIDATION_SECRET!,
  sseEndpoint: "/api/pwa/cache-events",
  webhookPath: "/api/pwa/revalidate",
});

export const config = {
  matcher: ["/", "/(ru|en)/:path*", "/api/pwa/:path*"],
};

HOC Arguments:

originalMiddleware – your middleware (e.g., auth, i18n)
revalidationSecret – keeps strangers out of your revalidation route
sseEndpoint – server-sent events endpoint (change it if needed)
webhookPath – POST endpoint to trigger cache revalidation manually

Now you can call revalidatePWA from anywhere — server actions, server components, API routes. The rest is handled for you.

Need a PWA app built? Hit us up.

What’s Inside `PWAProvider`

This is where the magic happens. Here’s what it wires up:

`RegisterSW`

Auto-registers your service worker. Checks support, registers /sw.js, logs errors if something explodes.

`CacheCurrentPage`

Intercepts navigation (SPA included) and sends the HTML to the service worker for caching. Supports offline mode and faster reloads.

`SWRevalidateListener`

Listens for localStorage events and syncs cache across tabs. When one tab updates, others follow.

`SSERevalidateListener`

Listens for server-sent events at /api/pwa/cache-events. When the server says “revalidate,” the client updates the cache. Crucial for SSR + server action integration.

`DevPWAStatus`

Built-in dev panel. Enable with devMode:

<PWAProvider devMode>{children}</PWAProvider>

Gives you:

Online/offline status
Update notifications
Buttons to:
- Clear cache
- Reload SW
- Update page cache
- Unregister SW
- Toggle caching

What the Service Worker Does

TL;DR: It’s a background script that manages cache, network, and updates.

HTML Caching

TTL defaults to 10 minutes (change in /sw.js)
Auto-refreshes cache when TTL expires
Offline? Serves cached version

Want to use a custom SW path?

<PWAProvider swPath="/some-path/sw.js">{children}</PWAProvider>

Static Asset Caching

Caches CSS, JS, images forever
Improves load speed on repeat visits
Only works with GET requests (because security)

Message Handling

SW listens for 6 types of messages:

CACHE_CURRENT_HTML – cache current page
REVALIDATE_URL – force refresh a specific URL
DISABLE_CACHE / ENABLE_CACHE – toggle caching
SKIP_WAITING – activate new SW version
CLEAR_STATIC_CACHE – drop static/API cache (useful after SSE updates)

Offline Mode

Shows offline.html when offline and no cache available
Tries to update content once you're back online

The `withPWA` HOC

Adds server-side revalidation support via SSR or middleware. Server can broadcast cache updates via SSE, which the client listens for and responds to.

export default withPWA(originalMiddleware, {
  revalidationSecret: process.env.REVALIDATION_SECRET!,
  sseEndpoint: "/api/pwa/cache-events",
  webhookPath: "/api/pwa/revalidate",
});

Usage Examples

Update Cache After Posting Data

import { updateSWCache } from "next-pwa-pack";

const handleCreatePost = async (data) => {
  await createPost(data);
  updateSWCache(["/blog", "/dashboard"]);
};

Revalidate on Server

import { revalidatePWA } from "../actions";

await createPost(data);
await revalidatePWA(["/my-page"]);

Clear Cache on Logout

import { clearAllCache } from "next-pwa-pack";

const handleLogout = async () => {
  await logout();
  await clearAllCache();
  router.push("/login");
};

All Exported Client Actions

import {
  clearAllCache,
  reloadServiceWorker,
  updatePageCache,
  unregisterServiceWorkerAndClearCache,
  updateSWCache,
  disablePWACache,
  enablePWACache,
  clearStaticCache,
  usePWAStatus,
} from "next-pwa-pack";

await clearAllCache();
await reloadServiceWorker();
await updatePageCache("/about");
await unregisterServiceWorkerAndClearCache();
await clearStaticCache();
updateSWCache(["/page1", "/page2"]);
disablePWACache();
enablePWACache();

const { online, hasUpdate, swInstalled, update } = usePWAStatus();

External Revalidation API Route

Sometimes you want to nuke cache from outside — like after a CMS update. Create an API route:

// app/api/webhook/revalidate/route.ts
...

Then hit it like this:

POST https://your-app/api/webhook/revalidate

body:
{
  "tags": ["faq"],
  "secret": "1234567890",
  "urls": ["/ru/question-answer"]
}

You’ll get a nice JSON with success stats.

Debugging Tips

Cache Verification

Open DevTools → Application → Service Workers
Check registration
Look in Cache Storage → html-cache-v2

Test Offline Mode

Enable devMode
Kill your internet (DevTools → Network → Offline)
Refresh page — you should see offline.html

Logs

Look out for these:

[PWA] Service Worker registered
[SW] Cached: /about
[SW] Revalidated and updated cache for: /blog

Limitations and Gotchas

Security

HTTPS only in prod
Only GET requests are cached
Sensitive data = keep it out of cache

Performance

Doesn’t slow things down
Speeds up repeat visits

Config Stuff

TTL is hardcoded in sw.js
Exclude URLs via CACHE_EXCLUDE
You’ll need to hand-edit manifest.json

`PWAProvider` Props

export default function PWAProvider({
  children,
  swPath,
  devMode = false,
  serverRevalidation = { enabled: true, sseEndpoint: "/api/pwa/cache-events" },
}: PWAProviderProps) {

Final Word

next-pwa-pack is a fast, zero-hassle way to turn your Next.js app into a proper PWA. It takes care of all the annoying stuff and gives you clean APIs to control your service worker and cache.

Coming soon:

TTL config via a proper config file
Push notifications
Smarter URL-based cache rules
Cache performance metrics

Built for Next.js 15, but should work fine with App Router in v13+.

Questions? Bugs? Weird use cases? Ping me!

Initializing Laravel and Admiral: Auth Setup Without Losing Your Will to Code

Dmitriy Kasperovich — Thu, 07 Aug 2025 20:50:04 +0000

Here’s a story you’ve probably lived: you spin up another Laravel admin panel, and what do you end up doing for the tenth time this month? That’s right — handcrafting authentication, fiddling with routing, wiring up yet another set of environment files like it’s 2015. Congrats, you’ve once again mastered the dark art of copying boilerplate.

And worst of all? It’s the frontend-backend integration hell that gets you — gluing things together, debugging invisible CORS errors, manually setting up your auth flow... again. Your business logic? Sitting in the corner. Crying.

That’s why we built Admiral – an open-source admin framework that says, “Hey, maybe you shouldn’t have to rebuild the same scaffolding for the hundredth time.” It standardizes what needs to be standardized, plugs straight into Laravel, and gives you the gift of skipping the boring parts.

Here’s the repo if you want to poke around:
👉 https://github.com/dev-family/admiral

In this post, I’ll walk you through bootstrapping Laravel + Admiral from scratch with proper authentication using Laravel Sanctum. No fluff. No marketing. Just real dev-to-dev setup until you’re past the yak shaving and into shipping features.

Installing Laravel

Let’s start with the basics. Create a new directory for our playground:

mkdir admiral-laravel-init && cd admiral-laravel-init

Install Laravel globally like a civilized person:

composer global require laravel/installer

Then create the backend project:

laravel new backend

We’re going to roll with SQLite here for simplicity. It’s one file, it works, and it won’t make you cry during local dev.

Now go into your backend directory and fire up the server:

cd backend && composer run dev

Laravel should be screaming its URL at you — usually something like:

APP_URL: http://localhost:8000

Open it in your browser. If you see the Laravel welcome page, you're alive and on the right track.

Installing Admiral

Time to bring Admiral on deck:

npx create-admiral-app@latest

When it asks, choose the option to install without backend setup. We already have Laravel running our backend show.

Name your frontend directory admin when prompted.

Then jump in and install dependencies like so:

cd admin && npm i

Hook Admiral up with the backend by editing your .env file:

VITE_API_URL=http://localhost:8000/admin

Now build and run the frontend:

npm run build && npm run dev

Your terminal should now say something like:

Local: http://localhost:3000/

Visit that in your browser and — surprise — you're staring at the login page. It does nothing yet, but it looks official, which is half the battle.

Authentication: AKA The Real Work

Now that Laravel and Admiral are up and pretending to like each other, let’s actually wire up the login flow.

We're using Laravel Sanctum, because it plays nice with SPAs and doesn't make you jump through OAuth hoops.

First, install Sanctum’s API features:

php artisan install:api

Now, open up config/auth.php and register a shiny new guard for the admin side of things:

'guards' => [
    'web' => [
        'driver' => 'session',
        'provider' => 'users',
    ],
    'admin' => [
        'driver' => 'sanctum',
        'provider' => 'users',
    ],
],

Oh, and don’t forget to toss HasApiTokens into your User model. It’s Sanctum’s secret sauce.

use HasFactory, Notifiable, HasApiTokens;

The Controller

Now, let’s get a real controller going. Here’s AuthController.php — our bouncer at the admin club:

// [code unchanged]

The Request

We’ll also need a request class that doesn’t let people submit empty forms and still hope for a login:

// [code unchanged]

The Resource

The AuthUserResource.php class makes sure we only send what’s needed to the frontend. No sensitive fields, no surprises.

// [code unchanged]

The Service Layer

Now the actual login logic. We like to keep our services tidy — services/admin/auth is a solid convention. Not required, just smart.

First up:

`AuthService.php`

// [code unchanged]

Then the trait for login attempt limiting. Because if someone’s slamming your login route, they probably shouldn’t be.

`LimitLoginAttempts.php`

// [code unchanged]

Routing All This

Create a new route file: routes/admin.php.

Here’s how we expose our login and protect our identity endpoints:

// [code unchanged]

Now wire it into bootstrap/app.php. Laravel 12 makes routing modular, and this is where you plug into that pipeline:

// [code unchanged]

Seeding a Test User

No auth setup is complete without a dummy user to break it with. In database/seeders/DatabaseSeeder.php, add:

User::factory()->create([
    'name' => 'Test User',
    'email' => 'test@example.com',
    'password' => '12345678',
]);

Then seed it:

php artisan db:seed

And restart the server:

composer run dev

Now hit your login form with those credentials and see what happens.

Red error block at the bottom? That’s good. That’s progress. That’s the frontend yelling about a failed login. Means the wiring’s working.

CORS throwing a tantrum? Laravel's got an old-school fix for that:

php artisan config:publish cors

Then open up config/cors.php and make sure your paths include:

'paths' => ['api/*', 'sanctum/csrf-cookie', 'admin/*'],

Now try again. If all is well, you’re in the admin panel. No more excuses. Time to build.

Where We’re At

You’ve just wired up Laravel + Admiral with full authentication using Sanctum. You’ve got proper guards, login throttling, token-based auth, and a clean frontend that talks to your backend like it means it.

Next stop? CRUD. But we’ll save that beast for another day.

If you hit a weird edge case during setup, drop us a line. We’ve probably hit it too — and we’re just as allergic to config hell as you are.

Automating CRUD Page Generation Using .cursor/rules and Our Own Open Source Library

Dmitriy Kasperovich — Fri, 11 Jul 2025 12:33:45 +0000

How We Automated CRUD Admin Panels with AI + .cursor/rules + Our Open Source Framework

Tired of setting up the same CRUD logic again and again? We were too — so we taught AI to do it for us.

👇Here's how it works.

The problem

Creating admin panels is repetitive:

same table structure
same hooks
same form fields.

Even with reusable components, mistakes still happen — wrong props, inconsistent naming, etc.

The solution

We built Admiral, our open source React-based framework for admin panels.

Then we added a .cursor/rules folder with Markdown-based rules for Cursor AI.

Now, AI knows:

how a CRUD page should be structured;
which components and hooks to use;
how to name things;
where to place files;
and how to fix TypeScript + lint errors right after generating.

Just trigger @crud-page in Cursor, fill in 7 simple fields — and get a ready-to-use CRUD page in seconds.

Example directory structure:

admin/
├── src/
│ └── crud/
│ └─── [resource]/
│ ├──── index.tsx # File with CRUD-page config
│ ├──── types.ts # Typescript
│ └────components/ # In case you need to use custom components
└── config/
└─── menu.tsx # A file describing how the navigation menu should look like


└── pages/ Routing
└─── [resource]/
├──── index.tsx # A page with a table
├──── create.tsx # A page with a c
└──── [id].tsx # A page with an edit form

The impact

Dozens of dev hours saved
Zero boilerplate hand-coding
Fewer errors
Clean, consistent code

We're actively using it in real projects and constantly expanding the ruleset.

🔗 Check the repo
🧠 Read the full walkthrough on our blog
💬 Got feedback or ideas for more rules? We'd love to hear them.

How I Hacked Together a Fully Functional Settings Page in Under 20 Minutes

Dmitriy Kasperovich — Mon, 07 Jul 2025 14:09:56 +0000

Sometimes, you just want a page that isn’t tied to some classic CRUD table. No list, no sorting, no pagination. Just a form. Like… app-wide settings, or something stupidly custom like “set default currency and minimum app version.”
So we built this in Admiral. Turns out, it’s actually dead simple to spin up a custom settings page, the same way you’d define any CRUD screen, just without the CRUD.
Here’s how we did it.
We’ll start by adding a new menu item — for example, Settings.

Step 1: Add It to the Menu

First, wire up a new menu item. Nothing fancy.

$menu->addItem(MenuItem::make(MenuKey::SETTINGS, 'Settings', 'FiSettings', '/settings'));

Now when you click that sucker, we’ll route to /settings.

Step 2: Build the Page Skeleton

Create a new folder: components/Settings/Settings.tsx.

Inside it, scaffold your form page like this:

import React, {useCallback} from 'react'
import {Form, Page} from '@devfamily/admiral'
import api from '../../config/api'


const settingsUri = 'settings'


export default function Settings() {
   const fetchInitialData = useCallback(() => {
       return api.get(settingsUri)
   }, [])


   const _onSubmit = useCallback(async (values) => {
       return api.post(settingsUri, values)
   }, [])


   return (
       <Page title="Settings">
           <Form submitData={_onSubmit} fetchInitialData={fetchInitialData}>
               // Here will be our inputs

               <Form.Footer>
                   <Form.Submit>Save</Form.Submit>
               </Form.Footer>
           </Form>
       </Page>
   )
}

Step 3: Register the Page

Let’s take a look at what our component returns. It renders a Page component along with a Form component from the devfamily/admiral package.

Nothing wild here — Admiral’s

takes care of all the loading/saving boilerplate. You just plug in the fetchInitialData and submitData callbacks, and it knows what to do.
Before we check how the page looks in the browser, let’s register it.
Navigate to the Pages directory and create a new settings folder with an index.tsx file inside.
In that file, we’ll define the following, so the router knows where to find this thing:

import Settings from '@/src/components/Settings/Settings'

export default Settings

Put this in /pages/settings/index.tsx or wherever your pages live.
Open the browser — boom, empty settings page. Let’s add some real fields.

Step 4: Add Form Inputs

Say we want two settings:
A minimum app version (min_version)

A default currency (default_currency) — which we’ll fetch from the server

Here’s the updated component:

import React, {useCallback} from 'react'
import {Form, Page, SelectInput, TextInput} from '@devfamily/admiral'
import api from '../../config/api'


const settingsUri = 'settings'


export default function Settings() {
   const fetchInitialData = useCallback(() => {
       return api.get(settingsUri)
   }, [])


   const _onSubmit = useCallback(async (values) => {
       return api.post(settingsUri, values)
   }, [])


   return (
       <Page title="Settings">
           <Form submitData={_onSubmit} fetchInitialData={fetchInitialData}>


               <TextInput name='min_version' label='Minimum App Version'/>


               <SelectInput name='default_currency' label='Default currency'/>


               <Form.Footer>
                   <Form.Submit>Save</Form.Submit>
               </Form.Footer>
           </Form>
       </Page>
   )
}

The currency options come from the backend, and the form auto-populates thanks to fetchInitialData. You don’t even have to think about state management. It just works.

Step 5: Add the API Wrapper

Admiral needs an api.get and api.post to fetch and save the form. Here’s what that looks like in src/config/api.ts:

import {GetFormDataResult, UpdateResult} from '@devfamily/admiral'
import _ from './request'
import {Any} from '@react-spring/types'


const apiUrl = import.meta.env.VITE_API_URL || '/api'


type apiType = {
   get: (uri: string) => Promise<GetFormDataResult>
   post: (uri: string, data: Any) => Promise<UpdateResult>
}


const api: apiType = {
   get: (uri) => {
       const url = `${apiUrl}/${uri}`
       return _.get(url)({})
   },
   post: (uri, data) => {
       const url = `${apiUrl}/${uri}`
       return _.post(url)({ data })
   },
}


export default api

Here, we defined two methods for sending requests to the server. Each method appends the passed uri (in this case, settings) to the base server URL specified in the environment variables.
It’s a tiny wrapper around your actual HTTP client (probably Axios). VITE_API_URL is where the admin API lives — by default, that’s http://localhost:802/admin.
Now we can move on to defining the routing and controller logic.

Step 6: Backend Time — Store Settings in the DB
You need a place to save this stuff. Here’s the migration:

<?php


use Illuminate\Database\Migrations\Migration;
use Illuminate\Database\Schema\Blueprint;
use Illuminate\Support\Facades\DB;
use Illuminate\Support\Facades\Schema;


return new class extends Migration
{
   /**
    * Run the migrations.
    */
   public function up(): void
   {
       Schema::create('settings', function (Blueprint $table) {
           $table->string('key')->unique();
           $table->text('value')->nullable();
           $table->timestamps();
       });


       DB::table('settings')->insert([
           [
               'key' => 'min_version',
               'value' => '3.0.0',
           ],
           [
               'key' => 'default_currency',
               'value' => 'RUB',
           ],
       ]);
   }


   /**
    * Reverse the migrations.
    */
   public function down(): void
   {
       Schema::dropIfExists('settings');
   }
};

Yes, it’s a key-value store. Yes, it’s enough for most settings pages. Don’t overengineer.

Step 7: Make the Model and Controller

<?php


namespace App\Models;


use Illuminate\Database\Eloquent\Model;


class Setting extends Model
{
   protected $fillable = [
      'key',
      'value',
   ];
}

Next, let’s create the controller with two methods:
One for returning the current settings;
One for saving new settings values.

<?php


namespace App\Http\Controllers\Admin;


use App\Http\Controllers\Controller;
use App\Models\Setting;
use Illuminate\Http\JsonResponse;
use Illuminate\Http\Request;


class SettingsController extends Controller
{
   public function get(): JsonResponse
   {
       $settings = Setting::query()
           ->whereIn('key', ['min_version', 'default_currency'])
           ->get()
           ->keyBy('key');


       return response()->json([
           'data' => [
               'min_version' => $settings->get('min_version')->value,
               'default_currency' => $settings->get('default_currency')->value,
           ],
           'values' => [
               'default_currency' => [
                   [
                       'label' => 'Dollar',
                       'value' => 'USD',
                   ],
                   [
                       'label' => 'Euro',
                       'value' => 'EUR',
                   ],
                   [
                       'label' => 'Russian ruble',
                       'value' => 'RUB',
                   ],
               ],
           ]
       ]);
   }


   public function store(Request $request): JsonResponse
   {
       Setting::query()->where('key', 'min_version')->update(['value' => $request->input('min_version')]);
       Setting::query()->where('key', 'default_currency')->update(['value' => $request->input('default_currency')]);


       return response()->json();
   }
}

So yeah — data pre-fills your form. values is for dropdown options. That’s how Admiral expects it.

In the get() method, the current settings data is returned under the data key. The keys in this object must match the name attributes defined in the form inputs.

The values key is used to pass the necessary options for the SelectInput. In this case, we’ve defined three currency options.

Next, let’s register our routes.

Step 8: Route It
Add this to /routes/admin.php:

Route::prefix('settings')->as('settings.')->group(function () {
   Route::get('',[SettingsController::class,'get'])->name('get');
   Route::post('',[SettingsController::class,'store'])->name('store');
});

Now your settings form will load values on page load and submit them back on save.

Done. You’ve Got a Custom Page.

So yeah. That’s it. You can now throw any inputs in there — CheckboxInput, DatePickerInput, TextareaInput, you name it. Admiral handles validation, form state, loading states, and submit logic. You just wire up your fields and your backend.

Settings page? Done. No spreadsheets, no state hell, no React-hook-form madness.

When the “Save” button is clicked, the form data is sent to the server.

Want to see it in action? Here’s the demo:

dev-family / admiral

Admiral is a frontend framework for creating back office in React. It provides out-of-the-box components and tools that make developing an admin interface easy and fast.

Revolutionize Your Workflow with Admiral: A Powerful Solution for Tailored Admin Panels and Business Applications

🌐 Try Live Demo | 📖 Real-World Use Cases