conception.tex

\section{Architecture}

Le diagramme suivant \ref{fig:sequence-overview} démontre les deux scénarios principaux de l'application:

\begin{enumerate}
  \item Lorsqu'un nouvel utilisateur rejoint le site, il doit récupérer l'état actuel de la toile.
  \item Lorsqu'un utilisateur pose un pixel, tous les autres usagers doivent recevoir l'information.
\end{enumerate}

De plus, le diagramme montre également que l'application utilise plusieurs niveaux de stockage de données: un cache et une base de données. Les raisons derrières ce choix seront expliquées dans la section \ref{section:stockage}.

\fig[H, width=1\textwidth]{Diagramme de séquence de la pose de pixels}{sequence-overview.svg}
\label{fig:sequence-overview}

\section{Séparation Client / Serveur}

Tout d'abord, le choix de découper le projet en deux applications bien distinctes s'est fait rapidement. En effet, il aurait été possible de faire une application monolithique, comme il était plus commun de le faire à l'époque avec des frameworks comme Ruby on Rails ou Laravel. De nos jours, il est plus courant de bien séparer les différentes couches d'une application et d'en faire des applications indépendantes. Cela octroie plusieurs avantages:

\begin{itemize}
  \item Meilleure scalabilité, en pouvant notamment multiplier les instances de chaque application séparément.
  \item Développement plus facile entre plusieurs équipes de développeurs, sans devoir tous modifier le même code.
  \item Possibilité d'utiliser le même serveur pour plusieurs clients différents, par exemple pour un site web ainsi qu'une application mobile.
\end{itemize}

Cependant, il faut également prendre en compte que cette approche demande souvent plus de travail qu'une application unique. Par exemple, pour gérer l'état actuel de l'application, les deux partis doivent garder une synchronisation entre eux. Il faut donc bien faire attention à ce que les changements soient effectués des deux côtés.