Repository files navigation

Laravel8 +Dockershrink/docker-php-api:8

Laravel Strict is a Laravel^⇗install designed for building high quality containerised Laravel applications.

• All HTTP requests served by Laravel — ideal for an API
• Code quality enforced byvimeo/psalm^⇗ andsquizlabs/php_codesniffer^⇗
• Laravel configured with sane defaults and without boilerplate
• Continuous Delivery usingGitHub Actions and the GitHub ContainerRegistry
• Development Environment using Docker Compose
• Taskfile^⇗ with helpful development lifecyclecommands

💭Laravel Strict is intended for projects with strict codequality requirements, it was created for use in regulated environments whereconfidence is more valuable than development speed.

1. Getting Started with Laravel Strict
2. Features included in Laravel Strict
3. Differences between Laravel Strict and Laravel
4. Development Environment

Laravel Strict is designed to be up and running immediately, producing adeployable application image from the first commit.Generate^⇗ a new repository from thistemplate and complete these steps from your new repository.

• Generate and add aPersonal Access Token^⇗ totherepository secrets with nameGHCR_PAT
• Fill outcomposer.json with projectname anddescription
• Create yourREADME.md with a project name anddescription

Your application is now ready to go: a production-ready Docker image has beenbuilt and pushed to the GitHub Container Registry by thebuild workflow. Start developing!

dev:~$git clone https://github.com/example/my-strict-application.gitdev:~$task start»» Launched application at http://localhost:8094

Docker'sHEALTHCHECK functionality declares a commandthat Docker can use at runtime to check the health of a container. LaravelStrict ships with a healthcheck endpoint (usingConductor)that is checked at a 10s interval.

There are differences between this install of Laravel and the standard that adeveloper will need to keep in mind. Many defaults have been removed,consolidated or changed to encourage best practices.

During development any required boilerplate can be obtained from thelaravel/laravel repository. When introducing boilerplateinto the project the code must be updated to meet the quality standards of theapplication.

Configuration has been moved fromconfig/*.php into the application bootstrapinbootstrap/app.php where all additional configuration of theapplication should take place. All of Laravel's optional configuration optionshave been removed, only required configuration is included by default.

Aliases have been removed as they encourage bypassing dependency injection.

Theroutes directory has been removed in favour of explicit route registrationthrough aServiceProvider for each component, as this encourages developers tothink about HTTP as one interface into the application — rather thantheapplication.

Laravel ships withvlucas/phpdotenv for easy environmentvariable management, however for a containerised application this library isunnecessary and may even compromise portability. All environment variablesshould be provided via the container orchestration engine, e.g: Docker Compose.

.dockerignore excludes all files by default before explicitlyincluding paths required by the application. Learn more about this approach inGetting Control Of Your.dockerignore Files by@markbirbeck.

Task is a cross-platform task runner, which is used to provide a fullsuite of commands for use during the development lifecycle.

dev:~$tasktask: Available tasks for this project:* check: Run application checks (code quality, tests)* start: Start the local application environment* .....: + more

Environment Variables should be explicitly set for each service indocker-compose.yml to emulate how environment variables will beprovided in production environments. A developer can usedocker-compose.override.yml to provide values unique to theirlocal environment.

Thevendor andstorage directories arevolume mounts to maximiseperformance, however this means by default the host machine cannot access thevolume contents.

Developers canbind mount these volumes instead to gain access to the volumecontents by overriding the volume configuration in theirdocker-compose.override.yml.

+services:+  app:+    volumes:+      - .:/srv+      - ./storage:/srv/storage+      - ./vendor:/srv/vendor

⚠️ bind mounting volumes in this way may reduce application performancein development by up to 10x