Laravelを使用してRESTfulアプリケーションを構築する従来の方法は何ですか？

Question

私はLaravelと（まだReactやVue.jsのような）おそらくわからないクライアントサイドのフレームワークを使って最初のRESTアプリケーションを構築します。

私は自分のアプリをどのように構築するべきかについていくつかの調査を行いましたが、残念ながら私はさらに混乱しました。

私は2通りの方法で私のアプリを構築することができるという結論に来ている：

• は、同じプロジェクトでアプリをビルドします。ただし、Laravel Bladeなし。
• 2つのプロジェクト（前と後）にアプリケーションを分けます。一方

---

、同じプロジェクトでアプリを構築するの長所：

• は私にLaravel Mixを使用するオプションを付与します。
• Laravelはすぐに購入できます。Vue support一方

、前方から後方に離れアプリを構築するの長所：

• 各側は、独自の単一責任を持っており、簡単にリファクタリングすることができます。
• 友人から聞いたように、それはもっと便利です（私にとってはあまりにも複雑すぎると思います）。

私は、Laravelがその一部であるときにRESTfulなアプリケーションを構築する最も一般的な方法が何であるか知りたかったのです。私が言及したことの別の方法がありますか？

Answer 1

個人的には、

私はそれらを分かりやすく保守しています。はい、2つの異なるプロジェクト/フォルダ/リポジトリを追跡する必要がありますが、それらは同じケーキの一部です。

LaravelでAPIを足場を立てることは非常に簡単で簡単です。私はあなたがすでにそれを行う方法を知っていると仮定します。あなたはLaravel Mixによって提供される利点を失うことについて心配していますが、私はあなたが何も失っていないと信じています。

あなたの設定は角度になっているので、すべての設定でシードプロジェクトリポジトリをクローンするだけです。例えば：
1. AngularJS：https://github.com/angular/angular-seed
2.角度2：https://github.com/mgechev/angular-seed

あなたが見ることができるように、これらの種のプロジェクトは、すでにあなたが必要となりました物事は簡単に実際に見えるすべてのビルドツールを持っています。これがフレームワークのために作られたものです。

ここで、後でモバイルアプリをスタックに追加するとします。一つのことを変更する必要はありません。 APIはすでにフロントエンドとは独立して実行されており、その逆もあります。

Answer 2

質問は意見に基づいています...だからここに私の反論があります。

TLDR：開発のスピードと間違いなく満足するためには、1つのプロジェクトとして構築してください。不必要に過度に過度に複雑化しないでください。プロジェクトが十分に大きくなり、お金を生み出したら、プロジェクトを分割することを考えてください。時間があると分かります。

Laravelエコシステムは、小規模、中規模、さらには大規模なアプリケーションにも最適です。

Laravelには、すべてのJavascript &フロントエンドアセットを入れることができるresourcesフォルダがあります。 Envoyには、アプリケーションの展開と展開スクリプトの記述があります。あなたは、あなたの資産を組み合わせるために混在しています。あなたはミックスを使用する必要はありません - あなたはあなた自身のgulp/webpack/gruntなどを書くことができます。

1つのプロジェクトとしてまとめておくと、フロントエンドとバックエンドの両方で同じIDEプロジェクトを使用できますすべてのバックエンドコードがフロントエンドコードから完全に分離されているため、懸念事項を分離してください。角度から送信されるペイロードを微調整し、PHP apiでペイロードがどのように処理されるかを微調整することができます。したがって、1 ideと1つのブラウザと端末クライアントのみが必要です。

あなたがVCS（git）を使用していると仮定し、あなたが本当にすべきであると仮定すると、フロントエンドとバックエンドは常に相互に同期します。それ以外の場合は、フロントエンドコードとバックエンドコードの配備を&で管理する必要があります。

アプリケーションが十分に大きくなると、フロントエンドとバックエンドがすでに非常に疎結合されているため、プロジェクトを分離するのに時間がかかりません。

アプリケーションに導入する複雑さを増したレイヤーをすべて考えてみてください。 REST APIに変更を展開するときは、角度アプリケーションに変更を展開する必要があります。角度アプリのどのバージョンがどのバージョンのAPIと互換性がありますか？特定のプロジェクトに取り組んでいる開発チームがあれば、この複雑さは相殺されます。しかし、ほとんどのチームは、管理のためのプロセスを持っており、&の導入を自動化します。

Answer 3

2つのプロジェクトに行ってください。私は...するだろう。

ここでは、複雑さの成長率を使用した例を示します。それは私自身の経験からです。 （Xはフィーチャの量を意味し、Yはどれほど複雑であるかを意味します）

最初は1つのプロジェクトで超シンプルです。サーバーとのコミュニケーションがなく、ハードなものではなく、すべてが絡み合っています。それで終わりに近づくと、すべてが絡まっているので、より多くの機能やページを作成するのが難しくなります。

しかし、あなたは、2つのプロジェクトを開始する場合は、必ず、それは最初は難しくなります（通信、同期何でも）が、複雑さの成長率の高さになりません。

または関数として

。すべてがそれ自身の責任であり、すべてがそれをする必要があります。テストが簡単で、拡張が簡単で、リファクタリングが簡単で、プロジェクトを簡単に完了できます。

または関数として：

明らかに、上記のグラフから、あなたは、単一のプロジェクトのための成長の速度が非常に遅いことを推測することができます。 （実際の数字ではなく、私は何も測定しなかったし、そのようなプロジェクトを追跡しなかった、これは自分自身の経験からちょうど外されている）