Всем привет! Частенько ли у вас возникает желание пойти в одну очень популярную песочницу (Minecraft) ? Я думаю раз в пол года - год у многих возникает такое желание. И также часто возникает желание поставить парочку… сотен модов.
Этот пост написан для себя-любимого и для тех людей кого тоже очень бесит настраивать моды , пытаться их синхронизировать между друзьями. Я не претендую на какой то Clean код и тд и тп. Сразу признаюсь. Код писали ИИ агенты. Я просто как обычный обыватель и разработчик описываю свою боль и как я сделал инструмент в первую очередь для своих нужд.
Итак… Начнем
Что мы хотим:
Поиграть с друзьями на fabric/forge сборке
Не поссориться из-за того что друзьями приходится постоянно обновлять моды
Не лазить по сторонним ресурсам чтобы найти эти самые моды
Быстро запустить
Введение
Сразу уточню. Я говорю про Self-hosted варианты, а не покупка готового майнкрафт сервера на каком-нибудь Aternos
Какие вообще варианты у нас есть:
1) Просто развернуть сервер на хостовой машине (Без контейнеров)
2) Docker / Docker Compose
Удобный запуск, можно легко поменять версию Java и не создавать лишних зависимостей (Только если скачанный Docker Image). Но как в первом варианте. Придется все моды закидывать в папку сервера, запускать , смотреть логи , и еще желательно где-то рядом собирать клиентскую сборку, а потом ее архивировать и отправлять друзьям. И повезет если они не ленивые.
Я соглашусь, что никто не мешает написать парочку скриптов и это уже будет удобнее. Но чаще хочется просто зайти в удобную панельку, понажимать на несколько кнопок и точно быть уверенным что все друзья получат актуальную сборку и сервер живет как нужно
3) Pterodactyl
Первое что приходит на ум из более универсального и удобного, но я если честно считаю что он слишком огромный для такой простенькой задачи. Он больше предназначен для большой серверной инфраструктуры, а не для развертывания пары сборок.
Возможно я не знаю каких то вариантов, возможно более нишевых. Но по итогу было предпринято решение писать подобный инструмент самостоятельно !
Что использовал
Как и в начале любого проекта, нужно определиться со стэком и технологиями:
VueJS/Nuxt для интерфейс
GoLang - Я бы мог взять и Python для более быстрого прототипирования, но все таки решил пойти таким образом, просто потому что хотелось получить один маленький бинарь и попрактиковаться в языке + есть нативная поддержка Docker API, что мне в целом и нужно.
Docker - Да, все сервера мы будем держать в контейнерах. Возможно ударит по производительности, которой и так нет, но зато отслеживать и устанавливать сборки становится очень просто засчет одного проекта, я говорю про itzg/minecraft-server. Этот образ послужит основой для управления серверами.
Wails - Позволяет писать десктопные приложения с использованием системного WebView на Go. Можно было взять Electron, но очень уж не хотелось тащить зависимость в виде Chromium движка.
Пишем свой велосипед
Как уже и говорилось ИИ агенты позволили ускорить разработку в пару десятков раз (С тем учетом что я был не знаком с Wails, уж точно). Я использовал в разработке Devin IDE (бывш. Windsurf) с Kimi K2.6 в качестве модели
Для начала решил задать правила проекта:
# Go Coding Rules — WebUI Backend
## File Size
- **Maximum 300 lines per file.** Split by domain (handlers, service, repository) or by feature when the limit is reached.
## Style & Formatting
- `gofmt` / `goimports` are mandatory.
- Import order: stdlib → third-party → project internal (`github.com/.../webui/backend/internal/...`).
## Error Handling
- Explicitly handle every error. Use `http.Error` or structured JSON errors for HTTP handlers.
- Log errors with context before returning them to the client.
## Architecture
- Keep `cmd/main.go` minimal: only wiring (DI, config, server start).
- Business logic lives in `internal/` packages, never in handlers directly.
- Handlers depend on interfaces, not concrete types.
## Naming
- Exported names need godoc comments.
- Handler functions use HTTP-method style where appropriate: `GetUser`, `PostServer`.
- DTO structs for requests/responses end in `Request` / `Response`.
## Testing
- Use `httptest.Server` for handler tests.
- Mock DB / external calls; do not hit real databases in unit tests.
- Run `go test ./...` in `backend/` before committing.
# Vue Coding Rules — WebUI Frontend
## File Size
- **Maximum 600 lines per file, including `<template>`, `<script>`, and `<style>`.**
- If a component exceeds this limit, decompose it:
- Extract child components.
- Move composables / utilities to `composables/` or `utils/`.
- Move large `<style>` blocks to scoped CSS modules or Tailwind utilities.
## Component Structure
Use this order inside `.vue` files:
1. `<script setup lang="ts">`
2. `<template>`
3. `<style scoped>` (only if Tailwind classes are insufficient)
## TypeScript
- Strict mode is on. No `any` without a documented reason.
- Define props with `defineProps<{}>()` and emits with `defineEmits<{}>()`.
- Prefer interfaces over types for object shapes.
## Composition API
- Use `<script setup>` and Composition API exclusively. No Options API.
- Extract reusable logic into `composables/` (e.g., `useServer()`, `useConsole()`).
- Keep components focused: one primary responsibility per component.
## Templates
- Use `kebab-case` for custom components in templates.
- Always provide `key` attributes in `v-for`.
- Avoid complex expressions in templates; use computed properties.
## Styling
- TailwindCSS is the default. Use utility classes first.
- Custom scoped styles only for complex overrides or third-party component theming.
- Never use element selectors (e.g., `div { ... }`) in scoped styles.
## State & Fetching
- Server state: use Nuxt composables (`useFetch`, `$fetch`) or a lightweight Pinia store if caching / cross-component sharing is needed.
- Client-only state: Pinia or `ref`/`reactive` inside composables.
- Always handle loading and error states in async operations.
## Performance
- Lazy-load heavy components with `defineAsyncComponent`.
- Debounce rapid user input (search, resize handlers).
- Prefer `v-show` over `v-if` for toggling visibility when the DOM cost is high.
## Linting
- Run `pnpm lint` (or the project's lint command) before pushing.
- Fix all TypeScript and Vue compiler warnings.
Примерная схема
Сначала был написан Оркестратор контейнеров-серверов через Docker API.
Он использует хостовый /var/run/docker.sock для управления хостовыми контейнерами (Это крайне небезопасно, но и мы не делаем пока что SaaS).
Сами сервера сразу прокидывают Volume в хост систему. Чтобы к файлам было легко попасть
Что можно делать
Просмотр логов
Управление состоянием сервера
Изменение параметров контейнера / сервера
Работа с файлами
Просмотр краш-репортов
RCON консоль
Управление игроками
Управление клиентскими и серверными модами
Помимо этого еще сделана интеграция с Modrinth.
Создание клиентской сборки
Эта ссылка используется для синхронизации с клиентом.
Sync-утилита
Она была написана на Go + Wails + Vue. И служит простеньким интерфейсом для синхронизации сборок. Также клиенту рекомендуется использовать MultiMC или Prism Launcher (или его форки).
Если кому-то будет интересно, то я открыт к диалогу. Репозитории к вашим услугам.
Всем хорошего дня/вечера/ночи (Или когда вы там вообще это читаете). Не факт что вообще кто-то дочитал до конца :)