DEV Community: Mustafa Bingül

I got tired of heavyweight frameworks, so I built my own web server in Java

Mustafa Bingül — Fri, 24 Apr 2026 20:30:58 +0000

I got tired of heavyweight frameworks, so I built my own web server in Java

Most Java web projects start with Spring Boot. You add the dependency, and suddenly you have an entire ecosystem loaded into memory before your first route is even registered. For a lot of use cases that's totally fine. But I wanted something I could drop a JAR into a folder, double-click, and have a running web server in under three seconds — no config ceremony, no classpath drama.

So I built Aurelius.

What is it?

Aurelius is a lightweight, minimalist Java web server designed for developers who want to get a site or a small API running without pulling in a full framework. It runs on Java 8+, ships as a single executable JAR (or .exe on Windows), and is built on top of Netty for the networking layer.

The core idea: drop the JAR in a folder, launch it, put your HTML files in the right place, and you have a running server. That's it.

Project structure

When Aurelius starts, it expects this layout:

my-project/
├── aurelius.jar
├── settings.yml
├── app/
│   └── main.html        ← served at /
│   └── about/
│       └── main.html    ← served at /about
├── containers/
│   └── button.html
│   └── section.html
└── public/
    └── logo.png
    └── data.json

Every folder under app/ becomes a route. main.html in a folder is the index for that route. Files under public/ are served statically and accessible from any HTML file via /public/filename.

The container system

This is the part I'm most proud of. Instead of reaching for a templating engine, I built a simple component system directly into the server.

You define a reusable HTML fragment in the containers/ folder:

<!-- containers/button.html -->
<button class="btn btn-primary">{text}</button>

Then you use it anywhere in your pages with a custom tag:

<container.button text="Click me"></container.button>

Aurelius processes the tag at serve time, injects the attribute values into the fragment, and sends the assembled HTML to the client. No JavaScript required, no build step, no npm.

You can nest containers, pass multiple attributes, and compose entire page sections from reusable fragments. It's not React — it's intentionally much simpler — but for static-ish sites it removes a lot of repetition.

Placeholder system

For site-wide variables, Aurelius has a placeholders.yml file:

title: "My Site"
author: "Mustafa"
version: "1.2"

Anywhere in your HTML you write %title% and Aurelius substitutes it at serve time:

<head>
  <title>%title% — Home</title>
</head>

This is useful for things like site name, meta descriptions, or any string you'd otherwise duplicate across dozens of pages.

RESTful API support via addons

Aurelius isn't just for serving HTML. You can register REST endpoints programmatically through the addon system:

// GET /api/hello
AddonManager.registerRestFulService(
    new RestFulResponseStructure.Builder("hello")
        .setRestFulResponse((body, helper) -> {
            return "Hello, world! Path: " + Arrays.toString(helper.getPathData());
        })
        .setRequestType(RestFulRequestType.GET)
        .build()
);

For structured request/response bodies, you implement the RestFulResponse<Output, Input> interface and Aurelius handles JSON deserialization automatically:

public class UserController implements RestFulResponse<UserDto, UserRequest> {

    @Override
    public UserDto response(UserRequest request, RestFulResponseHelper helper) {
        UserDto dto = new UserDto();
        dto.setUsername(request.getUsername());
        return dto;
    }

    @Override
    public UserRequest convert(String body) throws Exception {
        return (UserRequest) AddonManager.convertFromBodyJson(body, UserRequest.class);
    }
}

Cookies are also supported through the helper:

CookieStructure cookie = new CookieStructure();
cookie.setCookieName("session");
cookie.setCookieValue(UUID.randomUUID().toString());
cookie.setFeatures(Arrays.asList(new CFMaxAge(3600), new CFHttpOnly()));
helper.sendCookie(cookie);

Configuration

All server settings live in settings.yml:

server:
  port: 8080
  threadSize: 4
  ui: true

ui: true enables a built-in management panel where you can start, stop, and reload the server without touching the terminal. Useful if you're deploying somewhere without a great CLI experience.

Framework support

Because Aurelius just serves HTML, it works with any CSS framework that can be loaded from a CDN. Tailwind, Bootstrap, Bulma — just drop the <link> tag in your HTML and it works.

Who is this for?

Aurelius is a good fit if you:

Want a zero-dependency web server for a small internal tool or personal site
Are learning Java web development and want to see how a server works without framework magic hiding everything
Need to prototype a REST API quickly without standing up a Spring application
Want to understand Netty's HTTP handling without writing the boilerplate yourself

It's not the right tool for large production applications with complex routing, authentication middleware, or ORM integration. For those, reach for Spring Boot or Quarkus.

What's next

The main thing on my list is proper test coverage — the container parsing and placeholder substitution logic especially need unit tests. I'm also thinking about WebSocket support and a simple session management API.

11 releases in, Aurelius handles the basics solidly. If you're the kind of developer who likes understanding what's running under the hood, give it a try.

I built a centralized data orchestration engine for distributed Minecraft servers — here's how

Mustafa Bingül — Fri, 24 Apr 2026 20:28:44 +0000

I built a centralized data orchestration engine for distributed Minecraft servers

This post is about a real architectural problem I ran into while working on a multi-server Minecraft network — and how I solved it by building a dedicated data microservice called Nexus Core.

The problem

A large Minecraft network runs many game servers at the same time: lobby servers, PvP arenas, survival worlds, minigame instances. Each one is a separate JVM process running a Spigot plugin. The traditional approach is simple — every server connects directly to MongoDB, manages its own in-memory cache, and handles its own data logic.

This works fine at small scale. At larger scale, three problems emerge:

Connection pool exhaustion. Each server holds its own pool of MongoDB connections. With 20 servers, you're throwing 20× the connections at your database for no good reason.
Cache incoherency. Server A caches a player's balance. Server B modifies it. Server A's cache is now stale. The player sees incorrect data depending on which server they're on.
Duplicated logic. The same data access code exists in every plugin. Changing how player data is structured means touching 15 codebases.

The solution: one service that owns all data

Nexus Core is a standalone Java application that acts as the single source of truth for all data in the network. Game servers never query MongoDB directly. Instead, they publish a structured packet to a Redis channel, and Nexus Core handles the rest.

Spigot #1 ─┐
Spigot #2 ──► Redis (pub/sub) ──► Nexus Core ──► MongoDB
Spigot #3 ─┘

This gives us:

A single, optimized MongoDB connection pool
A centralized Redis cache that all servers read from
Data logic defined once per data type, shared everywhere

The packet protocol

Every request from a game server is a JSON packet published to a Redis channel:

{
  "protocol": 100,
  "source": "pvp-1",
  "type": "GET_DATA",
  "data": { "uuid": "550e8400-e29b-41d4-a716-446655440000" }
}

protocol is a numeric ID that identifies which data type is being requested. source is the server's identifier, used to publish the response back to the right channel. type is one of GET, SET, DELETE, or GET_ALL.

Nexus Core subscribes to the inbound channel, deserializes the packet, and routes it to the right handler in O(1) via a Map<Integer, DataAddon>.

The DataAddon abstraction

A DataAddon is an abstract class that you extend to define a new data type. It maps to exactly one MongoDB collection and one Redis cache namespace. Here's what a minimal addon looks like:

public class PlayerStatsAddon extends DataAddon {

    @Override public int addonId()          { return 100; }
    @Override public String addonName()     { return "Player Stats"; }
    @Override public String getDatabase()   { return "nexus_core_db"; }
    @Override public String getCollection() { return "player_stats"; }
    @Override public String cacheKeyHeaderTag() { return "stats"; }

    @DbDataModels(isId = true)
    private String uuid;

    @DbDataModels(defaultValue = "0", isId = false)
    private int kills;

    @DbDataModels(defaultValue = "0", isId = false)
    private int deaths;

    @Override
    public boolean handleRequest(String source, RequestType type, NexusJsonDataContainer data) {
        return true; // return false to reject the request
    }
}

Nexus Core discovers the schema at boot time via reflection over @DbDataModels annotations. It finds which field is the primary key, reads default values for missing fields, and knows how to serialize/deserialize documents without you writing any mapping code.

Registering the addon is one line:

NexusApplication.getInstance().getProtocolHandler().registerAddon(new PlayerStatsAddon());

From that point on, any game server can send a packet with protocol: 100 and get a full player stats document back.

Request lifecycle

Here's the full flow for a GET request:

Game server publishes packet to Redis
Nexus Core receives it and looks up the addon by protocol ID
handleRequest() is called — if it returns false, an empty response is sent back immediately
Nexus Core checks Redis for key stats:{uuid}
Cache hit → serialize and publish response
Cache miss → query MongoDB, write result to Redis, publish response

SET writes through to both MongoDB and Redis. DELETE removes from both. GET_ALL bypasses cache entirely — caching arbitrary result sets would make invalidation logic very complex.

The handleRequest() interceptor

This is one of my favorite parts of the design. Before any database operation happens, your addon's handleRequest() method is called synchronously. You can inspect the source server, the request type, and the payload — and reject the request outright by returning false.

This is where authorization lives. For example:

@Override
public boolean handleRequest(String source, RequestType type, NexusJsonDataContainer data) {
    if (type == RequestType.REMOVE_DATA) {
        return source.equals("admin"); // only admin server can delete
    }
    return true;
}

Keep this method fast — it runs synchronously and blocks the request pipeline.

Monitoring dashboard

Nexus Core ships with a live monitoring UI built entirely in Java Swing with Java2D — no external libraries. It shows real-time JVM CPU load, process RAM usage, number of objects currently in the Redis cache, and the count of active addons. All rendered as animated donut charts and scrolling line graphs.

What I'd do differently

Looking back, the main thing missing is test coverage. The addon system and cache invalidation logic are exactly the kind of thing that benefits from solid unit tests, and I didn't write them. That's the next thing I'm adding.

I'd also consider replacing the protocol integer with a string identifier — numeric IDs work fine but require a separate constants file to stay readable, which is an avoidable friction point.

Repo

https://github.com/mustafabinguldev/nexus-core

If you're building anything on distributed Java infrastructure or have thoughts on the addon model, I'd love to hear from you in the comments.

DEV Community: Mustafa Bingül

I got tired of heavyweight frameworks, so I built my own web server in Java

I got tired of heavyweight frameworks, so I built my own web server in Java

What is it?

Project structure

The container system

Placeholder system

RESTful API support via addons

Configuration

Framework support

Who is this for?

What's next

Links

I built a centralized data orchestration engine for distributed Minecraft servers — here's how

I built a centralized data orchestration engine for distributed Minecraft servers

The problem

The solution: one service that owns all data

The packet protocol

The DataAddon abstraction

Request lifecycle

The handleRequest() interceptor

Monitoring dashboard

What I'd do differently

Repo