なぜNibiruではなくLaravelなのか？

ニビルはLaravelとSymfonyとは異なる5つの点 — 実際のプロダクションコードで支えられています。

Stable Reading time ~ 2 min Edit on GitHub

ほとんどのPHPフレームワークの比較は感性です。この一个是grepできるものです。

以下の5つの違いは、実際の収益サイト maschinen-stockert.de から取り出されました。これは多言語の産業機械マーケットプレースです。36コントローラー、18モジュール、348テンプレート、161SQLマイグレーション、37,369行のPHP が2つのリポジトリに分散しています。すべての主張はコードベース内のファイル:行参照にリンクしているため、確認できます。

LaravelやSymfonyで開発経験がある人は、Nibiruが持っていないパターンに気づくでしょう。それがポイントです。

1. フレームワークに組み込まれたCMS層

Laravelでは、ページコピはBladeファイル（{{ __('page.title') }}）または翻訳JSONに存在します。変更するには、開発者はファイルを編集し、デプロイします。Nibiruでは、ページコピはデータベースに存在し、<controller>/<action> + 言語でキー付けされ、エディターは管理UIからコードに触れずに更新します。

public function pageAction()
{
    $controllerPath = $this->getController() . '/' . $this->getRequest('_action', 'page');

    foreach (Cms::init($this->getController())
                 ->loadCmsTemplateTextsByControllerPath($controllerPath, $this->language)
             as $t) {
        View::assign([
            $t['cms_template_texts_text_identifier']
                => $t['cms_template_texts_text_content']
        ]);
    }
}

全体的な影響: マーケティングがエディタで見出しを変更し、ページをリフレッシュして発行する。PRなし、デプロイなし、開発者が関与しない。これはCMSプラグインではない——フレームワークのCmsモジュールは組み込まれている。

→ モジュールをご覧ください。CMSモジュールが自分自身を構成する方法についてです。

2. モジュールはトレイトを介して構成され、サービスコンテナを介さない

Laravelの5,000行クラスに対する回答は、サービスプロバイダーや依存性注入です。Nibiruの回答はトレイトです。

maschinen-stockert.de 上の CMS モジュールは、13 のトレイトから構成されています。各トレイトは単一の責任を持っています — CmsStore, TextsForm, PageBuilderForm, CmsPageStructureModifier, FormElements, … 主な Cms クラスは 30 行で、これらを統合しています。新しい機能を追加するには “トレイトを作成し、含めれば完了” です。

class Cms implements Interfaces\Cms, SplSubject
{
    use Traits\CmsStore;
    use Traits\TextsForm;
    use Traits\PageBuilderForm;
    use Traits\CmsPageStructureModifier;
    use Traits\FormElements;
    / …8 more traits
}

全体的な効果: コンストラクタインジェクションゼロ、サービスプロバイダ登録ゼロ、設定ファイル内のbind() / singleton()呼び出しゼロ。新しい開発者はトレイト名をgrepで検索してすべての呼び出し元を見ることができます。

3. 直接の SQL と JSON の集約、ORM ではない

Eloquent と Doctrine には課金があります：ロードされる関係ごとに潜在的に N+1 クエリが発生し、PHP にプッシュされた集約はメモリを浪費します。Nibiru はデータベースの強みを活かしています。

-- application/module/machineryscout/traits/machinesElasticSearch.php
SELECT
    m.ms_machines_id AS machine_id,
    m.ms_machines_name AS machine_name,
    JSON_ARRAYAGG(
        DISTINCT JSON_OBJECT(
            'attribute_name',  ma.ms_machine_attributes_attribute_name,
            'attribute_value', mav.ms_machine_attribute_values_value,
            'attribute_type',  ma.ms_machine_attributes_attribute_type
        )
    ) AS attributes,
    JSON_ARRAYAGG(DISTINCT mi.ms_machine_images_filename
        ORDER BY mi.ms_machine_images_sort_order ASC) AS images
FROM ms_machines m
LEFT JOIN ms_machine_attribute_values mav ON mav.ms_machine_attribute_values_machine_id = m.ms_machines_id
LEFT JOIN ms_machine_attributes ma ON mav.ms_machine_attribute_values_attribute_id = ma.ms_machine_attributes_id
LEFT JOIN ms_machine_images mi ON mi.ms_machines_id = m.ms_machines_id
WHERE m.ms_active = 1
GROUP BY m.ms_machines_id;

一つのクエリ。JSONで集約された属性と画像、データベースからインデックスされたもの。結果は直接Elasticsearchにフィードされ、*“2500 × 1200 mm”*のような次元での範囲検索を可能にする準備ができています。

全体的な影響: N+1 問題は存在しません。監査可能、プロファイル可能、高速です。

データベースとマイグレーションについては、Database & Migrations を参照してください。このアダプターは、以下のようなクエリを実行します。

4. ロールベースのACL（ミドルウェアチェーンなし）

Laravelでは、認証はスタックです：authミドルウェア → ポリシークラス → ゲート → コントローラー。Nibiruでは、コンストラクタで3行です：

public function __construct() {
    parent::__construct();
    $this->user = new User();
    $this->acl  = new Acl();
    $this->acl->init();
    $this->user->validate();
}

$this->acl->init() は現在のセッション用のロール/権限セットを読み込みます。$this->user->validate() はセッションが正常かどうかを確認します。どちらかが失敗すると、リクエストはログインページを返します。アクションごとのチェック（$this->acl->can('edit', 'pages')）は必要とするアクション内で行われます。

APIコントローラーは逆のアプローチを取っています：コンストラクターでパブリックエンドポイントのホワイトリスト、それ以外には認証が必要です。

// public endpoints can be listed up-front, auth wraps the rest.
if (in_array($action, ['category', 'machines', 'ollama', 'team'])) {
    / public, skip auth
} else {
    $this->user = new User();
    $this->acl  = new Acl();
    $this->acl->init();
    $this->user->validate();
}

全体的な影響: 認証は1つのgrep可能な表現です。ミドルウェアの順序に関するバグはありません。「このエンドポイントがなぜ公開されているのか？」という謎もありません。

→ 認証の詳細については、認証を参照してください。

5. オブザーバパターン、イベントディスパッチャではありません

Laravelのイベントは、クロージャー、リスナー、およびキューされたジョブレコードを使用したディスパッチャを介して拡散されます。NibiruはPHPの標準ライブラリのSplSubject / SplObserverインターフェースを使用しています。同じパターンで、2つのインターフェースがあり、抽象化レイヤーはありません。

class Machineryscout implements IModule, \SplSubject
{
    private \SplObjectStorage $observers;

    public function attach(\SplObserver $o): void { $this->observers->attach($o); }
    public function detach(\SplObserver $o): void { $this->observers->detach($o); }
    public function notify(): void {
        foreach ($this->observers as $o) $o->update($this);
    }

    public function indexMachines(): void {
        / …do the work…
        $this->notify();   / analytics, cache invalidator, audit log all see it.
    }
}

全体的な影響: 状態の変化は同期的、決定論的、デバッグ可能。キューワーカーなし。リスナーが発火したかどうかの謎はありません。コントローラにオブザーバを追加すると、接続されます。

→ モジュールをご覧ください。

これにより得られるもの、2文で説明します。

個々の開発者や小さなチームは、フレームワークを学ぶ量が少ない、デバッグすべき抽象化が少ない、機能ごとの手続きが少ないで、実際の生産アプリケーションを構築し運用することができます。例えば、12カ国で工業機械を販売するアプリケーションなどです。トレードオフは、データベースクエリやイベントをフレームワークに隠したいと考えている場合、別の場所の方が幸せになるかもしれません。

コードを見たいなら、取ってください。

→ デモンストレーションを見る →