Quelques options que j'ai déjà utilisé:

utilisez Laravel pour rendre la vue" main view " + connect vue.js application.

en gros, laravel va rendre l'application Vue et chaque requête passe par une API.

1. Facile à installer
2. authentification + validation de l'utilisateur est plus facile (vous pouvez utiliser le gestionnaire de session laravel pour cela - vous n'avez pas besoin de construire/utiliser des tokens ou n'importe quoi d'autre. "Pas besoin de vous soucier de votre état d'application".)
3. Facile pour "déconnecter" de Laravel - si vous choisissez à l'avenir de découpler l'application SPA.

utiliser laravel (ou lumen) uniquement comme API, et sur un autre serveur, rendre un SPA.

cela peut prendre plus de temps, puisque vous aurez besoin de configurer un serveur supplémentaire, préparer cross-origin, etc.

1. Aussi facile à configurer, mais peut prendre plus de temps que l'option #1
2. Vous aurez besoin de créer quelque chose pour la validation de l'utilisateur/gestion de l'état, etc.
3. Facile à placer dans laravel, si vous décider à l'avenir d'utiliser "une seule application".
4. peut être plus facile à maintenir/échelle (si vous avez une équipe frontale, ils n'ont pas besoin de se soucier de laravel-même chose pour votre "équipe laravel", ils "n'auront pas besoin de se soucier" de la frontale)

Laravel + Vue = "une application"

vous pouvez utiliser Laravel pour rendre toutes les vues + vuejs pour les composants/éléments dans la page.

1. Facile à installer. Vous avez laravel + vuejs, et ils sont déjà prêts à être utilisés ensemble. https://laravel.com/docs/5.5/frontend#writing-vue-components
2. pas si facile à découpler. Dans ce cas, vous devrez créer les mêmes vues pour vue.js. Cela peut prendre du temps.
3. il s'agit du" développement web traditionnel " (à mon avis). Si je devais démarrer un projet comme celui-ci aujourd'hui, je ne créerais pas toutes les pages en Vue.js + something dans Laravel (contrôleur + nouvelle route) pour rendre ce point de vue. Si vous faites cela (encore - mon avis), c'est juste du travail supplémentaire. Si vous êtes inquiet au sujet de SEO, il y a des "retombées"/options supplémentaires.

--

toutes les options sont testables + évolutives.

Cela dépend aussi de la façon dont vous commencez ( dois-je m'inquiéter de la façon dont je vais découpler l'application dans le futur? Laravel + Vue sera pour de bon?), le fonctionnement de votre équipe ( est-ce que l'équipe frontend a vraiment besoin de mettre en place laravel ou ils ont seulement besoin de l'inquiétude à propos de la gestion de l'interface?), etc.

Je ne sais pas si j'ai répondu à votre question, sinon, veuillez laisser un commentaire.

vous n'avez rien trouvé de clair parce qu'il n'y a rien d'autre à dire que " ce qui semble juste pour votre compréhension et les besoins du projet'. Si vous avez trouvé vous-même très incertain, n'hésitez pas à vous lancer dans tout ce qui a du sens pour vous et ensuite réajuster la structure lorsque vous gagnez plus d'expérience.

aussi, lire des livres sur l'architecture du système, cela aidera beaucoup.

---

Est-ce un bonne idée d'utiliser juste laravel comme une API de données, et garder Vue séparée de Laravel?

par là, je suppose que vous voulez dire un SPA? Honnêtement, si votre candidature est petite, alors je vois que c'est très bien.

les applications plus grandes ont tendance à être difficiles à maintenir si elles étaient SPA.

Lire: https://medium.com/@NeotericEU/single-page-application-vs-multiple-page-application-2591588efe58

si vous finissez par utiliser Laravel comme API d'extrémité, puis utilisez la version dépouillée, Lumière, parce qu'il vient sans lame et quelques autres choses. Lumen est dépouillé version vers le bas pour agir comme un API-endpoint.

---

meilleure approche pour la mise en oeuvre de l'hybride des ZPS et des ZPM.

D'après mon expérience ayant tenté de construire 4 + projets en tant qu'hybrides, voici ce que j'ai trouvé la structure la plus optimale:

mon exemple portera sur une application qui enregistre les Messages.

1. Utilisez un modèle de conception de dépôt.

celui-ci vous évitera beaucoup de maux de tête en maintenant votre code et en maintenant un concept sec (Ne vous répétez pas) sur votre code.

• Créer un répertoire App\Repositories\

Faire une nouvelle classe PostsRepository. Ce sera en communication avec la base de données et contient la plupart de la logique.

• Créer le répertoire App\Services\

Faire une nouvelle classe PostsService. Celui-ci aura le PostsRepository dans son constructeur.

la classe service sera celle qui manipule les entrées de l'utilisateur, qu'elles proviennent du contrôleur Web ou du contrôleur API.

<?php

namespace App\Service;

use App\Repositories\PostsRepository;

class PostsService;
{
    protected $repository;

    public function __construct(PostsRepository $repository)
    {
        $this->repository = $repository;
    }
}

• faire une séparation entre les contrôleurs Web et API.

pour les controllers web, vous créez le controller comme d'habitude:

php artisan make:controller PostsController

pour les controllers API, vous créer le contrôleur à l'intérieur d'un dossier Api.

php artisan make:controller Api\PostsController

la dernière commande va créer le répertoire App\Http \ Controllers\Api et y placer le controller.

Rechapage

maintenant nous avons différents contrôleurs pour retourner les résultats appropriés au point de départ (Web / api).

nous avons des services que les deux contrôleurs (Web / api) envoient leurs données pour être validées (et ont l'action prises par le référentiel).

Exemples:

<?php

namespace App\Http\Controllers;

use App\Service\PostsService;

class PostsController extends Controller
{
  protected $service;

  public function __construct(PostsService $service)
  {
      $this->service = $service;
  }

  public function index()
  {
     /**
     * Instead of returning a Blade view and
     * sending the data to it like:
     *
     *          $posts = $this->service->all();
     *          return views('posts.index', compact('posts'));
     *
     * We go ahead and just return the boilerplate of 
     * our posts page (Blade).
     */
     return view('posts.index');
  }
}

...

<?php

namespace App\Http\Controllers\Api;

use App\Service\PostsService;

class PostsController extends Controller
{
  protected $service;

  public function __construct(PostsService $service)
  {
      $this->service = $service;
  }

  /**
  * Returns all posts.
  *
  * A vue component calls this action via a route.
  */
  public function index()
  {
     $posts = $this->service->all();

     return $posts;
  }

  /**
  * Notice we don't have a store() in our
  * Web controller.
  */
  public function store()
  {
     return $this->service->store();
  }
}

...

<?php

namespace App\Services;

use App\Repositories\PostsRepository;

class PostsService extends Controller
{
  protected $repository;

  public function __construct(PostsRepository $repository)
  {
      $this->repository = $repository;
  }

  public function all()
  {
     $posts = $this->repository->all();

     return $posts;
  }

  public function store()
  {
     $request = request()->except('_token');

     $this->validation($request)->validate();

     return $this->repository->store($request);
  }

  public function validation(array $data)
  {
      return Validator::make($data, [
          'content' => 'required|string|max:255',
          //
      ]);
  }
}

dans notre PostsRepository nous appelons en fait des méthodes qui sauvegardent les données. E. g. Post::insert($request);.

2. Dédier un groupe API

Route::prefix('api/v1')->middleware('auth')->group(function() {

    Route::post('posts/store', 'Api\PostsController@store')->name('api.posts.store');

});

Donner de l'API itinéraires ->name() aide quand vous faites des tests phpunit.

3. Lame de vues

Ceux qui doivent être allégée simple.

views/posts/index.blade.php:

@extends('layouts.app', ['title' => trans('words.posts')])

@section('content')
  <!-- Your usual grid columns and stuff -->
  <div class="columns">
     <div class="column is-6">
         <!-- This comp. can have a modal included. -->
         <new-post-button></new-post-button>
     <div class="column is-6">
          <posts-index-page></posts-index-page>
     </div>
  </div>
@endsection

4. Vue de la structure.

https://github.com/pablohpsilva/vuejs-component-style-guide

donc ces composantes de L'Evi pourraient vivre dans resources/assets/js/components/posts/ à l'intérieur /posts/ j'aurais des dossiers titrés par exemple IndexPage,CreateModal,EditModal chaque dossier ayant son .vue et README.md.

j'utiliserais <posts-index-page>index.blade.php et de les déposer dans le <post-create-modal> et <edit-post-modal> chaque fois que Je veux.

tous les composants d'Evi utiliseront le paramètre API que nous avons spécifié dans notre fichier Routes.