DEV Community: Vu xfi

RestoApp v2.4 is here

Vu xfi — Fri, 22 May 2026 04:57:53 +0000

This release is heavily focused on one thing: rebuilding the admin experience.

Over the past months, most of our work went into creating a cleaner, faster, and much more flexible admin panel. We wanted the system to feel modern, responsive, and enjoyable to work with every day — especially for teams handling large amounts of orders, products, and operational tasks.

A huge part of this became possible thanks to — the open-source admin framework we actively participate in and contribute feedback to during real production usage. WebResto is not just using Adminizer; we help shape its direction through practical experience from restaurant and delivery projects.

We are also currently developing a dynamic admin module system that will allow expanding the panel on the fly — adding new functionality, workflows, and integrations without rebuilding the entire system. The goal is to turn the admin panel into a customizable operational workspace with a completely new experience for both developers and operators.

✨ New Admin Panel

The admin interface has been fully redesigned:

• Modern and cleaner UI
• New dashboard with customizable widgets
• Reworked catalog management interface
• Full compatibility with the current core and modules preserved

📦 Stock Manager & Inventory Control

New tools for managing stock and availability:

• Stock and stop-list editor
• Dish and category availability management
• Bulk actions and improved navigation

🧩 Experimental Order Kanban

Order management has been significantly improved:

• Visual Kanban board for orders
• Order Stack support
• Better filtering and statuses
• Improved order processing workflow

📜 Order Logs & Transparency

Every order action is now traceable:

• Full order history
• Error logging
• Notification delivery logs
• Transparent processing chain from start to finish

⚡ Simplified Installer

Deployment is now much easier:

• Installation reduced from ~12 steps to just 3
• More user-friendly setup process
• Docker support fully preserved

📱 Mobile App Support

Basic mobile application support has been added:

• iOS and Android apps tested and working
• Foundation prepared for deeper admin integration in v2.5

WebResto continues evolving as an open platform for restaurant websites, delivery systems, and mobile applications.

Adminizer 4.6

Vu xfi — Fri, 22 May 2026 04:39:31 +0000

https://github.com/adminization/adminizer
https://www.npmjs.com/package/adminizer/v/4.6.0
https://t.me/talks_adminizer

Five months of work. The release is about observability and automation — knowing what happens to your data, reacting to it, and plugging AI into the routine.

🕓 Change history (audit trail)

The headline feature. Every model now keeps a full log: who, when, what changed, from which value to which.

Under the hood — a pluggable history adapter: you can swap the storage to whatever fits (separate DB, S3, an external audit service).

How to use it

Incident investigation
“Why did order #4821 change status yesterday at 18:40?” — open the record's history, instantly see the user, timestamp, and field diff. No more grepping app logs by timestamp.
Manual rollback
Previous value of every field is right there — restore state without a DB backup and without downtime.
Team oversight
A unified change list across all models, filterable by user — a manager opens it and sees exactly what a specific operator did today.
Compliance
For healthcare, finance, government contracts — covers the baseline requirement that all data edits must be traceable.
Integration debugging
See what an incoming webhook actually changed, instead of “something changed somewhere”.

Included

Pagination
Sort by date
Filter by user
Filter by association fields
Separate permission for viewing history
HistoryDialogStack UI component
getModelFieldsHistory export for custom views

History opens right inside the record card — no navigation away.

🔔 Notifications (foundation)

The codebase now ships a base notifications model and the infrastructure around it.

System notifications are off by default (so production doesn’t get spammed), but everything needed for your own alerts is already there.

What you can do today

Business events
“New order from a VIP customer”, “SKU stock dropped below threshold”, “1★ review needs a response” — write a handler, drop a record into the notifications model, the operator sees it in the admin panel.
Tech alerts for the team
“Payment integration token expired”, “nightly cron didn’t run”, “import queue exceeded the limit” — without wiring up an external alerting tool.
Workflow reminders
“Order has been in packing status for over 24h” — a notification automatically lands with the responsible manager.
Pair it with history
Important edit → automatic notification to the owner.

This is the foundation for a full notification system in upcoming releases — for now it’s a clean primitive for your own alerting logic.

🤖 AI agent (base layer)

AbstractAiModelService is now exported — a provider-neutral abstraction for any LLM.

The OpenAI integration was polished, switched to gpt-5-nano (faster and cheaper), and execution debug logs were expanded.

Use cases

Your own provider
Anthropic, a local LLM, a corporate AI gateway — implement the abstract service, register it, everything else works transparently.
Field autofill
From a short product description the agent generates SEO title, meta description, and tags.
Summarization
A long customer message → one-sentence summary in the card + suggested ticket category.
Classification & routing
Incoming lead → segment detection → automatic assignment to a manager.
Auditable actions
Debug logs show exactly what the agent sees and what decision it makes — critical when an agent operates on production data.

gpt-5-nano as the default makes typical agent runs several times cheaper than larger models — this is no longer “AI for the demo”, it’s viable for everyday work.

Everything else, in brief

Configurable dashboard widgets (defaultWidgets)
Info widget now supports links
Password visibility toggle on login
Redirect back to the original URL after sign-in
Dock improvements
versionText
GitHub link
Main-site link
displayName in model config
Smart redirect for single-record catalogs
Stabilization of Media Manager, Handsontable, JSONEditor
adminizer-jwt fixes
createdAt / updatedAt typing
CI: single npm publish workflow with branch-specific versioning
Translation updates

RestoApp: Why We Built an Open-Source Food Delivery Platform

Vu xfi — Sat, 09 Aug 2025 08:35:30 +0000

From WordPress to Node.js

When we first started building food delivery websites, we relied on tried-and-true tools — WordPress and WooCommerce.
For one of our clients, we launched a fully functional delivery site on this stack, and at first glance, it worked. But under the hood, it was almost entirely rewritten: too many modifications, a messy structure, and major maintenance headaches.

Technologies like PHP were no longer inspiring — we wanted something modern, modular, and flexible. That’s when we decided to switch to Node.js to create solutions that meet today’s web development standards.

At the time, we chose Sails.js as the framework — it was simple and easy to understand, allowing us to quickly build an MVP. Yes, it’s aging now and we’re considering migrating to a newer stack, but back then it was the optimal choice.

Why Food Delivery is Not Just E-commerce

Food delivery is not just an “online store with a cart.” It works differently:

The website often serves as an external storefront, while business processes and logistics live inside ERP systems (iiko, r-Keeper, Poster, Loyverse, or any other).
For an enterprise-grade solution, synchronization with these systems is critical — but the site must also work autonomously, without external dependencies.
Unlike retail, speed is critical: real-time order processing, live menu updates, delivery zones, and instant delivery cost calculation.

Our goal was to create a standalone, enterprise-level delivery site that:

Works equally well for a small café or a nationwide chain.
Can easily integrate with any ERP.
Functions as a fully autonomous system, processing orders without third-party services.

Why We Chose Open Source

Today, our clients range from single restaurants to large chains and franchises. We’ve learned that traditional subscription or “percentage of sales” models often don’t work:

For large companies, they create unpredictable costs and vendor lock-in.
Medium-sized businesses often seek lifetime licenses for closed products.
For long-term flexibility, Open Source is increasingly the preferred choice.

We went fully open-source for several reasons:

Transparency — anyone can review the code, check the architecture, and ensure its reliability.
Flexibility — integrate with any service or make custom changes without waiting for vendor updates.
Community — build a network of developers and business owners around the platform.
Scalability — use RestoApp not only for delivery websites but also to create aggregator-level platforms.

For us, Open Source is not just a philosophy. It’s a strategic decision that gives businesses control and independence, while letting us grow the platform together with the community.

Technology Stack

RestoApp is built on modern, high-performance tools:

Node.js — fast, scalable server-side runtime.
Sails.js — straightforward, easy-to-learn framework for APIs and business logic.
PostgreSQL — reliable relational database.
Docker — deploy in minutes anywhere: locally, on a server, or in the cloud.

Installing RestoApp

We’ve made installation as simple as possible.

Quick Start

Run RestoApp in Docker with one command:

docker run --name restoapp -p 8080:8080 webresto/restoapp:latest

Once the container starts, open your browser and go to:
http://localhost:8080

What’s Next

RestoApp is already ready to use as a complete food delivery solution, but we’re moving forward:

Integration support for any ERP
Extended modules for loyalty programs and promotions
Capability to run delivery aggregators on top of the platform

In the next article, we’ll show you how to connect a restaurant management system and automate menu updates.

RestoApp Links

How to Build a Realtime-Extensible Node.js SPA adminpanel

Vu xfi — Thu, 19 Jun 2025 11:32:46 +0000

Introduction

A quick look at our journey from classic templating engines to a dynamically extensible UI with Inertia.js.

Over the past five years, we’ve been searching for a convenient way to build the interface for our admin panel—something easy to update, expand, and scale. We started with Jade, then moved to EJS. Everything seemed fine. Later, we began removing jQuery from the project and switched to Vue. Vue had many strengths, but it turned out to be suboptimal for extensibility and scalability: each new component had to be bundled, and support for third-party libraries was often lacking.

For our admin framework (Adminizer), one key requirement is extensibility without restarting the Node.js process—in other words, realtime extensibility. We need to allow developers to create custom controls for model fields via an internal API. Although Adminizer provides all the essential UI controls out of the box, sometimes more is needed.

For example, in earlier versions of the admin panel, you could inject any component (e.g., JsonEditor) using a <head><script> tag and mount it via EJS to any database field requiring it. But how can we replicate this behavior in a SPA—without rebuilding or restarting?

How We Came to the Idea of Dynamic Bundling

Why we abandoned full rebundling and turned to dynamic component loading.

One of our developers raised a fundamental question: why bundle everything upfront? A SPA doesn’t need everything in one file, and modern tooling allows for dynamic component loading. So why not load the components we need—on demand, as independent modules?

That idea clicked. We envisioned an admin panel where each module is a separate UI component that gets injected into the system on the fly, without any recompilation—just via HTTP requests.

This led us to the concept of a modular SPA, and the technology that enabled it was Inertia.js. While this approach is widely used in Laravel/PHP, we had to make some adjustments for it to work well with our Node.js-based framework.

Why Inertia.js Was the Perfect Fit

Explaining how Inertia.js stands out from other frameworks.

Inertia is designed to work with components. When it needs to render a page, it gets the component name from the server response and uses a manifest to locate the appropriate file. All we had to do was write a wrapper component that dynamically imports the path passed through props.

Inertia acts as a bridge between the server and the SPA: on the backend, we specify which component to render, and Inertia takes care of loading and displaying it. The best part? That component doesn’t even need to exist at boot time—it can be created later and used immediately, without any need to rebuild the frontend.

The result? We can display anything we want on the page. Since React is globally available via the window context, the entire admin system becomes controllable as a live SPA. In theory, it could even be wrapped in Cordova to deliver a mobile app version (though we haven’t tested this yet—that’s for another article).

How the New Admin Architecture Works

Describing the practical implementation of dynamic extensibility.

Our new admin panel behaves like a modular SPA framework. Vite loads React globally via window. When initializing a controller, we specify which component to load and from where—and if it exists, it gets rendered immediately. Most components live in individual modules, often inside node_modules, and they require no rebundling.

Inertia handles routing and delivery. It “understands” what needs to be rendered, even for routes we didn’t explicitly configure. It parses HTML and embedded JSON metadata, loads only what’s necessary, and even keeps a request log for caching and rollback.

Why This Matters: Real-World Use Cases

Why we needed this flexibility—and what it enables.

Modules can now not only extend the UI but also inject custom fields, interactive controls, or even entire standalone pages. For example, if a module needs a special editing interface, it simply defines it—and it just works. All of this happens without touching the main admin codebase and without triggering a rebuild.

We believe this architecture is close to ideal for an admin panel, where modularity and flexibility are critical.

Conclusion: Where We Are Now

What’s done and what comes next.

We now have a fully working version 4 of our admin panel, built with this modular Inertia.js approach. It’s already running in production. We’re currently polishing the last parts and preparing documentation to share this solution with the community.

Hopefully, it’ll help others looking to build a flexible, scalable, and truly extensible admin panel—without the pain of constant rebuilds or server restarts.

Source code: https://github.com/adminization/adminizer