DEV Community: Vu xfi

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