タグ付けされた質問 「backend」

2
フルスタックJavaScriptでフロントエンドとバックエンドを分離する方法は?
私がフロントエンドを持っていると仮定します。フロントエンドは、ほとんどが角ばった、うなり声、お辞儀を使って書かれた単一ページのアプリケーションです。そして、私がバックエンドを持っていると仮定します。ほとんどの場合、ORMの上に置かれたREST APIであり、データベースからオブジェクトを保存/取得し、うなり声、エクスプレス、シークライズなどを使用します。 角度のあるアプリケーションは、ユーザーに表示されるすべての視覚的な処理を行いますが、バックエンドによって提供されるサービスを介したGUIとして機能します。 これらを2つの異なるコードベースに分離し、独立した開発、バージョン管理、継続的統合、開発へのプッシュなどを可能にすることが望ましいでしょう。 私の質問は、これをきれいに行うための方法は何ですか?フルスタックJavaScriptの推奨ベストプラクティスはありますか? オプション#1はモノリス、つまり「それらを分離しない」ようです。利点は、ビルドチェーンがシンプルであり、すべてが1か所にあることですが、多くの欠点があるようです。個別にバージョン管理するのが難しく、前面が壊れていると、展開できない背面を意味します。 オプション#2は準モノリスのようです。フロントエンドビルドチェーンにより、多数のファイルがバックエンドに書き込まれます。distフロントエンド上のディレクトリをするとき、フロントエンドminifies、uglifiesなどので、基本的に、バックエンドには、いくつかのディレクトリを参照することになり、それがすべてを実行し、バックエンドに公開してしまいます。 オプション#3は完全に分離されているようです。フロントエンドとバックエンドはそれぞれ異なるポートで独自のサーバーを実行し、完全に独立したプロジェクトです。欠点は、互いのポートについて知るように設定する必要があるようです。バックエンドは、フロントエンドからのCORSを許可する必要があり、フロントエンドは、それらのすべてのエンドポイントが予想される場所を知る必要があります。 オプション#4は、docker-composeなどを使用して、すべてをまとめてリグすることです。 私は他のオプションがあると確信しています。推奨されるベストプラクティスは何ですか?

3
バックエンドとフロントエンドのWebアプリケーションを完全に分離し、それらが(JSON)REST APIと通信できるようにするのは通常の設計ですか?
私は新しいビジネスWebアプリケーションを作成しています。 それぞれの領域から最高の技術を使用します。堅牢なORMを備えた信頼性の高いバックエンドフレームワークが必要です。そして、フロントエンドアプリケーションの最新のHTMLおよびJavascript機能を使用した、最も高度なSPA(単一ページアプリケーション)フレームワークが必要です。 さまざまなタイプのアプリケーション(たとえば、Webアプリケーション、モバイル(Android)、および場合によっては他のタイプ(スマートデバイスなど))から使用するバックエンドエンティティとビジネスサービスを公開します。 したがって、両方の要件を満たすために、バックエンドアプリケーションとフロントエンドアプリケーションでアプリケーションを完全に分離し、REST API(JSON)を使用してそれらの間の通信を整理する傾向があります。これは健全なアプローチですか? 多くのWebアプリケーションテクノロジーには、サーバーサイドアプリケーションがビューの生成を多少制御し、ビューからの応答を部分的に処理するビューレイヤーが統合されているため、このような分離は明白な設計ソリューションではありません(たとえば、ビューレイヤーを持つSpringMVC、ビューを持つPHP Yii Java JSF / Faceletsは、サーバー上のコンポーネントの状態を完全に保存します)。そのため、より強力な結合を提案し、開発時間の短縮とより標準的な道のりを約束する多くの技術があります。だから-広く使われていない方法で技術を使い始めるとき、私は注意しなければなりません。 私が理解したように、完全に分離されたSPAフロントエンドは通常、サードパーティAPIを使用する必要性から生じます。しかし、バックエンドとフロントエンドの両方が1つの会社によって開発されたとき、そのようなデカップリングサウンドデザインはありますか? 私が現在選択しているテクノロジーは、Java / Springバックエンドとフロントエンド用のAngular2 / Web Components / Polymerです。この質問は一般的な設計に関するものであり、具体的な技術の選択に関するものではないため、それはこの質問とは無関係です。

4
「フロントエンド」という用語は「クライアント側」と同義ですか?もしそうなら、これは常にそうですか?
比較的新しい(独学)Web開発者として、フロントエンド、クライアントサイド、バックエンド、サーバーサイドという用語をよく耳にします。私にとって、フロントエンドとバックエンドは、それぞれクライアント側とサーバー側の同義語でした。 ただし、CodeIgniterのようなMVCフレームワークで作業を開始すると、基本的にエンドユーザーが参照するもの(サーバー側コードを含む)を参照するフロントエンドのインスタンスに遭遇しました。エンドユーザーには表示されません(CMSを含む)。私にとって、クライアント側とサーバー側の意味ははるかに具体的です。それらは非常に明確な線で区切られています。一方、フロントエンドとバックエンドはそうではありません。 他のWeb開発者との会話の中で、彼はCodeIgniter(全体)をフロントエンドと呼んでいましたが、これがループを引き起こしました。私は彼を修正してCodeIgniterが私のバックエンドであると言うのか、それとも2つの用語の定義が完全に間違っているのかを確信できませんでした。 フロントエンドとバックエンドの定義を検索すると、いくつかの点で少し混乱しましたが、いくつかの点が明確になりました。これら4つの用語の間に線が引かれている場所と、Web開発のコンテキスト(具体的にはLAMPスタック)でそれらがどのように結び付いているかを知りたいだけです。

2
バックエンド開発者として、ソフトウェアテストを学ぶ必要がありますか?[閉まっている]
閉じた。この質問はより集中する必要があります。現在、回答を受け付けていません。 この質問を改善したいですか?この投稿を編集するだけで1つの問題に焦点を当てるように質問を更新します。 5年前に閉鎖されました。 ジュニア開発者として、航空業界向けのソフトウェアを開発する会社で働いています。テストチームがあるので、テストソフトウェアを学ぶ意欲はありません。私の友人は、小さな会社でバックエンド開発者として働いています。チームには特定のテストチームはなく、自分でテストを行います。バックエンド開発者はソフトウェアのテストについて学ぶ必要がありますか?
12 testing  backend 

2
サーバーレスアーキテクチャはどのようにデータベース接続を管理しますか?
サーバーレスアーキテクチャの主な利点は、そのようなプログラムが継続的に実行するために専用サーバーを必要としないことです。次に、要求時に呼び出され、関数の終了時に停止します。 つまり、レスポンシブであるためには、サーバーレスプログラムをすばやく起動する必要があります。次に、データベース接続などの時間のかかるアクションをどのように処理しますか?それは毎回データベースに接続しますか、それともサーバー接続で行われるような関数呼び出しのためにデータベース接続を個別に管理しますか?

3
REST API承認戦略
ここでは、RESTful APIの認証と承認のメカニズムを扱う多くの質問がありますが、アプリケーションレベルで安全なサービスを実装する方法の詳細については触れていません。 たとえば、私のWebアプリケーション(Javaを念頭に置いていますが、これは実際にはすべてのバックエンドに当てはまります)に、APIのユーザーがユーザー名とパスワードでログインできる安全な認証システムがあるとします。ユーザーがリクエストを行うと、リクエスト処理パイプラインの任意の時点でgetAuthenticatedUser()、ユーザーがログインしていない場合はnullユーザー、またはログインしているユーザーを表すユーザードメインオブジェクトを返すメソッドを呼び出すことができます。 APIにより、認証されたユーザーはデータにアクセスできます。たとえば、GET /api/orders/はそのユーザーの注文リストを返します。同様に、GET to /api/tasks/{task_id}はその特定のタスクに関連するデータを返します。 ユーザーのアカウントに関連付けることができるいくつかの異なるドメインオブジェクトがあると仮定します(注文とタスクは2つの例であり、顧客、請求書などもある可能性があります)。認証されたユーザーだけが自分のオブジェクトに関するデータにアクセスできるようにしたいので、ユーザーがを呼び出すときは、ユーザーが/api/invoices/{invoice_id}そのリソースにアクセスすることを許可されていることを確認してから、サービスを提供します。 私の質問は、この承認の問題に対処するためのパターンや戦略は存在するのでしょうか。私が検討しているオプションの1つは、ヘルパーインターフェイス(つまりSecurityUtils.isUserAuthorized(user, object))を作成することです。これは、リクエストの処理中に呼び出して、ユーザーがオブジェクトをフェッチすることを許可されていることを確認できます。これは、これらの呼び出しの多くでアプリケーションのエンドポイントコードを汚染するため、理想的ではありません。 Object someEndpoint(int objectId) { if (!SecurityUtils.isUserAuthorized(loggedInUser, objectDAO.get(objectId)) { throw new UnauthorizedException(); } ... } ...そして、少し面倒かもしれませんが、すべてのドメインタイプにこのメソッドを実装するという問題があります。これが唯一のオプションかもしれませんが、私はあなたの提案を聞いて興味があります!
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.