Oder: Was passiert, wenn “schnell genug” nicht reicht
318 Requests pro Sekunde. 1.000 gleichzeitige Nutzer. Null verlorene Verbindungen.
Das sind Stresstestergebnisse von Doppar, einem PHP-Framework, von dem du wahrscheinlich noch nie gehört hast. Laravel optimiert für Developer Experience. Symfony optimiert für Enterprise-Stabilität. Doppar optimiert für pure Geschwindigkeit — und überlässt dir den Rest.
Für wen das hier ist: Du hast deine PHP-Anwendung profiliert, Queries
optimiert, Caching eingebaut, und brauchst trotzdem mehr Durchsatz. Du hast kein
Problem damit, Integrationen selbst zu schreiben, die woanders ein
composer require wären. Du willst Laravel-Syntax ohne Laravel-Overhead.
Was ist Doppar?
Permalink to "Was ist Doppar?"Doppar ist ein performantes, minimalistisches PHP-Framework, das Ende 2025 Version 3.x veröffentlicht hat. Es basiert auf drei Prinzipien:
- Null externe Abhängigkeiten für Kernfunktionen
- Intelligentes Memoization wiederholter Ausführungen
- Attribute-First-Konfiguration
composer create-project doppar/doppar my-app
cd my-app
php pool server:start
Deine erste Route:
// app/Http/Controllers/HelloController.php
#[Mapper(prefix: 'api')]
class HelloController extends Controller
{
#[Route(uri: 'hello/{name}', methods: ['GET'])]
public function greet(string $name): Response
{
return response()->json(['message' => "Hallo, {$name}!"]);
}
}
Voraussetzungen: PHP 8.3+ und Composer.
Geschichte & Philosophie
Permalink to "Geschichte & Philosophie"Doppar wurde von techmahedy entwickelt — ein Entwickler, der Laravels elegante Syntax ohne den Overhead wollte. Das 3.x-Release Ende 2025 markierte den Übergang vom Experiment zum nutzbaren Framework. Die Parallele zu Laravels eigener Entstehungsgeschichte ist kein Zufall — Symfony existierte und war robust, aber Laravel fand seine Stimme, indem es etwas anderes anbot.
Die Philosophie ist simpel:
“Brauchst du ein Feature? Installier es und nutz es. Brauchst du es nicht? Halt deine Anwendung so einfach und sauber wie möglich.”
Doppar will Laravel oder Symfony nicht ersetzen. Es ist eine Alternative für Entwickler, die alles aus ihrem aktuellen Stack rausgeholt haben und trotzdem mehr brauchen.
Warum ist es schnell?
Permalink to "Warum ist es schnell?"Drei Techniken machen Doppar schneller als typische PHP-Frameworks:
1. Intelligentes Memoization
Permalink to "1. Intelligentes Memoization"Wiederholte Ausführungen werden automatisch gecacht. Config-Parsing, Service-Auflösung, Route-Matching — alles, was mehr als einmal läuft, wird ohne manuelles Eingreifen memoized.
2. Abhängigkeitsfreier Core
Permalink to "2. Abhängigkeitsfreier Core"ORM, Validation, WebSocket-Server und Scheduler sind direkt im Core eingebaut. Kein Doctrine. Keine externen Queue-Packages. Keine Third-Party-HTTP-Clients für interne Operationen. Weniger Packages bedeutet weniger Autoload-Aufrufe und weniger Initialisierungs-Overhead.
3. Minimale Initialisierungszeit
Permalink to "3. Minimale Initialisierungszeit"Schwere Frameworks zahlen mit langer Initialisierungszeit — die Zeit, die fürs Bootstrapping draufgeht, bevor ein einziger Request bearbeitet wird. Doppar minimiert das durch Lazy-Loading von Services und flache Dependencies. Im Worker-Modus bootet die Anwendung einmal und bleibt im Speicher.
Das Ergebnis: Benchmarks zeigen etwa 7-8x höheren Durchsatz als typische PHP-Frameworks unter vergleichbaren Bedingungen.
Benchmark-Methodik: Die 318 req/s stammen aus
Doppars Stresstest-Dokumentation
mit wrk, 1.000 gleichzeitigen Verbindungen über 30 Sekunden. Der
“7-8x”-Vergleich ist gegen eine Standard-Laravel-Installation auf derselben
Hardware. Das sind Herstellerangaben — unabhängige Benchmarks sind willkommen.
Deployment-Modell: Doppar läuft in zwei Modi. Klassisches PHP-FPM
funktioniert, aber die Performance-Vorteile gehen verloren — jeder Request
startet neu. Worker-Modus (php pool server:start) hält die Anwendung zwischen
Requests im Speicher, ähnlich wie Swoole oder RoadRunner. (Für mehr Hintergrund
zu diesen Async-Runtimes, siehe
Async PHP in Production.) Die
Benchmarks gehen vom Worker-Modus aus. Wenn dein Hosting PHP-FPM erfordert
(Shared Hosting, manche PaaS), schrumpft der Geschwindigkeitsvorteil deutlich.
Besondere Features
Permalink to "Besondere Features"Bevor wir einzelne Module vergleichen, hier was Doppar bietet, das Laravel und Symfony nicht eingebaut haben:
Airbend: Native WebSockets
Permalink to "Airbend: Native WebSockets"Die meisten PHP-Frameworks behandeln WebSockets stiefmütterlich — nimm Pusher, starte einen Node.js-Server, oder konfiguriere Ratchet. Symfony hat Mercure, das Real-Time elegant löst, aber einen separaten Hub-Service erfordert (in Go geschrieben). Laravel bietet Broadcasting mit Pusher oder einer selbst gehosteten Lösung via Laravel Reverb.
Doppar geht einen anderen Weg mit Airbend — eine native WebSocket-Komponente, die im selben PHP-Prozess läuft:
use Doppar\Airbend\Broadcast;
Broadcast::channel('orders')
->event('order.created')
->data(['order_id' => $order->id])
->send();
// Channel-Autorisierung
Broadcast::channel('orders.{id}', function ($user, $id) {
return $user->orders()->where('id', $id)->exists();
});
Keine externen Services. Kein separater Server-Prozess. Der Trade-off: Mercure ist bewährt und skaliert horizontal; Airbend ist neuer und bindet deine WebSockets an den Lifecycle deines PHP-Workers.
Dual-Mode Task Scheduler
Permalink to "Dual-Mode Task Scheduler"Standard Cron-getriggerter Modus:
* * * * * cd /path/to/project && php pool schedule:run
Oder Daemon-Modus für Sub-Sekunden-Präzision:
php pool schedule:daemon
Der Daemon-Modus läuft kontinuierlich und prüft Tasks mehrmals pro Sekunde — keine Supervisor-Konfiguration nötig.
Schedule::call(fn() => $this->pingHealthCheck())
->everySecond();
Schedule::command('reports:generate')
->dailyAt('02:00')
->runInBackground();
Automatische Transaktionen via Attributes
Permalink to "Automatische Transaktionen via Attributes"use Phaseolies\Utilities\Attributes\Transaction;
#[Transaction]
public function transferFunds(Account $from, Account $to, float $amount): void
{
$from->decrement('balance', $amount);
$to->increment('balance', $amount);
// Commit bei Erfolg, Rollback bei Exception
}
Optionale AI-Integration
Permalink to "Optionale AI-Integration"Doppar bringt einen AI-Wrapper mit — keine Core-Abhängigkeit, aber verfügbar, wenn du ihn brauchst:
use Doppar\AI\Agent;
$response = Agent::make()
->model('gpt-4')
->prompt('Fasse diese Bestellung zusammen')
->context(['order' => $order->toArray()])
->send();
Unterstützte Provider: OpenAI (GPT-3.5/4), Anthropic (Claude) und lokale Modelle
via TransformersPHP. API-Keys konfigurierst du in .env — es passieren keine
AI-Calls, solange du die Agent-Klasse nicht explizit nutzt.
Modul-Vergleiche
Permalink to "Modul-Vergleiche"Routing
Permalink to "Routing"Doppar — Attributes mit Inline-Rate-Limiting:
#[Mapper(prefix: 'api/users', middleware: ['auth'])]
class UserController extends Controller
{
#[Route(uri: '{id}', methods: ['GET'], name: 'users.show')]
public function show(string $id): Response
{
return response()->json(User::find($id));
}
#[Route(uri: '', methods: ['POST'], rateLimit: 10, rateLimitDecay: 1)]
public function store(Request $request): Response
{
// Limitiert auf 10 Requests pro Minute
}
}
Symfony — Native Attributes, Rate-Limiting via separatem Bundle:
#[Route('/api/users', name: 'users_')]
class UserController extends AbstractController
{
#[Route('/{id}', name: 'show', methods: ['GET'])]
public function show(int $id): Response
{
return $this->json($this->userRepository->find($id));
}
}
Laravel — Datei-basiertes Routing (Attributes via Package):
// routes/api.php
Route::middleware(['auth:sanctum'])->prefix('api/users')->group(function () {
Route::get('{id}', [UserController::class, 'show']);
Route::post('', [UserController::class, 'store'])->middleware('throttle:10,1');
});
Dependency Injection
Permalink to "Dependency Injection"Doppar — Explizites Binding auf Parameter-Ebene:
class OrderController extends Controller
{
#[Route(uri: 'orders', methods: ['POST'])]
public function store(
#[Bind(StripeGateway::class)] PaymentGatewayInterface $gateway,
Request $request
): Response {
// $gateway ist StripeGateway
}
}
Symfony — Config-Datei oder #[Autowire]:
// config/services.yaml
services:
App\Payment\PaymentGatewayInterface:
class: App\Payment\StripeGateway
Laravel — Service Provider:
// AppServiceProvider.php
$this->app->bind(PaymentGatewayInterface::class, StripeGateway::class);
Doppars Ansatz macht das Binding direkt an der Verwendungsstelle sichtbar. Trade-off: Ausführlicher, wenn du Framework-weite Defaults willst.
ORM
Permalink to "ORM"Doppar — Eloquent-Style API, null Abhängigkeiten:
$users = User::where('active', true)
->whereBetween('created_at', [$start, $end])
->orderBy('name')
->limit(10)
->get();
// Batch-Insert mit Chunking
User::saveMany($records, 1000);
// Speichereffiziente Iteration
foreach (User::where('active', true)->cursor() as $user) {
// Ein Datensatz zur Zeit
}
Symfony (Doctrine) — QueryBuilder:
$users = $this->userRepository->createQueryBuilder('u')
->where('u.active = :active')
->andWhere('u.createdAt BETWEEN :start AND :end')
->orderBy('u.name')
->setMaxResults(10)
->setParameters(['active' => true, 'start' => $start, 'end' => $end])
->getQuery()
->getResult();
Laravel (Eloquent) — Fast identisch mit Doppar:
$users = User::where('active', true)
->whereBetween('created_at', [$start, $end])
->orderBy('name')
->limit(10)
->get();
Doppars ORM-Syntax spiegelt Eloquent — vertraut, wenn du von Laravel kommst. Der Unterschied: Kein externes Package, direkt im Core eingebaut.
Validation
Permalink to "Validation"Doppar:
$validated = $request->sanitize([
'name' => 'required|min:2|max:100',
'email' => 'required|email|unique:users',
'age' => 'required|int|between:18,120',
]);
Symfony:
class UserDto
{
#[Assert\NotBlank]
#[Assert\Length(min: 2, max: 100)]
public string $name;
#[Assert\Email]
public string $email;
}
$errors = $validator->validate($dto);
Laravel:
$validated = $request->validate([
'name' => 'required|min:2|max:100',
'email' => 'required|email|unique:users',
]);
Doppar und Laravel sind quasi identisch. Symfonys DTO-Ansatz bietet bessere Type-Safety für komplexe Domains, braucht aber mehr Code.
Community & Ecosystem
Permalink to "Community & Ecosystem"| Metrik | Doppar | Laravel | Symfony |
|---|---|---|---|
| GitHub Stars | ~200* | 78k+ | 30k+ |
| Erstes Release | 2024 | 2011 | 2005 |
| Packagist Downloads | <10k* | 300M+ | 500M+ |
| Discord/Community | Klein* | 120k+ | Groß |
*Doppar-Zahlen sind Schätzungen vom Januar 2026. Aktuelle Werte auf GitHub und Packagist.
Doppars Ecosystem ist jung. Du wirst Integrationen selbst schreiben, die bei
Laravel oder Symfony ein composer require wären. Der Trade-off für
Performance: Mehr Eigenarbeit.
Solltest du Doppar nutzen?
Permalink to "Solltest du Doppar nutzen?"Die ehrliche Antwort: wahrscheinlich nicht — noch nicht.
Doppar macht Sinn in einem engen Szenario: Du baust High-Throughput-APIs, hast deine Laravel- oder Symfony-App bis zum Anschlag profiliert, und der Framework-Overhead ist immer noch dein Bottleneck. Du hast kein Problem damit, Integrationen selbst zu schreiben, und du brauchst kein PostgreSQL (nur MySQL und SQLite). Wenn das auf dich zutrifft, ist Doppar einen ernsthaften Blick wert.
Für alle anderen sind die Trade-offs schwer zu rechtfertigen. Laravel hat tausende Packages und eine riesige Community. Symfony betreibt Enterprise-Systeme mit bewährter Stabilität. Beide haben ein Jahrzehnt Production-Edge-Cases, Security-Audits, CVE-Tracking und Responsible-Disclosure-Prozesse hinter sich. Doppar hat dieses Volumen an Real-World-Nutzung noch nicht gesehen — manche Dokumentationsseiten liefern noch 404, und das Queue-System ist nicht vollständig dokumentiert.
Es gibt auch Risiken zu bedenken. Doppar hat einen einzigen Haupt-Maintainer. Wenn techmahedy aufhört, ist die Zukunft des Projekts ungewiss. Das Framework ist jung — erwarte Breaking Changes zwischen Minor-Versionen während die APIs reifen. Und Entwickler mit Doppar-Erfahrung zu finden wird deutlich schwerer als bei Laravel oder Symfony.
Wenn du reine Performance brauchst, aber das Ecosystem nicht aufgeben willst, schau dir Swoole oder RoadRunner mit Laravel oder Symfony an. Du bekommst den Großteil der Performance-Gewinne und behältst Zugang zu Packages, Dokumentation und Community-Support.
Für einen tieferen Laravel-vs-Symfony-Vergleich ohne den Performance-Fokus, siehe Laravel vs Symfony 2025: Wann was nutzen.
Doppar ist kein Laravel-Ersatz. Es ist ein spezialisiertes Tool für ein spezifisches Problem.
Meine Meinung: Doppar ist ein interessantes Projekt, das man im Auge behalten sollte. Die Philosophie ist nachvollziehbar — Laravel-Ergonomie ohne den Overhead — und die native WebSocket-Integration ist echt überzeugend. Aber für Production bin ich skeptisch. Der Abstand zu Laravel ist nicht groß genug, um die Ecosystem-Trade-offs für die meisten Teams zu rechtfertigen. Wenn du reine Performance brauchst, gibt dir Swoole oder RoadRunner auf Laravel/Symfony vielleicht 80% der Vorteile, ohne das Ecosystem aufzugeben. Doppar fühlt sich an wie ein Framework für eine sehr spezifische Nische: High-Throughput-APIs, wo jede Millisekunde zählt und du kein Problem damit hast, alles selbst zu bauen.
Trotzdem: Konkurrenz belebt das Geschäft. Wenn Doppar Laravel und Symfony dazu bringt, sich mehr um Performance zu kümmern, gewinnen alle. Ich behalte es im Blick — aber meine Production-Apps bleiben erstmal auf Symfony.
Die Dokumentation findest du auf doppar.com. Das Framework ist MIT-lizenziert auf GitHub. PHP 8.3+, Composer, und die Bereitschaft, Komfort gegen Mikrosekunden zu tauschen.
