Bonnes Pratiques Web & Cloud

PRPL is a pattern for structuring and serving web applications and Progressive Web Apps (PWAs) with an emphasis on improved app delivery and launch performance. The letters describe a set of ordered steps for fast, reliable, efficient loading:

• Push all resources required for the initial route – and only those resources – to ensure that they are available as early as possible
• Render the initial route and make it interactive before loading any additional resources
• Pre-cache resources for additional routes that the user is likely to visit, maximizing responsiveness to subsequent requests and resilience under poor network conditions
• Lazy-load routes on demand as the user requests them; resources for key routes should load instantly from the cache, whereas less commonly used resources can be fetched from the network upon request

Beyond targeting the fundamental goals and standards of PWAs, PRPL strives to optimize for:

• Minimum time-to-interactive
  • Especially on first use (regardless of entry point)
  • Especially on real-world mobile devices
• Maximum caching efficiency, especially over time as updates are released
• Simplicity of development and deployment

PRPL is inspired by a suite of modern web platform features, but it’s possible to apply the pattern without hitting every letter in the acronym or using every feature.

In fact, PRPL is more about a mindset and a long-term vision for improving the performance of the mobile web than it is about specific technologies or techniques.

Annexe : Exemples de code

DDD Sample

Ce repository qui illustrait le Domain-Driven Design, initié vers 2008 par une équipe comprenant Eric Evans, utilise ces mots application / domain / infrastructure :

• https://github.com/citerus/dddsample-core

Dans src/main/java/se/citerus/dddsample, on trouve les répertoires :

Le répertoire application contient l’interface de programmation du code métier, une fine couche qui orchestre le code métier :

Dans domain, on trouve les objets et les règles métier, par exemple pour les marchandises (cargo) :

Et le répertoire infrastructure contient le code de persistance et de messaging :

Modular Monolith with DDD

Cet autre exemple de Kamil Grzybek utilise des répertoires Application / Domain / Infrastructure dans ses modules, qui correspondent chacun à des bounded contexts :

• https://github.com/kgrzybek/modular-monolith-with-ddd

Vous pouvez inspecter chaque module :

• src/Modules/Administration
• src/Modules/Meetings
• src/Modules/Payments
• src/Modules/UserAccess

View Model

The view model acts as an intermediary between the view and the model, and is responsible for handling the view logic. Typically, the view model interacts with the model by invoking methods in the model classes. The view model then provides data from the model in a form that the view can easily use. The view model retrieves data from the model and then makes the data available to the view, and may reformat the data in some way that makes it simpler for the view to handle. The view model also provides implementations of commands that a user of the application initiates in the view. For example, when a user clicks a button in the UI, that action can trigger a command in the view model.

Implementing MVVM in Angular

Angular supports the principles behind MVVM design pattern in the following approach.

• Model — The model is implemented as an Angular service (Factory or Service).

• View — The View is implemented using Angular ‘template’ (HTML with data bindings) that is rendered into the Angular view directive (ng-view / ui-view). The View is bound to the ViewModel so that when a property is changed in the ViewModel, it is instantly reflected in the View. Data bindings can work both ways in special cases like HTML forms, where a user can manipulate a property directly.

• ViewModel — The ViewModel is implemented as an Angular controller. The ‘ngController’ directive is used to specify a controller for a view. It can expose properties and methods to the view. It can also be attached to the DOM by declaring it in a route definition via the ‘$route’ service.

The above implementation suggestions are applicable to Angular 1.x framework.

« Le Modèle-Vue-VueModèle (en abrégé MVVM, de l’anglais Model View ViewModel) est une architecture et une méthode de conception utilisée dans le génie logiciel. MVVM est originaire de Microsoft et adapté pour le développement des applications basées sur les technologies Windows Presentation Foundation et Silverlight via l’outil MVVM Light par exemple. Cette méthode permet, tel le modèle MVC (Modèle-Vue-Contrôleur), de séparer la vue de la logique et de l’accès aux données en accentuant les principes de binding et d’événement. » (source)

Pour vulgariser, la différence entre MVVM et MVC tient du fait que le MVVM, lui, se repose sur le DataBading et l’évènementiel.  Ça tombe bien, c’est ce qu’AngularJS est !

La vue est couplée aux données via du DataBinding et invoque les méthodes du ViewModel.

Le ViewModel invoque les méthodes du modèle. Il contient la data spécifique à la gestion de l’écran et les méthodes de réponses aux interactions utilisateurs. Il contient également une référence vers un ou des modèles.

Le modèle contient la data et les méthodes de manipulation de cette dernière (calculs, appels de services, …).

Même si vous n'avez jamais entendu le terme "middleware" le concept de ce design pattern ne devrait pas vous sembler étrangé. Un middleware désigne un élément qui va venir se placer entre la requête reçue par le serveur et la réponse renvoyée. En ce sens, votre application PHP est, par nature, un middleware, elle prend en entrée une requête (représentée par des variables globales `$_POST`, `$_SERVER`...) et l'interprète pour renvoyer une réponse HTTP (grâce aux fonctions `echo` et `header()`).