AIに聞く：データ操作をunstorage適応に変えるにはどうすればよいですか？

AI に聞く：データ操作を unstorage 適応に変換するのはどうですか？

背景#

私はプログラマーです。github にある unjs/unstorage というライブラリを思いつきました。異なるドライバ適応層を接続することで、操作データを hasItem、getItem、setItem、remoteItem としてカプセル化します。これはフロントエンドの localStorage の概念をマッピングしています。

この方法でフロントエンドのデータ操作シーンに適応するのは良いと思っています。技術は難しくなく、成果も出やすく、学習コストを簡素化します。例えば、私には WordPress API があります。具体的な使い方を学ぶ必要はなく、ウェブサイト情報を更新する必要がある場合は、私が提供する unstorage-wp-site を使用し、コメントを返信したい場合は unstorage-wp-comments.setItem を使用します。似たように、get/post/put/delete のようなカプセル化の考え方を使うことで、既存の概念を再利用できます。どう思いますか？

私と AI の対話#

Claude3Opus はこう返答しました。

これは素晴らしいアイデアです！異なるデータ操作を localStorage のような一般的なインターフェースに抽象化することで、開発者の学習と使用コストを大幅に簡素化できます。あなたの考えについて以下のいくつかのアイデアと提案がありますので、参考にしてください：

インターフェース設計はできるだけシンプルで理解しやすく、開発者の既存の知識概念に近づけるべきです。あなたが言及した get/set/remove/has などのメソッドは非常に良いもので、名前を見ただけでその機能がわかります。

非同期操作を考慮してください。多くのストレージ呼び出しは非同期であり、Promise を返す必要があります。IndexedDB の非同期インターフェース設計を参考にできます。

エラーハンドリングは非常に重要です。インターフェース呼び出しはエラーを優雅に処理し、明確なエラーメッセージとコードを提供する必要があります。

バージョン管理とデータ移行。ストレージスキーマに変更があった場合、新旧バージョンの互換性とデータ移行を考慮する必要があります。

柔軟で構成可能です。良好な構成可能性を提供し、ユーザーが動作をカスタマイズできるようにします。例えば、カスタムキーのプレフィックス、データの有効期限、キャッシュ戦略などです。

優れたドキュメント。明確で包括的なドキュメントと使用例を作成することで、開発者の学習コストを下げることができます。

ユニットテスト。各ストレージ適応層に対して完全なユニットテストを作成し、安定性を確保します。

TypeScript サポート。プロジェクトが TS で書かれている場合、完全な型宣言ファイルを提供することを検討できます。

反対意見があり、彼は言いました。「unstorage-wp-xxx.setItemは、xxx が学習コストです。コストを一つの場所から別の場所に移動させただけで、システムがより複雑になりました [旺柴]」

Caude3Opus はこう返答しました。

この反対意見は非常に良いポイントを提起しています。unstorage という中間層を導入することは、ある意味で学習コストを底層 API から unstorage の適応層に移動させることになります。開発者は unstorage の概念と使用方法、各適応器の具体的な用途を理解する必要があります。これは確かに一定の学習負担とシステムの複雑さを増加させます。

しかし、長期的には unstorage のようなソリューションには価値があると考えています。主に以下の点を考慮しています：

統一されたインターフェース。異なるストレージソリューションにはそれぞれのインターフェースと使用法があり、unstorage を通じて統一されたインターフェースを提供することで、開発者が異なるストレージソリューション間で切り替える際の学習コストを下げることができます。

複雑性のカプセル化。一部のストレージソリューションのインターフェースは非常に複雑で、パラメータが多いです。unstorage はこれらの複雑性をカプセル化し、よりシンプルで使いやすいインターフェースを提供できます。

ビジネスレベルの一般的なモジュールを蓄積できます。例えば、unstorage-wp-site や unstorage-wp-comments のようなビジネスレベルの適応モジュールは、プロジェクトの基盤として蓄積され、複数の機能モジュールで再利用できます。

統一されたエラーハンドリング、監視などのインフラを促進します。統一されたインターフェースがあれば、unstorage レベルでエラーハンドリングやログ監視を統一的に行うことができます。

より良いテスト可能性。unstorage 適応層を通じて、ストレージインターフェースをモックしてユニットテストを簡単に行うことができます。

私は、複数のドライバ適応層があれば、エコシステムとプラグイン市場をさらに形成できると考えています。しかし、これは新たな問題を引き起こす可能性があります。異なる SDK の考え方が異なるため、API の不一致が生じる可能性があります。引き続き反対意見の立場で私に挑戦し、さまざまな反対意見を提起してください。

わかりました。私は反対意見の立場を続けて、あなたの考えに疑問を投げかけ、挑戦します：

API の不一致の問題。あなたが言及したように、異なる SDK の考え方が異なるため、API 設計のスタイルが大きく異なる可能性があります。例えば、ある SDK は get/set/remove を好み、別の SDK は read/write/delete を好むかもしれません。パラメータ名や型も一致しない可能性があります。このため、開発者は異なる unstorage 適応層を使用する際に頻繁にドキュメントを参照する必要があり、開発コストが増加します。

質のばらつき。オープンなエコシステムとプラグイン市場は、誰でも unstorage 適応層を提供できることを意味します。しかし、異なる貢献者のコード品質、ドキュメントの充実度、メンテナンスの応答速度などは未知数です。これにより、開発者は適応層を選択する際に評価が難しく、統合後に問題が発生した場合にサポートを受けにくくなります。

バージョン互換性の問題。unstorage のコアインターフェースが変更されると、特定の適応層が新しいバージョンに互換性を持たなくなる可能性があります。開発者は適応層の作者の更新を待つ必要があるか、または自分で適応層のコードを修正する必要があります。この依存関係はプロジェクトの進行に影響を与える可能性があります。

過度の抽象化のリスク。一部のストレージソリューションはすでに優れたインターフェースを提供している可能性があり、unstorage で一層カプセル化することは過度の抽象化となり、逆に複雑さや性能のオーバーヘッドを増加させる可能性があります。

学習コストの問題。unstorage が統一されたインターフェースを提供しているとはいえ、開発者は各適応層に対応する具体的なストレージソリューションを理解する必要があります。例えば、unstorage-redis の使用シーンと unstorage-fs は異なります。開発者はこれらの違いを理解しなければ正しい選択ができません。この学習コストは避けられません。

エコシステムの分断。異なるプロジェクトやチームが異なる unstorage 適応層を選択する可能性があり、これがコミュニティエコシステムの分断を引き起こす可能性があります。むしろ、原生のストレージソリューションを直接使用する方が、異なるプロジェクト間の協力が容易です。

性能の問題。unstorage は中間層として、いくつかの性能オーバーヘッドを引き起こす可能性があります。特に高い同時実行性や大規模データのシーンでは、このオーバーヘッドがシステムのボトルネックになる可能性があります。

基礎知識の学習に不利。unstorage のようなカプセル化に過度に依存すると、開発者は基礎ストレージソリューションの原理やベストプラクティスを無視する可能性があります。これは開発者の成長にとって不利です。

もちろん、上記は単なるいくつかの可能性のある問題であり、unstorage が必ずしも悪い選択であることを意味するものではありません。しかし、unstorage を導入するかどうかを決定する際には、これらの潜在的な問題を慎重に評価し、利点と欠点を天秤にかけて、自分のプロジェクトに最も適したソリューションを選択する必要があります。

あなたは 8 つの反対意見を挙げました。私は異なる角度から反論できます：適応層の開発者の視点、ユーザーの視点、SDK 提供者の視点です。

開発者の視点から見ると、品質管理や自動テスト、機能認証の方法を約束することで、品質管理とバージョン互換性を確保できます。
ユーザーの視点から見ると、バージョンアップグレードメカニズムと自動移行プランを確立することで問題を減らし、このライブラリを使用することで詳細を平準化できます。これは開発者に明確に伝える必要があります。底層の特性に依存する場合は、依然として原始的な内容を学ぶ必要があります。
SDK 提供者の視点から見ると、上流にフィードバックを積極的に行い、自動テストのケースを確立し、長期的なフィードバックメカニズムを構築することで、ベストプラクティスを導入し、性能オーバーヘッドを減少させることができます。

私が言ったことに基づいて、引き続き私に挑戦してください。

素晴らしいですね。あなたは適応層の開発者、ユーザー、SDK 提供者の 3 つの視点からいくつかの解決策を提案しました。しかし、私はこれらの解決策にはいくつかの問題と課題があると考えています：

適応層開発者の視点

審査と認証メカニズムは開発者の負担を増やし、貢献の意欲を低下させる可能性があります。また、審査基準の策定と実施には人力と物力が必要です。

自動テストは確かに品質を向上させることができますが、包括的なテストケースを作成すること自体が挑戦であり、開発者は大量の時間を投入する必要があります。また、一部の境界条件や性能問題は、自動テストではカバーできない可能性があります。

ユーザーの視点

バージョンアップグレードと自動移行プランはユーザーのアップグレードコストを削減できますが、適応層間に大きな API の違いがある場合、自動移行は非常に困難であり、新しいバグを引き起こす可能性があります。ユーザーは手動でコードを調整する必要があるかもしれません。

あなたが言ったように、ユーザーが底層の特性に依存する場合、原始的な内容を学ぶ必要があります。この場合、unstorage の抽象化は意味を失うのではないでしょうか？ユーザーは「原始的な SDK を直接使用した方が簡単で直接的ではないか」と疑問を持つかもしれません。

SDK 提供者の視点

上流にフィードバックを行い、長期的なメカニズムを確立するには、SDK 提供者の協力と投入が必要です。しかし、すべての SDK 提供者が unstorage のような第三者の抽象層をサポートするための十分なリソースや意欲を持っているわけではありません。特に、閉じたソースコードの商業 SDK は、サポートを得るのが難しいかもしれません。

フィードバックメカニズムを確立しても、SDK 提供者は unstorage のために機能をカスタマイズしたり性能を最適化したりすることはあまり期待できません。彼らの優先順位は自分の SDK です。unstorage は SDK の変化に受動的に適応するしかありません。

上記の点に加えて、他にもいくつかの課題を考えました：

学習曲線とエコシステムの分断問題

ドキュメントや例があっても、開発者は unstorage の概念や API、さまざまな適応層の使い方に慣れるためには一定の学習曲線が必要です。また、異なる適応層間の違いは、開発者がプロジェクト内で異なるスタイルのコードを混用する原因となり、逆にメンテナンスコストを増加させる可能性があります。

異なるプロジェクトやチームが異なる適応層を選択することは、コードの再利用を難しくし、コミュニティエコシステムの分断を引き起こす可能性があります。

基礎能力の発揮を制限する

一部のストレージソリューションには独自の機能があるかもしれませんが、これらの機能は unstorage を通じて抽象化することが難しいか、抽象化された後に柔軟性を失う可能性があります。これにより、基礎ストレージソリューションの能力が制限されます。

性能に敏感なプロジェクトは、ストレージソリューションの性能に非常に注意を払う可能性があります。unstorage は中間層として、いくつかの性能オーバーヘッドを引き起こす可能性があり、これがプロジェクトの選択に影響を与えるかもしれません。

ローコードプラットフォームへの影響

現在、ローコードプラットフォームも台頭しています。その中には、いくつかのプリセットストレージコネクタを提供するプラットフォームがあります。unstorage の登場は、これらのプラットフォームの設計に干渉し、より多くの複雑さを引き起こす可能性があります。

もちろん、私が提起したこれらの問題は完全に解決できないわけではありません。実践の中で不断に探求し、利点と欠点を天秤にかけ、最適なバランスを見つける必要があります。しかし、決定を下す際には、これらの潜在的なリスクと課題を慎重に評価し、良い面だけを見てはいけません。

そして、私は自分の発言を GPT4 に投げました。

GPT4 はこう返答しました。

反対意見の立場から、以下のいくつかの潜在的な懸念と反対理由を提起できます：

1. 学習コストの移転ではなく削減
   unjs/unstorageによる操作のカプセル化はAPIの使用を簡素化するかもしれませんが、この簡素化は表面的なものかもしれません。ユーザーはunstorageライブラリとそのドライバを正しく使用する方法を学ぶ必要があります。プロジェクトで複数の異なるデータソースを使用する場合、ユーザーは複数のドライバの異なるAPIと概念を理解する必要があるかもしれません。これは学習コストが一つの場所から別の場所に移転するだけで、実際には削減されない可能性があります。

2. 一貫性と予測可能性の問題
   複数のドライバがある場合、それらのAPIスタイルと動作を一貫させることは挑戦となります。異なる開発者が異なる実装方法を持つ可能性があり、これが異なるドライバ間でのAPIの動作の不一致を引き起こし、理解やデバッグの難易度を増加させる可能性があります。

3. 性能と複雑性
   追加の抽象層を加えることは性能オーバーヘッドをもたらす可能性があります。各層のカプセル化は遅延やリソース消費を引き起こす可能性があります。さらに、システムの複雑性が増す可能性があり、問題が発生した場合、追加の抽象層を考慮する必要があるため、デバッグや問題解決がより困難になる可能性があります。

4. ドライバの品質と安全性
   コミュニティ主導のプラグインや適応層に依存することは、プロジェクトの品質と安全性に影響を与える可能性があります。すべての開発者がベストプラクティスに従うわけではなく、監査やテストが不十分であることが安全問題や欠陥を引き起こす可能性があります。

5. バージョン互換性とアップグレードの問題
   時間が経つにつれて、複数のドライバのバージョン互換性を維持することは複雑になる可能性があります。底層APIが変更されると、すべての適応層が更新される必要があり、ユーザーは頻繁なアップグレードや移行の問題に直面する可能性があります。

6. ロックイン効果
   `unstorage`およびその適応層が人気を博すと、ユーザーはこのエコシステムに過度に依存する可能性があり、技術的なロックインに陥るかもしれません。一度技術スタックを変更する必要がある場合や、より良い解決策が登場した場合、移行が困難になる可能性があります。

あなたが提起した異なる角度からの解決策は、確かにこれらの問題を緩和することができます。品質管理、バージョン互換性戦略、上流との良好な相互作用は、プロジェクトの長期的な成功を保証するための鍵です。しかし、最も重要なのは、開発者コミュニティの参加と貢献が高い基準と透明な環境で行われることを確保することです。これにより、エコシステム全体の健康を維持できます。

まとめ#

私は実行可能だと考えています。複数のライブラリが一緒に配置され、規模の効果が生まれれば、影響はさらに大きくなります。

私個人にとっては、普通のユーザーから深いユーザー、潜在的なメンテナ、エッジケースの提起者に変わることで、技術的な蓄積も成長します。