私がDavid Grudlなら、ネッテのどこを変えたいですか？

私は6年近く前から商用ソフトの開発で積極的にNette Frameworkを使用しています。最初の数年間は非常に熱心でしたし、フレームワークはチームとしてのすべてのニーズに完璧に対応していたので、基本的に他のツールを探す理由はありませんでした。

2019年頃から、ネッテ内の当初の熱意が落ちてきて、先進的な機能が恋しくなってきたところです。これらはフレームワークそのものを超えたものであることが多いので、実装されることも期待できないのですが、一方で、開発者は今後どのように開発を進めていくかを判断しなければならず、もしかしたら別の技術に手を伸ばすことになるかもしれません。

データベース層

私は、「ネットdeデータベース」は、残念ながらフレームワークの最大の失敗の一つだと考えています。

学校を出てすぐの後輩や、他のフレームワークから移行してきた中級者までが、ネッテを探求する一環として応募し、ネッテデータベースを発見するというインタビューが毎週、会社で行われています。データベース層としては悪くないのですが、そこで問題になるのが実際のプロジェクトでの実用性です。

これは、ネットデータベースが、最初から厳格なデータ型を使うこと、カラムやリレーションの名前を付けること、クエリー（リポジトリ）メソッドをモデルから分離することなど、全体として多くのことを行うための小さなニュアンスを開発者に押し付ける努力をしていないためである。

私は長年、当時大活躍したDibiライブラリを使っていました。これによって、かなりきれいにデータベースへの問い合わせができるようになり、インターフェイスも統一されました。一方、時代は進み、データベースが型付けされていないオブジェクトを返すようになると、PHPStanは原理的に満足できなくなるのです。

個人的には、実体とリポジトリのネイティブサポートを「Nette Database」に組み込むか、「Nette」の中でDoctrineの公式サポートを提供するか、どちらかだと思います。大企業レベルのアプリケーションをプログラミングするのであれば、開発には本腰を入れなければならず、特にDoctrineは非常に理にかなっていると思います。同時に、新参者にはすぐにでもより良い技術を教育したいし、古い習慣を教えたくないという思いもあります。

トレイシーとエラーログ

私は今でもTracyがPHP用の最高のランタイムデバッガーだと思っています。

2017年に無名のデジタルエージェンシーに来て、彼らのネッテプロジェクトの技術的な状況を見たとき、私はぞっとしました。エラーのログを取ろうとせず、純粋なPHPで書かれたサイトが何度あったことか。かなり簡単な解決策は、プロジェクトにTracyをインストールし、Debugger::enable()を呼び出し、それ以上何もしないことでした。バグは自動的にディレクトリに記録され、数日おきに手動で拾い上げるだけでよかったのです。

トレイシーに関しては、デビッドが改良する理由がほとんどない完成品のような気がします。一方で、新しい方向性にはまだ改善の余地があると思います。

例えば、セキュリティに真剣に取り組む企業や個人向けに、なぜTracyは有料機能を搭載しないのでしょうか。

トレイシーは、Sentryタイプのカスタムウェブインターフェースを実装し、アカウントを作成すると、プロジェクト全体でバグを追跡できるよう、APIを通じて自動的に生産バグが送信されるようにすることができます。また、アプリが個々のサイトをリクエストし、利用できないことを自動的に検知して、他の方法で所有者に通知することもできます（トレイシーはサーバークラッシュを論理的に検知できないため）。また、本番サイトで誤ってTracyを有効にしてしまい、データベースへのアクセス方法などがDIC経由で分かるという問題にも時々遭遇します。トレイシーも注意喚起してください。

Tracyは他にも、Node.jsで知っているちょっとしたことを実装することもできました。例えば、ソースコードの表示では、行内の特定のトークンをハイライトする可能性があるため、特別な方法でハイライトされる文字間隔を選択することが可能である。同時に、アプリケーションの次の部分でコンテキストを表示するために、2番目の（おそらく青色の）ハイライトラインのサポートを追加するとよいでしょう。

ソースコードのスニペットを表示する場合、コールスタックから直接ブラウザで探索できるように、コードの残りをajaxでレンダリングできるボタンを追加することも厭わない。これはSymfonyが行っていることであり、素晴らしい機能です。これに、メソッド、クラス、継承をクロールできる基本的な静的解析が加われば、チーム全体のデバッグ作業が大幅に軽減されるはずです。

コールスタックがパッケージをトラバースしている場合、特定のファイルに対して私が作業しているパッケージのバージョンを表示するのは良いことだと思います。開発中のパッケージでエラーを投げることがよくありますが、古いバージョンであることは視覚的にわかる方がいいかもしれませんね。

スタティックルーティング

Nette Routerの中に、スタティックルーターという新しいタイプを定義できるようにします。これは基本的なルーターの子孫にあたるが、文字列リテラルしか受け付けないため、正規表現ではなく、ストレートパスとなる。多くのページが静的に動作し（連絡先、各種記事、意外とホームページも）、そのためにルーターは毎回マッチとURL構成のための正規表現ルールを評価しなければならないのです。

例えばラテのテンプレートで静的なルートが使われていた場合、テンプレートのコンパイル時に安全に静的な https://ja.php.brj.cz/path 文字列に変換することができるので、例えばレイアウトにある100のURLをリクエストごとにコンパイルする必要はありません。

テンプレート側でのキャッシュで同じ機能を実現できることは理解していますが、システムでの解決はもっと評価できます。

Next.jsのフレームワークでは、スタティックルーティングという概念にすっかりはまってしまいました。n:href`などというものはなく、要するにURLをあらかじめ知っておかなければならないので、リダイレクトをあまりしない、URLのフォーマットをあらかじめ考えておく、しつこくしておくということをせざるを得ないのです。

PSRインターフェース

ネッテがPSRのインターフェイスをネイティブに実装していないのは残念です。パッケージ開発者として、Composer の依存関係を Nette で定義したい場合、これは迷うことになる。ネッテは多くの問題を解決してくれる一方で、その後買い替えることはないだろうということもわかっています。汎用的なインターフェースがないため、Symfony、Laravel、またはまったく別の汎用的なインターフェースを使いたいと思ったことが何度もあります。

将来のポータビリティのために汎用規格に対応していないことが、2022年にネッテから完全に手を引き、新しいアプリケーションはもっぱら汎用でチーム開発をしている最大の理由です。

APIレイヤー

REST APIのリクエストを処理するバックエンドとして、ネット社を利用したい場合はどうすればよいのでしょうか。プレゼンターを構築して、レスポンスを $this->sendJson() として送信するのでしょうか？サードパーティのライブラリはインストールされるのですか？それとも、足りないライブラリの必要性を、すぐに新しいライブラリを書くことで解決するDavid Grudlさんですか？

なぜネッテはREST APIのような一般的なものをすぐに実装できないのでしょうか？今日、ほとんどすべてのアプリケーションは、例えば、フロントエンドにデータを提供するために、APIを介して通信する必要があります。

初心者の場合、これまたビルトインのLatteやスニペットを使ってしまい、より良い選択肢があることを知らずに、フロントエンド全体を別途横に置いて構築し、そこにデータを提供するだけになってしまうのだそうです。

10年後を信じる

最後のポイントは、非常に現実的なもので、チーム内のビジネス部門から時折聞かれる議論から生まれたものです。

もし、デビッドグルドルがネッテの開発を完全に止めてしまったら、どうなるのでしょうか？もし、誰かが開発をやめたら？何に乗り換えるのか？そして、それはどれほどの挑戦なのでしょうか？

多くの開発者（多くの場合、企業での経験がない）は、この懸念を「大丈夫」と一笑に付したがる。そうだけど、そうじゃないみたいな。

社内の若手開発者を育成するために、NetteとReact、Node.jsのどちらに時間を割くか、という問題に取り組んだとき、残念ながら後者の選択肢が勝ります。

ネッテはまだ電車に乗り遅れてはいませんが、この半年間、何十回と面接している中で、かなり強く感じているんです。