ウェブサービスの開発では、様々な作業をフロントエンドとバックエンドに分けることができる。大雑把にまとめると、フロントエンド開発とは、主にユーザーインターフェイスを扱うすべての作業を指します。フロントエンドはバックエンドと通信し、バックエンドは永続的なデータを意味のある効率的な方法で管理し、すべての消費者が利用できるようにする責任を負います。ウェブ開発において、フロントエンドとバックエンドの境界は、このようにブラウザとサーバーの間にあります。この記事では、フロントエンド開発とバックエンド開発の類似点と相違点について説明します。
どのようなタイプの開発であっても、一般的には以下のような条件から恩恵を受ける:
例えば、JavaScriptを使ってウェブ・アプリケーションを開発する場合、次のようなツールが技術的なサポートを提供してくれるだろう:
リンターやテストフレームワークは、ほとんどのプログラミング言語に存在しますが、フロントエンドでのテスト開発には、しばしばさらなる障害が伴います。何をもって「直感的に使える」インターフェースとするかは、非常に主観的な評価である。これに加えて、どのブラウザを、どのバージョンで、どのオペレーティング・システムで、どのディスプレイ・サイズのデバイスで使用するかという問題が加わる。Playwrightのようなツールは、異なるブラウザで自動的にテストを実行することで、非常に役立ちます。
アクセシビリティというトピックも注目されるようになり、開発に新たな課題とルールをもたらしている。ここでは、自動テストは部分的にしか不可能であり、理想的には人が定期的に手動テストを行うことである。
バックエンドのテスト開発が一般的に簡単で、要求が少ないと言いたいわけではない。むしろ、並列リクエストのコンフリクトのない効率的な処理のような、別の問題がここに絡んでくる。しかし、さまざまなシナリオを再現し、それらを自動的にテストすることは、一般的に容易である。
また、バックエンドが無効な入力を単に拒否することが許されていることにも注意する必要がある。プログラムが期待されているのは、入力のどの部分が無効とみなされたかを明示することだけである。(例えば、訪問者はボタンXを押したはずだ)。フロントエンドは、潜在的に経験の浅い訪問者とバックエンドの間を仲介する必要があります。最良のシナリオでは、もちろん、バックエンドは成功したリクエストだけを受け取りますが、この成功の功績は主にフロントエンドにあり、フロントエンドは優れたユーザーエクスペリエンス(UX)によってそれを可能にします。
予期せぬエラーが発生した場合、ほとんどの場合、バックエンドでそれを追跡する方が簡単である。通常、外部環境(ハードウェア、オペレーティング・システム、…)はすぐに記録できるか、すでに知られている。
最後の手段として、開発者はシステムと直接対話することができます。バックエンドデータベースの無効なエントリは、手動で削除することができます。しかし、もし訪問者のフロントエンド(ブラウザ)のストレージに問題がある場合、開発者が直接アクセスすることはほとんど不可能であり、例えばデフォルト値にフォールバックするなど、他の方法で問題を解決しなければならないことがよくあります。したがって、フロントエンドは、ローカル設定をリセットするボタンのような、修正不可能な状態に対するいくつかのオプションを提供するべきです。
フロントエンドとバックエンドの開発におけるもう一つの一般的な違いは、開発者チームそのものである。作業を分けるのは個人的な好みによるものかもしれないが、ブラウザとサーバーの境界がはっきりしているおかげで、開発作業の分担は極めて適切である。この原則は、コンピュータの分野では一般にコンウェイの法則と呼ばれている。従って、異なるチーム間のコミュニケーションは、フロントエンドとバックエンド製品間の正確で効率的なやり取りを保証するための基本です。
技術的なレベルでは、OpenAPI仕様がコミュニケーションの良いガイドとなる。Swagger UIやOpenAPI-diffのような、仕様に基づいて構築されたプロジェクトは、優れたドキュメンテーションのための構造を提供することができる。
要約すると、フロントエンドとバックエンドの開発は、それぞれの専門化が可能であるか、あるいは必要でさえあるほど、十分な領域で異なっている。しかし、効率的に作業するための基本的な推奨事項やアプローチは、ほとんど同じままです。この原則は、システムの実際のハードウェアとのより密接なデータのやりとりを伴うシステム・プログラミングのような、他の開発カテゴリーにも当てはまります。
Web 開発の基礎についてもっと学びたい方は、LPI の新しい Web Development Essentials 試験をご覧ください。