Création d’une plateforme complète d’annonces immobilières

Pourquoi cette note existe

Cette note documente la direction technique derrière la construction d'une plateforme de listage de propriété de style AirBnB.

La valeur de ce projet n'est pas la marque du clone. La partie utile est la conception du système derrière une application web de type marché:

• utilisateurs
• lieux/listes
• équipements
• villes/États
• Révisions
• direction des réservations
• relations entre les bases de données
• routage du moteur
• Paramètres de l'API
• rendu de la façade
• structure de déploiement

Une application de listage de propriétés est un bon exercice complet car elle force l'application à gérer les données connectées au lieu d'afficher uniquement des pages statiques.

Contexte du projet

Le projet a été construit en tant qu'application web complète inspirée des plateformes de location à court terme.

L'accent était mis sur la compréhension de la structure d'une véritable application Web, du moteur à la façade :

database models
  ↓
backend logic
  ↓
API routes
  ↓
frontend views
  ↓
user interaction
  ↓
deployment

Le projet fait partie du portefeuille en tant qu'architecture logicielle et note de base complète, pas en tant qu'affectation de formation générique.

Ce que ce projet veut prouver

• applications web ont besoin de modèles de données claires avant de polir UI
• les relations entre les utilisateurs, les listes, les lieux et les commentaires comptent
• le routage du moteur et la conception de l'API doivent suivre le comportement de l'application
• le rendu frontal dépend de la forme propre des données
• la structure de déploiement est importante même pour les petites applications
• clonage d'un concept de produit existant peut encore enseigner l'architecture réelle
• Le travail complet consiste principalement à raccorder les couches de façon sûre et prévisible

Pioche et outils utilisés

Calque de sauvegarde

• Python
• Direction de la flamme
• Routes de type REST
• modèles d'application
• sérialisation
• Traitement des demandes/réponses
• validation du moteur

Couche de données

• modélisation des données relationnelles
• utilisateurs
• lieux/listes
• villes
• États
• équipements
• Révisions
• relations entre les bases de données
• direction du moteur de stockage

Couche frontale

• HTML
• CSS
• JavaScript
• rendu dynamique
• Consommation d'API
• structure des pages
• Direction générale de l'assurance-chômage

Couche de déploiement

• Direction du serveur Linux
• direction du serveur Web/du serveur d'application
• configuration de l'environnement
• Actifs fixes
• initialisation de la base de données
• démarrage du service

Construction prévue

La construction prévue est une plate-forme de listage de propriétés de travail avec backend connecté et des couches frontales.

Une version terminée devrait prendre en charge:

• liste des lieux/propriétés
• organisation des listes par lieu
• associer les utilisateurs aux listes
• afficher les équipements
• montrant les commentaires
• récupérer les données via les routes API
• rendu dynamique du contenu frontend
• Maintenir une structure de projet propre
• préparer l'application pour le déploiement

Le projet n'a pas besoin d'être une plateforme de réservation commerciale pour être techniquement utile.

Sa valeur est dans l'architecture d'application.

Modèle de données principal

Le système central peut être compris par des entités:

User
State
City
Place
Amenity
Review

Les relations comptent.

Exemple :

State
  ↓
City
  ↓
Place

Autre exemple:

User
  ↓
Place
  ↓
Review

Et :

Place
  ↔
Amenity

Cela introduit des relations d'un à plusieurs, qui sont importantes dans les applications réelles.

Pourquoi les relations avec les données comptent

Une simple page de liste peut sembler facile de l'extérieur.

Mais le moteur doit répondre à des questions comme:

Which city does this place belong to?
Who owns this place?
Which amenities are attached to it?
Which reviews belong to it?
Who wrote each review?
How should deleted or missing records behave?

Si les relations sont malsaines, la façade devient malsaine aussi.

Une bonne modélisation des données facilite la construction du reste de l'application.

Direction d'acheminement du moteur

Un moteur propre devrait exposer des itinéraires prévisibles.

Exemples de groupes d'itinéraires :

/users
/states
/cities
/places
/amenities
/reviews

Chaque ressource peut soutenir des opérations comme :

list
get by id
create
update
delete

Les itinéraires devraient suivre la structure des données au lieu d'être des gestionnaires ponctuels aléatoires.

Cela rend l'API plus facile à tester et plus facile à consommer pour la façade.

Sérialisation

Les objets Backend doivent devenir JSON ou un autre format compatible avec la façade.

Par exemple, un objet Place peut avoir besoin de sérialiser :

{
  "id": "place-id",
  "name": "Listing name",
  "city_id": "city-id",
  "user_id": "owner-id",
  "price_by_night": 80,
  "amenities": [],
  "reviews": []
}

La sérialisation est importante parce que les modèles backend contiennent souvent plus de données que la façade ne devrait recevoir.

Une bonne application décide ce qui doit être exposé.

Rendu frontal

La façade ne doit pas coder toutes les inscriptions.

Un meilleur flux:

page loads
  ↓
JavaScript fetches listings from API
  ↓
frontend renders cards
  ↓
user filters or interacts
  ↓
frontend updates view

Ceci sépare les données de la présentation.

Il facilite également l'application plus tard.

Cartes d'inscription

Une carte d'inscription de propriété nécessite habituellement :

title
price
location
short description
amenities
owner or host direction
reviews/rating direction
image direction if supported

L'interface utilisateur n'est pas seulement une décoration.

Il reflète les données disponibles et la structure du moteur.

Direction du filtrage

Une plateforme de listing devient plus utile lorsque les utilisateurs peuvent filtrer les résultats.

Filtres possibles:

location
price
amenities
availability direction
number of guests
type/category

Même si la première version ne prend en charge que des filtres simples, le moteur et la façade doivent être structurés afin que les filtres puissent être ajoutés proprement.

Le filtrage oblige le système à penser à la structure de requête et à l'état frontal.

Examens

Les revues présentent un comportement important.

Une revue appartient à:

user
place

Un examen devrait généralement comprendre:

text
rating direction if implemented
created date
author
place

La logique de révision soulève également des questions de politique générale :

• Les propriétaires peuvent-ils consulter leurs propres listes?
• Les utilisateurs peuvent-ils modifier/supprimer leurs commentaires?
• Les lieux supprimés devraient-ils garder des revues historiques?
• Les examens devraient-ils être paginés?
• Les revues doivent-elles être chargées de place ou séparément?

Même si toutes les fonctionnalités ne sont pas mises en œuvre, le modèle enseigne les véritables préoccupations d'application.

Équipements

Les commodités sont un bon exemple de nombreuses données.

Un endroit peut avoir de nombreuses commodités:

Wi-Fi
Parking
Kitchen
Air conditioning
Pool

Et la même amabilité peut appartenir à de nombreux endroits.

Cette relation est plus intéressante qu'un simple champ de texte car elle nécessite une table de jonction ou une structure équivalente.

Cela le rend utile en tant qu'exercice de modélisation de base de données.

Direction de l'authentification

Une plateforme de listage de propriétés a besoin d'authentification.

Actions potentielles de l'utilisateur:

create listing
edit own listing
delete own listing
write review
manage profile
save favorites
book/reserve direction

L'authentification et l'autorisation sont des idées distinctes :

authentication = who are you?
authorization = what are you allowed to do?

Même si la première version a une authentification limitée, l'application doit être structurée en tenant compte de la propriété.

Directive d'autorisation

Les règles de propriété sont importantes.

Exemples:

only listing owner can edit listing
only review author can edit review
admin can moderate content
public users can view listings
logged-in users can create reviews

Ces règles transforment le projet d'un catalogue statique en une véritable application.

API et contrat Frontend

La façade dépend de la forme de la réponse du moteur.

Si l'API change au hasard, la façade se brise.

Un meilleur modèle est de garder un contrat clair:

endpoint
method
request body
response body
error format
status codes

Exemple :

GET /api/places
returns list of places

POST /api/places
creates a new place

GET /api/places/<id>
returns one place

Cela rend le projet plus facile à déboguer.

Gestion des erreurs

Une vraie application nécessite des erreurs prévisibles.

Cas fréquents:

record not found
invalid input
missing required field
unauthorized action
database error
duplicate value
invalid relationship id

La façade doit recevoir des erreurs utiles, pas des accidents aléatoires.

Un format de réponse d'erreur simple peut aider:

{
  "error": "Place not found"
}

Pages statiques et pages dynamiques

Une plate-forme de listing peut commencer par des pages de serveur ou un HTML statique qui récupère les données de l'API.

La distinction importante:

static content = written directly in the page
dynamic content = fetched from backend/data source

Une version plus forte utilise le moteur comme source de vérité et laisse le rendu frontend mettre à jour les données.

Direction du déploiement

Une application complète nécessite plus que du code.

Le déploiement comprend :

• variables environnementales
• configuration de la base de données
• serveur app
• proxy inversé
• fichiers statiques
• journaux
• Comportement de redémarrage
• migrations/initialisation
• direction de sauvegarde

Même une petite application devrait avoir des étapes de démarrage documentées.

Configuration environnement

Les secrets et les valeurs spécifiques à l'environnement ne doivent pas être codés en dur.

Exemples:

database URL
secret key
debug mode
host/port
API base URL

Une configuration propre utilise:

.env.example
.env.local
environment variables

De vrais secrets ne devraient pas être confiés à GitHub.

Initialisation de la base de données

Une application prévisible devrait avoir un moyen d'initialiser sa base de données.

Étapes utiles:

create tables
seed test data
load sample states/cities/amenities
create demo users
reset dev database if needed

Cela facilite les tests locaux.

Il aide également les futurs contributeurs à comprendre l'application rapidement.

Direction des essais

Les tests utiles comprennent:

Essais du modèle

• créer un utilisateur
• créer un lieu
• attacher l'amenité
• créer un examen
• chargement de la relation
• champs invalides

Essais d'API

• liste des lieux
• obtenir un seul endroit
• créer un lieu
• création de requête invalide
• supprimer/actualiser la direction de propriété

Essais de front

• rendu des listes
• mise à jour des filtres
• l'état vide apparaît
• Le message de défaillance de l'API apparaît

Même si la construction originale est simple, documenter la direction du test la rend plus forte.

Bogues courantes

Frontend affiche les données vides

Causes possibles:

• URL de l'API incorrecte
• moteur ne fonctionnant pas
• Numéro CORS
• changement de la forme de la réponse
• bug de sélection de JavaScript
• Erreur retournée par l'API au lieu de liste

Données de relation manquantes

Causes possibles:

• ne comprend pas les champs connexes
• relation de base de données non chargée
• Mauvaise clé étrangère
• requête retourne un objet incomplet

Dossiers en double

Causes possibles:

• pas de contrôle d'unicité
• script de semences répété
• IDs externes manquants
• la réinitialisation de la base de données n'a pas été effectuée correctement

App fonctionne localement mais pas déployé

Causes possibles:

• variables d'environnement manquantes
• Mauvais hôte/port
• base de données non initialisée
• fichiers statiques non servis
• proxy inversé non configuré
• debug-only chemin utilisé dans la production

Décisions pratiques

Encadrez-le comme une plateforme, pas comme un clone

La partie utile est l'architecture, pas la copie d'une marque.

Gardez les modèles de données lisibles

Des modèles clairs facilitent le reste de l'application.

Traiter la forme de l'API comme un contrat

Frontend et backend devraient convenir de données prévisibles.

Séparer la configuration du code

Le déploiement ne devrait pas nécessiter l'édition des fichiers sources.

Ne pas surcharger la capacité de production

Une application d'apprentissage et de mise en place complète peut encore être utile sans prétendre être une plateforme commerciale.

Afficher les relations

La preuve technique la plus forte n'est pas l'interface utilisateur.

Ce qu'une version terminée devrait montrer

Une version terminée forte devrait montrer:

• structure propre du moteur
• modèles de base de données
• relations entre les entités
• Routes de type REST
• sérialisation
• frontend récupération des données
• cartes d'inscription dynamiques
• direction de filtrage
• examen/traitement de l'attention
• config environnement
• notes de déploiement
• README avec les étapes de configuration
• Aucun secret commis
• données d'échantillonnage pour les essais

Preuves à retenir

Voici quelques éléments de preuve utiles à cette note :

• diagramme du modèle de base de données
• liste des itinéraires
• fronten listing page screenshot
• Exemple de réponse à l'API
• exemple de relation lieu/sensité
• exemple d'examen
• structure du dossier de projet
• instructions d'exécution locale
• notes de déploiement
• échantillon de semences
• avant/après l'exemple de rendu dynamique

Hypothèses techniques

Cette note suppose que l'application est un projet complet de listage de propriétés inspiré par les plateformes de marché/location.

Il prend une direction Python/Flask style backend avec frontend JavaScript et des modèles de base de données structurés.

Il suppose également que l'objectif est de démontrer les fondamentaux et l'architecture d'application complète, et non de revendiquer l'exhaustivité des caractéristiques commerciales.

Principaux risques

• présenter le projet comme un clone de marque au lieu de travail d'architecture
• surdemande de paiement/reservation si elle n'est pas mise en œuvre
• Faibles relations entre les bases de données
• données frontend codées en dur
• pas de contrat d'API clair
• aucune séparation de l'environnement
• aucune documentation d'installation
• exposer des secrets
• Déploiement interrompu en raison du manque de configuration de la base de données
• essayant d'ajouter des fonctionnalités avancées avant que CRUD ne fonctionne

État actuel

Cette note représente un projet de logiciel complet axé sur la structure de l'application.

Il est plus ancien que l'infrastructure et le système d'affaires actuels, mais il ajoute encore de la valeur parce qu'il montre une couche différente:

backend models
API design
frontend rendering
database relationships
deployment basics

Cela le rend utile comme note d'appui plutôt que la pièce maîtresse principale du portefeuille.

Ce que la présente note ne prétend pas

La présente note ne prétend pas être un concurrent de production AirBnB.

Elle ne prétend pas inclure le traitement des paiements réels, les flux légaux de réservation, la vérification d'identité ou les opérations complètes du marché, à moins que ces caractéristiques ne soient explicitement mises en œuvre.

Il documente une application complète pratique utilisée pour comprendre comment les plates-formes d'inscription sont structurées.

À emporter pratique

La leçon utile est:

Une application de type marché est principalement des données connectées, pas seulement des cartes sur une page.

Les éléments importants sont les suivants:

• modèles propres
• relations correctes
• API prévisibles
• rendu dynamique de la façade
• validation
• Règles de propriété
• configuration de l'environnement
• structure de déploiement

Encadré de cette façon, le projet devient une note d'architecture complète au lieu d'un clone générique.