FoodBasket / MISE

Centralized Discovery, Brand-level Identity

Links

• Documentation
• Main Page

Overview

MISE is a specialized B2B backend and frontend suite designed for the restaurant industry. Built as a direct competitor and a direct opposite of table-littered POS systems, MISE treats relational restaurant data as a multi-axis stream, focusing on spatial UI consistency and forgivefulness for users.

By the way, MISE comes for mise en place in French, or just "store" if you fancy the Japanese meaning more. It's whatever most comfortable for you.

Motivation

This project was created as a clone of my capstone project, but steered towards my vision of the project, instead. Here are a few main reasons as well as differences that led to the creation of this project.

• They don't seem to care about sources of truth. Their version of an SRS or a PRD is simply a list of features, or what they want to do, such as "A branch manager can manage menu items (add, remove, delete)".
• They are optimizing for the first minute the user uses, as long as you can master the tool in 5 minutes, that's good enough. I want to optimize for the user's 1000th minute of usage, I want them to work with the system fast instead of following the system step-by-step like a form-filling data spreadsheet job.
• They are thinking that data normalization should be the principle of the platform, regardless of user intuition. Clones are always referenced, like a branch is a "ref" to another, and changing the template branch changes all affected branches as a way to boast about automation and efficiency. For me, this is error-prone, and people prefer explicitness in a B2B software, I'd assume so.
• They want to use tables to represent naturally relational data, such as menus and items, or users and roles, while wanting to use a hierarchical layout for billings and data management.
• They let the libraries, chosen technologies to be rather limited to do the heavy lifting, but they can't customize it or work outside the libraries. So the way they use those libraries dictates what the database or the UI design to be.

And there are a lot more reasons, but that's the gist of it. The clash in philosophy is too big to warrant fighting it out over a capstone.

Requirements

These include libraries or binaries that are required to do any development work at all:

• Docker & Docker Compose
• Rustc v1.93
• Sqlx (cargo install cargo-sqlx)
• NodeJS (via NVM or NPM is fine)
• GoTask (aka Task or Taskfile)
• Caddyserver (not required, but nice to have)

Structure

This project is setup as a mono-repo handled with Taskfile. Run task or go-task to see usable commands. For example:

• go-task dev starts the backend and all the frontends with hot reload.
• go-task test:backend for testing Backend
• go-task build tries to build Docker images of each to allow easy deployment.
• go-task build:ui to build the UI components.

There are the following apps inside this mono-repo, under /apps:

• backend: The centralized backend of the system.
  • Uses Rust and Axum.
  • Port 8080.
• frontend-admin: The platform-wide administrative panels of the system.
  • Uses Vite, Vue and Vue Router.
  • Port 3003.
• frontend-home: The home of the SaaS.
  • Uses Astro and Vue.
  • Port 3000.
• frontend-pos: POS SPA/PWA for workers in a POS system.
  • Uses Vite, Vue, Vue Router and Service Worker.
  • Port 3002.
• frontend-tenant: The home page of the tenant's.
  • Uses Astro and Vue.
  • Port 3001.

For reference, this is the capstone's team's setup:

Also a mono repo, under /apps:

• backend: Centralized backend of the system.
  • Uses NestJS and @orpc/nest.
• frontend: Centralized frontend of the system.
  • Uses Tanstack Router, React and @orpc/client.
• Type-safe pkgs/api-contracts to import into both.

This sounds great on paper, but from what I noticed, it's a lot of problems because everytime there's some dude committing something, the others are like "wait we haven't updated that contract yet". So when the other eventually do update them, the other have to go back and change what the previous person changed. That doesn't seem wonky and roundabout at all.

Local Environment Setup

Due to the nature of DNS-level namespacing of this project, you would need to modify your system's hostfile for the most similar setup to production.

In my capstone's team, this is not needed as there's only one frontend and one backend. And everything is namespaced in the path level.

To edit the hostfile, edit /etc/hosts on Unix systems and C:\Windows\System32\drivers\etc\hosts on Windows, and add the following:

127.0.0.1        foodbasket.localhost
127.0.0.1        admin.foodbasket.localhost
127.0.0.1        twinbells.foodbasket.localhost
127.0.0.1        pos.twinbells.foodbasket.localhost

twinbells can be changed to match whatever your fake restaurant to be. But this should be enough to differentiate between the four frontend applications. You may add more to the system, for example a different tenant to see what.

Using Caddy/Nginx

You may use caddy or nginx as a way to reverse proxy into the services. There is already a Caddyfile as an example for what you can do. But I won't go too deep into that.