Laravel 5マルチアプリ
そのため、私の作業にはダッシュボードに組み込まれたcodeigniterがあり、ダッシュボード上のすべてのアプリにはコントローラー/モデル/ビューに独自のサブフォルダーがあり、何も共有されていません。これをLaravel 5にアップグレードする必要があります。この機会に「正しい方法」で実行したいと思います。
Laravel 5.でこれを行う方法に興味があります。自分自身を中間ユーザーLaravelユーザーと見なし、それぞれの方法を見つけたいと思いますアプリは何らかの方法で「分離」されますが、一般的なモデル/ビュー/構成なども共有します。
私は頭のてっぺんからいくつかハックな方法を考えることができますが、皆さんがどう思うかを見るのに興味がありました。何か案は？
概念的には、「システム」ごとに一元化されたAPIを持つことが理想的です（ただし、すべてのシステムで同じではありません）。
私はシステムという用語を使用していますが、これは単一のシステムに多数のアプリがある場合や、複数のシステムで動作するアプリがある場合があるためです。素敵な例は、WebAppとモバイルアプリケーションで、同じデータで機能する2つの異なる「アプリケーション」です。反対側には、会社のCRMを制御し、Webサイトの統計情報を表示するダッシュボードがあります。これは、基本的に1つのアプリケーションが2つの異なる「システム」と対話することです。
たとえば、同じデータベース上にWebサイトと販売データがあると、Webサイトを変更したい場合に大きな問題が発生する可能性があります。これは、販売データに問題が発生する可能性があり、システム管理者や、すべてのベテラン開発者というわけではありません。同じアプリケーションで2つのデータベースを使用すると、まったく新しい問題が処理されます。そしてそれは、想定される許可の問題や、「より機密性の高いデータ」に影響を与えるエクスプロイトやハッキングのリスクを、想定以上に考慮せずに行われています。
したがって、システムごとに個別のAPIを構築して、モデル、関係、動作を適切に分離し、十分に文書化して、効果的に機能させることをお勧めします。つまり、ビジネスロジックに質問や変更がある場合は、1か所で確認する必要があります。
それ以上に、「アプリ」ごとに個別のコードベースを用意しますが、それは個人的な意見です。
今の考え方は、APIからデータをプルする必要があるということです。APIを使用した後は、表示上の理由でのみフォーマットを行う必要があります。つまり、eコマースがあり、すべての製品の値の合計であるcart totalがある場合、この値はAPIからFLOATまたはDECIMALとして取得されます。 10進数は2桁のみであり、消費部分は値をフォーマットします（つまり、通貨などを追加します）。
これは、アプリの考えられるさまざまなバージョンを簡素化し、一貫性を確保するためです（cart totalは、同じAPIから取得されているため、一方のアプリでは間違いなく、もう一方のアプリでは間違いない場合があります）。
APIの主な理由は一貫性です。大きなコードベースは、メンテナンスとパフォーマンスの理由で悪いです。一方、コードベースが小さいと、コードが複製される可能性があり、システムの1つが動作を変更すると、一貫性の問題や奇妙なバグが発生する可能性があります。
また、この決定はフレームワークを決定する前に行われます。何を構築しようとしているのかを決定する前に特定のフレームワークまたは言語を選択すると、誤った決定をする大きなリスクが生じます。 APIの使用とプレゼンテーションの操作は、どのJavaScriptフロントエンドフレームワークからでもLaravelよりも簡単になります。 Rails（はるかに優れたモデル））またはNode（シンプルさとパフォーマンス、使用しないものを少なくする）は、LaravelよりもAPIの提供がおそらくはるかに簡単です。また、何らかの理由（NoSQLやPostgresなど）で別のデータベースを使用することを検討する場合、オプションを検討する前にフレームワークを選択することは、取引を妨げる可能性があります。
これらの決定はすべて、互いに考慮しなければなりません。快適に作業できる最も有利なオプションが必要です。週末のプロジェクトでは通常、「何でも」を意味しますが、数か月または数年続くプロジェクトでは、異なる言語またはフレームワークを選択すると、ビルドするものの速度と品質に大きな影響を与える可能性があります。これが理由です。そのような困難で重要な決定であること。