node.jsのアセンブリ

GitHubおよびNPMライブラリ。


node.jsとは関係のない未知の集約。 しかし、habrでは、写真を添付するのが良い形と考えられています

少し前に、node.jsで* SQLなどのリレーショナルデータベースやMongoなどのnoSQLを使用するのは複雑で、なぜプログラマーの速度に合わせた代替ソリューションを作成したのか（速度に合わせた従来のソリューションと比べて）データベースを操作する）および最小エントリしきい値のAPIの単純さとコンパクトさ。 最初のインスピレーションの源は、レポート「minimal surface API」 、2番目-ドナルドクールの有名な引用

プログラマーは、アプリケーションの重要ではない部分の速度を心配する異常な時間を費やし、効率を高めるこれらの試みは、これらのアプリケーションのデバッグとサポートに深刻な影響を及ぼします。 時期尚早の最適化はすべての悪の根源です 。

Dixleimer 1：ここで説明するライブラリは初期ベータ版です。 今のところ、あなたの人生の商業的または重要なプロジェクトには使用しないでください。

免責事項2：テキストには複雑な用語が表示され、コード例には多くのES6機能があります。 何かが理解できないと思われる場合-コメントを書いてください、私はテキストを簡素化し、コードにコメントを追加しようとします

sequelizeを使用したとき（他のライブラリの方が良いとは思わないでください）、どうしてそれが複雑なのかと思わず思いました。 それが内部からどのように機能するかを理解するという観点ではなく、いや-私はライブラリインターフェースを掘り下げます。 そこから手が伸びないか、開発者が私のようではなくDBAに焼き付いているかのどちらかです。

今、私は彼らがツールボックスに追加しようとしたこと、何ができるかを知っています。 出力は、前の14を組み合わせた15番目の標準です。地獄のようなジャグリングの組み合わせは、MySQL、SQlite3、Postgres、CouchDB、Mongo、Redis、Neo4jなどの非常に多様なデータベースのリストで使用できることを示しています。

しかし、小規模なプロジェクト-あらゆる種類のテレグラムボット、開発サーバー、およびSPA-の場合、複雑なORMアプローチの裏にある機能の複雑な部分は必要ありませんでした。 基本的に必要な機能は、レコード、条件および関係による選択の保存と検索です。 時期尚早な最適化は必要ありません。データベースからフィールドの一部を取得したり、クエリの最適化を行ったり、関数を保存したりします。 リレーションの選択（オブジェクトとすべての接続を取得する）は、トランザクションによって形式化できます。 速度が低下するため、宣言構文の追加エンティティの束がなくなります。 最も純粋な形のオッカムのカミソリ。

叙情的な余談：数万人から数十万人のユーザーがいるプロジェクトの開発の歴史を見ると、一定の時間が経過すると、開発者はスピードを失います。 クエリ、データベース、言語、プラットフォームを変更して機能するようにします。 プロジェクトが撮影された場合、彼は部品を交換する必要があり、ベースで最初に作業するのは、最初の努力が「将来のために」費やされていない場合です。 同時に、重くて複雑なORM構文は置換を複雑にします。 結論は明らかです。ORMの選択を将来の非技術的な負債として評価する場合、効率の低いソリューションが開発者の速度を提供し、最小限のAPIを提供することが正しい選択であり、別のソリューションへの移行を簡素化します。

ユニットを作りました

DBではなく、JS中心のActiveRecord-ただし、一部の場所では、古典的なパターンから遠ざかりました。

データベース中心ではないため、データベースはソリューションの要件に従って選択されたものであり、特定のデータベースについて決定されたものではないことを理解することが重要です。 Neo4jがリポジトリとして選択されました。 このソリューションには長所と短所がありますが、これまでのところさらに利点があります。

neo4jに慣れていない場合-これは、SQL、使いやすいWebクライアント、ボックスからのフルテキストインデックス（luceneを使用）、Postgresに比べてやや低い（線形）パフォーマンスよりも初心者にとってはるかに理解しやすい言語を備えた人気のあるグラフデータベースです/ Mysql。 すべてのインストール手順は、 http ： //neo4j.com/download-thanks/？edition = communityにあります。 Macでは、brew install neo4jを介してインストールされます

簡単な接続とエントリから始めましょう。

const {Connection, Record} = require('agregate') const dbPath = 'http://neo4j:password@localhost:7474'; class ConnectedRecord extends Record { static connection = new Connection(dbPath); } class User extends ConnectedRecord {} User.register() //  ,     const user = new User({name: 'foo'}) user.surname = 'bar' user.save() .then(() => User.where({name: 'foo'})) .then(([user]) => console.log(user)) //=> User {name: 'foo', surname: 'bar'} 

コードのわかりやすさから抜け出す唯一のものは、User.register（）の呼び出しです。 JSでは、ハンドラーをハングアップしてクラスを作成することはできません（そして、このことについて言語の開発者に感謝します）。

Record.registerメソッドは次の3つのことを行います。

1. このクラスを既存のデータベース接続に登録します。 単に置く-接続内のマップで、関連付け「ラベル」-「クラス」が推力されます。 （後でそれらについて）関連付けを解決するとき、データベースオブジェクトをJSオブジェクトに変換するために使用されるのはこのマップです
   
   
2. 内部ライブラリプロセスを開始します（セキュリティのために、インデックス付けとuuidの一意性の制限）
   
   
3. カスタムインデックスのインデックス作成を開始します（このクラスに設定されている場合）。

抽象クラスの場合、このメソッドを呼び出す必要はありません。

ES2015では、静的プロパティはエンティティプロパティと同じ方法で継承されます-示されているように、親クラスで一度connectonが宣言されます。 データベースが1つしかない場合、Record.connectionを接続に割り当てることもできますが、これは開発の観点からは正しくありません。

関係と関係

例を複雑にしましょう。 ACLを実行していて、関係が必要だと想像してください。

 const {Connection, Record, Relation} = require('agregate'); //  Role  Permission     const Role = require('./role'); const Permission = require('./permission'); export default class User extends ConnectedRecord { roles = new Relation(this, 'has_role', {target: Role}); permissions = new Relation(this.roles, 'has_permission', {target: Permission}); hasPermission = ::this.permissions.has } 

よく見ていないと、実際にはthis.permissionsが多対多の関係であることがすぐにわかりません。 この種の構文を使用すると、検索、削除、可用性の確認など、完全なクエリを使用できる関係の長いチェーンを構築できます。

Relationは、ES6の組み込みSetオブジェクトをエミュレートします。 APIは異なりますが、よく知られており、すぐに理解されます。 違いは、メソッドは既にデータを返すPromiseを返し、size（）はプロパティではなくメソッドであることです。 さらに、送信された要素の配列とリレーションに含まれる要素の共通部分を返す#intersectメソッドと、以下のように明らかにする#whereメソッドがありました。

DBで検索

これには、同じAPIを持つメソッドが使用できます。Record.where（）クラスのメソッドと、Relation＃where（）クラスのインスタンスメソッドです。 使用可能なオフセット、制限、順序、値による検索、配列の内容、配列へのエントリ（はい、型付き配列はneo4jのプリミティブの1つです）およびサブストリング。 検索には多くの機会があります。 それらはすべての主要なタスクをカバーしています。 すべてのオプションを列挙するのは非常に難しいため、typescriptのような構文で正式な説明を見るのは簡単です。

 var dbPrimitiveType = bool | string | number | Array<bool> | Array<string> | Array<number> async function where( params?: { [string: queryKey]: dbPrimitiveType | { $gt?: number //greater than -  $gte?: number //greater than or equal -    $lt?: number //less than -  $lte?: number //less than or equal -    $exists?: bool //   $startsWith?: Array<string> | string //  $endsWith?: Array<string> | string //  $contains?: Array<string> | string //  $has?: Array<dbPrimitiveType> | dbPrimitiveType //   $in?: Array<dbPrimitiveType> | dbPrimitiveType //   } }, opts?: { order?: string | Array<string>; //  -  key  key DESC  key ASC,  ['created_at', 'friends DESC'] offset?: number; limit?: number; }, transaction?: Queryable): Array<Record> 

取引

上記のAPIを使用すると作業できます。 残っているのは原子性の問題だけであり、これはトランザクションを使用して古典的に解決されます。

集約では、2つの方法でトランザクションを操作できます-単純または簡単です。

明確な方法は、額のトランザクションを使用することです。 これを行うには、（特に）最後の引数を渡します。 データベースで機能するすべての標準メソッドは、この表記法をサポートしています。

 class Post extends Record { author = ::new Relation(this, 'created', {direction: -1}).only //    only,      .      ,    . async static createAndAssign(text, user) { const transaction = this.connection.transaction() const post = await new this({text}).save(transaction) await post.author(user, transaction) await transaction.commit() return post } //  ,  -     async static createAndAssign(text, user) { const transaction = this.connection.transaction() try { const post = await new this({text}).save(transaction) await post.author(user, transaction) await transaction.commit() return post } catch (e) { await transaction.rollback() throw e } } } 

接続オブジェクト（クラスとクラスインスタンスの両方で使用可能）は、接続、トランザクション、またはサブトランザクションです。 3つのエンティティすべてが同じインターフェイスを提供し、内部のわずかな違いがあるため、人生の使用に違いはありません。 connection.transaction（）を呼び出すと、接続はトランザクションを返します。トランザクションはサブトランザクションであり、サブトランザクションは別のサブトランザクションです。

内部の違いは次のとおりです。接続のコミットおよびロールバックメソッドはエラーをスローします。トランザクションが期待どおりに動作する場合、サブトランザクションの場合-コミットは何もせず、ロールバックは親トランザクションをロールバックします。

これは、たとえばRecord＃save（）のように、一部のメソッドがトランザクションを生成し、最後に終了するために行われます。 このようなメソッドがトランザクションのフレームワーク内で正しく機能するために、サブトランザクションの無限のネストが実装されています。

2番目の方法-シンプル-では、デコレータが使用されます：

 import {Record, acceptsTransaction} from 'agregate' class Post extends Record { @acceptsTransaction async static create(text) { return await new this({text}).save(this.connection) } } 

コードは次のようになります。

 import {Record, acceptsTransaction} from 'agregate' class Post extends Record { async static create(text, transaction) { //Queryable -  ,    Connection, Transaction, SubTransaction if (transaction instanceof Queryable) this.connection = transaction try { const result = await new this({text}).save(this.connection) if (transaction) await transaction.commit() return result } catch (e) { if (transaction) await transaction.rollback() throw e } } } 

上記の例のように、デコレータを直接使用して構成できます。 構成の場合、現在使用可能なフラグは1つだけです-forceは、トランザクションを強制的に作成します-トランザクションが転送されない場合、それを作成します。 次のように使用する必要があります： @acceptsTransaction({force: true}) ...

注意してください-現在、this.connectionはトランザクションになっています。 関数が完了すると、プロパティは以前の状態に戻りますが、トランザクションを渡すことを心配せずにクラスの他のメソッドを呼び出すことができます。 この魔法はこれでのみ機能します（予測可能です）。

トランザクションは順番に処理されるため、つまり あるオブジェクトが完了するまで、別のオブジェクトが開始されるまで、オブジェクトは複製されないため、このデコレータで静的メソッドをラップすると、誤ってトランザクションが失敗する可能性があることに注意してください。 クラスインスタンスの場合、これは、JSを正しく操作する場合、そのスコープ内にあり、他の実行スレッド（promise、asyncなど）から同時にアクセスできないという事実のため、怖いことではありません。オブジェクトにアクセスできません。

それがユニット全体です

APIの説明と、APIがこの方法で実行された理由と、そうでない理由は完了です。

追加する価値のある唯一のことは、自分や友人のための小さなプロジェクトで既に使用していることです。 長い間、データベースを操作するとき、そのような喜びを感じていませんでした-Ruby / Railsで作業しているときだけ、作業メカニズムの「透明性」と理解可能性の感覚を感じました。

ユニットには機能や速度が不足している場合がありますが、これが必要な場合はプロジェクトに接続してください。 集計は、かなりよく組織化されたコードのわずか608行（ショック）であり、変更、追加、更新、および追加のテストを行うのは非常に簡単です。 大規模なプロダクションでの使用に特に適していることを確認したいと思います。もしそれが気に入ったら、開発に参加してください！