Une simple application de service API pour consommer les bons du pool. Ceci est à des fins de démonstration et créé pour démontrer les compétences en architecture et en programmation.
Vous trouverez ci-dessous les points clés de la conception et la manière dont ils ont été traités et mis en œuvre.
Composer permet de gérer toutes les dépendances de l'application. Tous les packages/bibliothèques requis sont déclarés dans le fichier composer.json
. Et peut être installé à l’aide de la commande composer install
.
L'entrée de l'application pointe vers le répertoire public
, qui contient uniquement le fichier index.php
et peut également contenir des fichiers d'actifs accessibles publiquement. En dehors de cela, aucun code ou fichier en dehors de ce dossier n’est accessible directement. L'idée est de protéger tous les fichiers en dehors de ce répertoire.
Toutes les requêtes et la manière dont elles doivent être traitées sont définies dans le routes/api.php
.
Pour interagir avec MySQL, nous avons utilisé Illuminate Database alias "Eloquent". Il nous permet d'interagir avec notre base de données via le Object Relational Mapping "ORM".
Pour migrer et amorcer la base de données, nous avons utilisé le package indépendant du framework Phinx. Au fil du temps, le code de l'application évolue et la base de données évolue également avec lui. Pour suivre les modifications du code, nous utilisons des outils de versioning source comme git. Avec les scripts de migration, nous pouvons également suivre les modifications de la base de données. Particulièrement utile lorsque vous travaillez dans un environnement d’équipe. Lorsque vos coéquipiers récupèrent vos modifications, s'ils voient les scripts de migration, ils peuvent simplement les exécuter avec la simple commande pour mettre à niveau les modifications de leur schéma de base de données locale.
Pour gérer les dépendances de classe et effectuer l'injection de dépendances, nous avons utilisé SlimFramwork Container
. Avec cela, nous pouvons inverser le contrôle des dépendances de l'application à la classe, d'où le modèle "Inversion de contrôle".
Pour gérer les paramètres de configuration de l'application, nous avons utilisé Illuminate Config. Toutes les configurations sont stockées dans le répertoire config
. J'ai également utilisé Symfony Dotenv pour charger les variables définies dans le fichier .env
, puis y accéder via la fonction getenv(). Ceci est utile pour avoir des paramètres de configuration différents pour chaque environnement, c'est-à-dire développement, préparation, production.
Pour comprendre ce qui se passe dans notre application, nous avons utilisé la bibliothèque Monolog qui fournit des services de journalisation robustes qui vous permettent de consigner les messages.
Pour valider les données de requête HTTP entrantes de votre application, nous avons utilisé Illuminate Validation, qui fournit une variété de règles de validation puissantes.
Pour fournir une sortie standard et cohérente des données de réponse API, nous avons utilisé League Fractal, afin que nous puissions avoir une couche de présentation et de transformation pour nos données de sortie. Toutes les classes de transformation sont stockées dans le répertoire app/Transformers
.
Lorsqu'une nouvelle offre spéciale est créée, nous ne générons pas de bons pour tous les destinataires de notre système. Au lieu de cela, nous utilisons des HashIds pour générer et valider des bons pour chaque destinataire. Nous pouvons encoder et décoder en utilisant une combinaison de [{recipient_id}, {offer_id}]
. Il produit toujours un code de bon d'achat de 8 caractères exacts qui peut également être mis à jour dans le config/hashids.php
Pour tester notre service d'application, nous avons utilisé Codeception, prêt à l'emploi, il nous permet d'avoir les trois types de tests, c'est-à-dire les tests unitaires, fonctionnels et d'acceptation dans un cadre unifié. Dans notre cas, nous avons testé unitairement les objets métier principaux dans AppServices
, ainsi que des tests d'acceptation écrits pour vérifier l'intégration et la fonctionnalité de tous les points de terminaison de l'API. Tous les cas de tests sont stockés dans le répertoire tests
. et peut être exécuté par la commande suivante :
$ php vendor/bin/codecept run --steps
Pour maintenir les normes de codage au sein de l'équipe, j'ai créé le fichier phpcs.xml
, dans lequel toutes les normes de codage sont définies. et tous les fichiers de code peuvent être vérifiés en fonction de ce fichier en exécutant la commande suivante :
$ php vendor/bin/phpcs
Exigences de l'environnement de développement :
Configuration de votre environnement de développement sur votre machine locale à l'aide du script de configuration (Pour MAC/LINUX) :
git clone https://github.com/ahsanatiq/voucher-pool-api.git
cd voucher-pool-api
./setup.sh
Configuration manuelle (pour Windows) :
git clone https://github.com/ahsanatiq/voucher-pool-api.git
cd voucher-pool-api
cp .env.dev .env
docker-compose up -d
docker exec -it voucher-pool-php-fpm composer install
docker exec -it voucher-pool-mysql mysql -u root -pnewsletter2go -e " create database newsletter2go_testing; GRANT ALL PRIVILEGES ON *.* TO 'newsletter2go'@'%' IDENTIFIED BY 'newsletter2go'; " ;
docker exec -it voucher-pool-php-fpm php vendor/bin/phinx migrate
docker exec -it voucher-pool-php-fpm php vendor/bin/phinx seed:run
Vous pouvez désormais accéder à l'application via http://localhost:8080.
Exécutez les tests unitaires et les tests d'acceptation dans le conteneur de services PHP-FPM :
docker exec -it voucher-pool-php-fpm php vendor/bin/codecept run --steps
Vous pouvez accéder à la documentation publique de l'API sur Postman. Pour importer et exécuter toutes les API, cliquez sur "Exécuter dans Postman" dans la barre supérieure. Après l'installation et l'importation, vous verrez la nouvelle collection sous le nom "Newsletter2Go - Voucher API".