相互理解を維持しながらフロントエンドとバックエンドを分離する方法

モノリシック製品のアーキテクチャを変更して開発を加速する方法、および作業の一貫性を維持しながら1つのチームを複数に分割する方法 私たちにとって、これらの質問に対する答えは、新しいAPIの作成でした。 カットの下に、そのようなソリューションへの道についての詳細なストーリーと選択されたテクノロジーの概要がありますが、最初は小さな余談です。

数年前、科学的な記事で、本格的なトレーニングにはますます時間が必要であり、近い将来、知識を得るには80年かかると読みました。 どうやら、ITのこの未来はすでに来ています。

「プロトタイプ」、「製品エンジニア」、「UX」、「QA」という言葉が聞こえなかったバックエンドとフロントエンドのプログラマーに分かれていなかった時代に、私は幸運にもプログラミングを始めました。 世界はよりシンプルで、木々はより高く、より緑で、空気はきれいで、子供たちは駐車場の代わりに庭で遊んでいました。 その時にどのように戻りたいとしても、これはスーパーヴィランの計画ではなく、社会の進化的発展であることを認めなければなりません。 はい、社会は違った形で発展する可能性がありますが、ご存知のように、歴史は仮定法の気分を許容しません。

背景

BILLmanagerは、厳密な方向の分離がなかったときに登場しました。 一貫性のあるアーキテクチャを持ち、ユーザーの動作を制御でき、プラグインで拡張することさえできました。 時間が経ち、チームが製品を開発し、すべてがうまくいくように見えましたが、奇妙な現象が観察され始めました。 たとえば、プログラマーがビジネスロジックに携わっていると、フォームの作成が不十分になり、フォームが不便で理解しにくくなりました。 または、一見シンプルな機能を追加するのに数週間かかりました。アーキテクチャ上、モジュールは緊密に結合されていたため、一方を変更する場合、他方を調整する必要がありました。

アプリケーションが未知のエラーでクラッシュした場合、一般的な製品の利便性、人間工学、およびグローバルな開発は忘れられる可能性があります。 以前にプログラマがさまざまな方向で作業を行うことができた場合、製品とその要件の成長により、これは不可能になりました。 開発者は全体像を見て、機能が正しく安定して機能しない場合、金型、ボタン、テスト、およびプロモーションが役に立たないことを理解しました。 したがって、彼はすべてを延期し、不運な間違いを修正するために座った。 彼は少しの偉業を成し遂げましたが、それは誰にも評価されずに残っていました（クライアントへの適切な供給のための単なる強さはありませんでした）が、機能は働き始めました。 実際、これらの小さな偉業を顧客に届けるためには、チームはさまざまな分野（フロントエンドとバックエンド、テスト、設計、サポート、プロモーション）の責任者を含める必要があります。

しかし、それは最初の一歩に過ぎませんでした。 チームは変更され、製品のアーキテクチャは技術的に緊密に結合されたままです。 このため、必要なペースでアプリケーションを開発することはできませんでした;インターフェイス自体を変更する場合、データ自体の構造は変更されないことが多いものの、バックエンドロジックを変更する必要がありました。 これらすべてで何かをしなければなりませんでした。

フロントエンドとバックエンド

すべての分野でプロフェッショナルになるには時間がかかり、高価です。そのため、応用プログラマの現代世界は、大部分がフロントエンドとバックエンドに分かれています。

ここではすべてが明らかなようです。フロントエンドのプログラマーを募集しており、ユーザーインターフェイスを担当します。バックエンドは最終的にビジネスロジック、データモデル、その他のエンジンフードに集中できるようになります。 同時に、バックエンド、フロントエンド、テスター、およびデザイナーは1つのチームにとどまります（共通の製品を作成するため、異なる部分に焦点を合わせます）。 1つのチームに所属するということは、1つの情報スペース、そしてできれば領土スペースがあることを意味します。 新しい機能について一緒に話し合い、完成した機能を分解します。 大きなタスクの作業を調整します。

いくつかの抽象的な新しいプロジェクトではこれで十分ですが、すでにアプリケーションを作成しており、計画された作業の量とその実装のタイミングから、1つのチームではできないことが明確に示されました。 バスケットボールチームには5人、サッカーチームには11人、約30人でした。これは、5〜9人の完璧なスクラムチームには合いませんでした。 分割する必要がありましたが、一貫性を維持する方法は？ 前進するには、アーキテクチャおよび組織の問題を解決する必要がありました。

「すべてを1つのプロジェクトで行うので、より便利になります」と彼らは言いました...

建築

製品が古くなった場合、それを放棄して新しい製品を作成するのは理にかなっています。 これは、時間を予測でき、すべての人に適している場合に適切な決定です。 しかし、私たちの場合、理想的な条件下であっても、新製品の開発には何年もかかります。 さらに、アプリケーションの仕様は、古いものから新しいものに完全に変更することは非常に困難です。 下位互換性はお客様にとって非常に重要であり、存在しない場合、新しいバージョンへのアップグレードを拒否します。 この場合、ゼロから開発する可能性は疑わしいです。 したがって、最大の下位互換性を維持しながら、既存の製品のアーキテクチャをアップグレードすることにしました。

私たちのアプリケーションはモノリスであり、そのインターフェースはサーバー側で構築されました。 フロントエンドは、受信した命令のみを実装しました。 つまり、フロントエンドはユーザーインターフェースを担当しましたが、バックエンドは担当しました。 アーキテクチャ的には、フロントエンドとバックエンドが1つとして機能したため、1つを変更すると、別の変更を余儀なくされました。 そして、これは最悪ではなく、さらに悪いことです。サーバーで何が起こっているのかを深く知ることなくユーザーインターフェイスを開発することは不可能でした。

フロントエンドとバックエンドを分離し、別々のソフトウェアアプリケーションを作成する必要がありました。それらの開発を開始する唯一の方法は、必要なペースと量でした。 しかし、2つのプロジェクトを並行して実行し、それらが互いに非常に依存している場合、それらの構造を変更する方法は？

解決策は追加のシステム、 つまりレイヤーでした。 中間層の概念は非常に単純です。バックエンドとフロントエンドの作業を調整し、すべての追加費用を負担する必要があります。 たとえば、支払い機能がバックエンド側で分解されると、レイヤーはデータを結合し、フロントエンド側では何も変更する必要はありません。 または、ユーザーが注文したすべてのサービスのダッシュボードに結論を出すために、バックエンドで追加の機能を実行せずに、レイヤー内のデータを集約します。

これに加えて、レイヤーはサーバーから呼び出すことができ、最終的に返されるものに確実性を追加することでした。 操作を実行する機能の内部構造を知らなくても、操作の要求を可能にしたかったのです。

責任範囲を分割することにより安定性が向上しました。

コミュニケーションズ

フロントエンドとバックエンドの間には強い依存関係があるため、並行して作業を行うことは不可能であり、チームの両方の部分の速度が低下しました。 1つの大きなプロジェクトをプログラムで複数に分割し、それぞれで行動の自由を得ましたが、同時に作業の一貫性を維持する必要がありました。

誰かがソフトスキルを向上させることで一貫性が達成されると言うでしょう。 はい、開発する必要がありますが、これは万能薬ではありません。 交通状況を見てください。ドライバーが礼儀正しく、ランダムな障害物を避け、困難な状況で互いに助け合う方法を知っていることも重要です。 しかし！ 交通ルールがなければ、たとえ最高のコミュニケーションがあったとしても、すべての交差点で事故が発生し、時間通りにその場所に到着しないリスクがあります。

破ることが難しいルールが必要でした。 彼らが言うように、違反するよりも遵守することを容易にするため。 しかし、法律の実施には利点だけでなくオーバーヘッドも伴うため、メインの作業を遅らせて、全員をプロセスに引き込みたくありませんでした。 そのため、製品のさまざまな部分を適切に開発するための条件を作成することを目標とした調整グループを作成し、次にチームを作成しました。 彼女は、さまざまなプロジェクトが全体として機能するインターフェイスを設定しました。これは、破るよりも従うのが簡単なルールそのものです。

このコマンドを「API」と呼びますが、新しいAPIの技術的な実装はタスクのほんの一部です。 コードの共通セクションは個別の機能に配置されるため、APIチームは製品チームの一般的な問題を解析します。 ここでフロントエンドとバックエンドの接続が行われるため、このチームのメンバーは各方向の詳細を理解する必要があります。

「API」はチームにとって最良の名前ではないかもしれません。アーキテクチャや大規模なビジョンについての何かがより適しているでしょうが、この些細なことは本質を変えるものではないと思います。

API

サーバー上の関数アクセスインターフェイスは最初のアプリケーションに存在していましたが、消費者には無秩序に見えました。 フロントエンドとバックエンドの分離には、より確実性が必要でした。

新しいAPIの目標は、新製品や設計のアイデアを実装する際の日々の困難から生まれました。 必要なもの：

1. システムコンポーネントの接続性が弱いため、バックエンドとフロントエンドを並行して開発できます。
2. 新しいAPIが機能の構築に干渉しないようにするための高いスケーラビリティ。
3. 安定性と一貫性。

APIのソリューションの検索は、通常受け入れられているように、バックエンドからは始まりませんでしたが、反対に、ユーザーが必要とするものを考えました。

最も一般的なのは、すべての種類のREST APIです。 近年、記述モデルがswaggerなどのツールを介して追加されていますが、これは同じRESTであることを理解する必要があります。 そして実際、その主なプラスとマイナスは同時にルールであり、それらは排他的に記述的です。 つまり、個々のパーツを実装するときに、そのようなAPIの作成者がRESTの想定から逸脱することを禁止する人はいません。

もう1つの一般的なソリューションはGraphQLです。 また、完全ではありませんが、RESTとは異なり、GraphQL APIは単なる記述モデルではなく、実際のルールです。

前に、フロントエンドとバックエンドの作業を調整するシステムについて説明しました。 中間層はまさにその中間レベルです。 サーバーを操作するための可能なオプションを検討したので、フロントエンドのAPIとしてGraphQLに決めました 。 しかし、バックエンドはC ++で記述されているため、GraphQLサーバーの実装は重要なタスクであることが判明しました。 私はそれらを克服するために行ったすべての困難とトリックを説明しませんが、それは本当の結果をもたらしませんでした。 反対側から問題を見て、シンプルさが成功の鍵であると判断しました。 そのため、実証済みのソリューションであるExpress.jsとApollo Serverを備えた別のNode.jsサーバーに決めました。

次に、バックエンドAPIにアクセスする方法を決定する必要がありました。 最初にREST APIを上げる方向に目を向け、次にC ++でNode.jsのアドオンを使用しようとしました。 その結果、これらすべてが私たちに合わないことを認識し、バックエンドの詳細な分析の後、 gRPCサービスに基づくAPIを選択しました 。

C ++、TypeScript、GraphQL、およびgRPCを使用して得られた経験を集めて、単一のソフトウェア製品の作成を継続しながら、バックエンドとフロントエンドの柔軟な開発を可能にするアプリケーションアーキテクチャを得ました。

その結果、フロントエンドがGraphQLクエリを使用して中間サーバーと通信するスキームが求められます（何を尋ね、何を返すのかを知っています）。 リゾルバーのgraphQLサーバーは、gRPCサーバーのAPI関数を呼び出し、このために通信にProtobufスキームを使用します。 gRPCベースのAPIサーバーは、受信した要求の送信元または送信先のマイクロサービスを認識しています。 マイクロサービス自体もgRPC上に構築されているため、リクエストの処理速度、データの入力、および開発にさまざまなプログラミング言語を使用する能力が保証されます。

アーキテクチャの変更後の一般的な作業スキーム

このアプローチには多くのマイナス面があり、その主なものは、回路のセットアップと調整、および補助関数の作成という追加作業です。 しかし、これらのコストは、APIユーザーが増えると報われます。

結果

製品とチームを開発するという進化の道を歩んできました。 成功したか、ベンチャーが失敗に変わったのか、判断するのはおそらく早いでしょうが、中間結果は要約できます。 私たちが今持っているもの：

1. フロントエンドは表示を担当し、バックエンドはデータを担当します。
2. フロントエンドでは、データのクエリと受信に関して柔軟性が残っていました。 インターフェースは、サーバーに何を尋ねることができ、どのような答えが必要かを知っています。
3. バックエンドには、ユーザーインターフェイスが引き続き機能することを確信してコードを変更する機会があります。 フロントエンド全体をやり直すことなく、マイクロサービスアーキテクチャに切り替えることが可能になりました。
4. バックエンドの準備がまだ整っていないときに、フロントエンドのモックデータを使用できるようになりました。
5. コラボレーションスキームの作成により、チームが同じタスクを異なる方法で理解した場合の相互作用の問題がなくなりました。 データ形式のやり直しの反復回数が削減されました。「7回測定、1回カット」という原則に基づいて行動します。
6. これで、スプリント作業を並行して計画できます。
7. 個々のマイクロサービスを実装するために、C ++に詳しくない開発者を募集できるようになりました。

このすべてから、私は意識的にチームとプロジェクトを開発する機会を主な成果と呼びます。 各参加者がより意図的に能力を向上させ、注意を散らすことなくタスクに集中できる条件を作成できたと思います。 誰もが自分のサイトでのみ作業する必要があり、今では高い関与と絶え間ない切り替えが可能です。 すべてにおいて専門家になることは不可能ですが、今では私たちにとって必要ではありません 。

この記事は概要であり、非常に一般的であることが判明しました。 彼女の目標は、製品開発を継続するために技術的な観点からアーキテクチャを変更する方法に関するトピックに関する複雑な研究​​の経路と結果を示し、チームを合意された部分に分割する組織的な困難を示すことでした。

ここでは、1つの製品のチームおよびチーム作業の問題、テクノロジーAPIの選択（RESTとGraphQL）、Node.jsアプリケーションとC ++の関係などについて表面的に触れました。それらを書きます。