Intermediate 5: Multi-app configuration

Review

From the previous lessons, you’ve gotten used to configuring and deploying repositories to Platform.sh with three files:

• .platform/routes.yaml: for handling requests
• .platform/services.yaml: for configuring and defining services
• .platform.app.yaml: for defining build and deploy steps for the application

Configuring multiple applications

On Platform.sh, it’s just as easy to define multiple application containers within your repositories.

Take a look at the repository tree below:

.
├── .platform
│   ├── routes.yaml
│   └── services.yaml
├── .platform.app.yaml
├── README.md
├── ....
├── application code
└── ...

This could be the repository structure for any project deployed on Platform.sh, but let’s begin by assuming that it represents a PHP-based CMS like Drupal or WordPress. Every bit of code and configuration exists in the root of the repository in this case, but the following would be equally valid:

.
├── .platform
│   ├── routes.yaml
│   └── services.yaml
└── drupal
    ├── .platform.app.yaml
    ├── README.md
    ├── ....
    ├── application code
    └── ....

Here, all of our application code and application configuration can be nested inside of a subdirectory called drupal. This doesn’t just enable you to clean up your codebase a bit, but also to define an application container as a submodule (which becomes more relevant as you add more applications).

Now, let’s say that I plan on decoupling my application - that is, I want to rely less on Drupal’s built-in frontend tooling (Twig) and instead leverage its JSON API and consume content data with a different frontend. Next.js is looking promising, so I may want to create a new development environment to test out the changes.

If you already have a Next.js project to start playing with, one way to test it is with the following:

.
├── .platform
│   ├── routes.yaml
│   └── services.yaml
├── drupal
|   ├── .platform.app.yaml
|   ├── README.md
|   ├── ....
|   ├── application code
|   └── ....
└── nextjs
    ├── .platform.app.yaml
    ├── README.md
    ├── ....
    ├── application code
    └── ....

Next.js gets its own subdirectory called nextjs that contains its application code and it’s own .platform.app.yaml file to configure its builds and deployments. In our new environment we can test and merge this new application into production when we’re satisfied. From that point on each environment will inherit this new architecture, giving them copies of both application containers every time.

Shared configuration

If we revisit the new structure of the repository, you’ll notice that the project-level .platform subdirectory hasn’t moved from its original location. This is because configuration here is considered shared across app containers.

Services

For services, that means that a database defined in .platform/services.yaml

db:
    type: mariadb:10.4
    disk: 2048

can be accessed from both applications (if necessary) with identical relationship definitions.

relationships:
    database: 'db:mysql'

Routes

Route definitions simply get added to the same .platform/routes.yaml file for all applications.

https://api.{default}/:
  type: upstream
  upstream: "drupal:http"
  id: "api"
  cache:
    enabled: true
    cookies: ['/^SS?ESS/', '/^Drupal.visitor/']
https://www.api.{default}/:
  type: redirect
  to: "https://api.{default}/"
  
https://www.{default}/:
  type: redirect
  to: "https://{default}/"
https://{default}/:
  type: upstream
  primary: true
  id: "client"
  upstream: "nextjs:http"

The above snippet

• Modifies the drupal app’s url to the api subdomain.
• Directs traffic at the root domain to the nextjs application.

Next: Multi-app reusability