- A backend using API Platform Admin component
- A legacy frontend, hosting an API and a corporate frontend, developed with Symfony 6.2
- A white label frontend developed with Gatsby, consuming the “Legacy” API
- A Mercure Rocks server for marketing purposes (push notifications)
- All customer sources on a public GitHub repo
How to start hosting your multiple-application project with Platform.sh
1. Create a Platform.sh account
If you already have an account, you can skip this step. If not, you firstly need to create an account on Platform.sh using your Github, Google, Bitbucket, or GitLab account.2. Create a Platform.sh project
Now that you have your Platform.sh account set up, it’s time to create a project. On the homepage of your console, click on the ‘Create Project’ button on the top right corner and choose the second option to create a project from scratch. Then all you have to do is name it and select a region from the list. Please remember to always respect data sovereignty and we always encourage our users to choose a region with low-carbon consumption for their deployment. The production environment and organization can remain the same. After validation, which will take a few minutes, your project will be created—it’s as simple as that!3. Edit your plan for optimal storage
Multiple-application projects often need more storage than what’s included in the typical Platform.sh default development plan. Much like this Bigfoot project is used using for some apps, the Node modules consume at least 2GB of storage and so for the 4 applications needed to classify it as a multiple-application project, that number increases to 9GB of storage. To add more set up this enhanced storage, in the top right corner of your project overview in the console, click on the ‘More’ button—represented as 3 dots—and choose ‘Edit Plan’ which you can see in the image below. From there, go to the ‘Storage’ section and select the 10GB option, then select ‘Save.’ And if you want to go back to your project from there, just use the back button in your browser.4. Creating a fork of BigFoot multiple-application repository
To be able to perform the following steps in this process, you first need to create your own repository—i.e. fork—in Github as you won’t be able to change anything from the main repository. To do so, simply follow the steps in this Github article to create a fork from our BigFoot multiple-application project to your own Github organization. This Bigfoot multiple-application project has a backend using API Platform, a frontend+API using Symfony, a white label frontend using Gatsby, and a Mercure Rocks server. After creating your fork, please clone it locally and open it in your favorite integrated development environment (IDE). If you’re using PHPStorm, remember to install this amazing Platform.sh plugin designed to help with Platform.sh YAML config files.5. Add GitHub integration
Platform.sh provides a feature called Github integration that allows your Platform.sh project to be fully integrated with your Github repository. This integration enables you to use the normal Git workflow to deploy your environment—with no need to connect to the Platform.sh console. To enable Github integration on your project, follow these 5 simple steps:- From your Platform.sh console of your project, on the top right corner, click on the Settings button (represented as a wheel).
- In the left menu, from the Project Settings section, choose Integrations and select GitHub.
- Fill out the form with your access token and select your forked project.
- Choose the sync options that are needed for your project.
- Submit the form using the add integration button.
Please note: Throughout these steps, your main environment deployment should be failing with the following error.
This is the expected error as you won’t have created config files yet so don’t worry about that.
6. Set a remote to your Platform.sh project
In order to ease interaction from your terminal with your Platform.sh project, you need to set a remote using this CLI command:Please note: your
<projectID> can be found in the
console interface of your project,
or by finding it in your project list, as shown below:7. Configure your project
To configure your multiple-application project, there are a few basic rules:- .platform/ folder, containing routing, services, and application configuration files shared across all apps, needs to stay at the root of your source code.
- The name of the configuration files is fixed: routes.yaml, services.yaml, applications.yaml or .platform.app.yaml if you want to configure apps individually.
- Yaml format is used for config files.
-
Each app has a id:
- admin: API Platform Admin component
- api: BigFoot API + default frontend
- gatsby: Gatsby frontend
- mercure: Mercure Rocks Server
- App source code can be split into separate repositories and use Git Submodules. To find out more, please stay tuned, another blogpost is coming that will cover this subject.
Step 1: Configure routing and services
Platform.sh Yaml configuration needs at least 3 Yaml files for your project to be deployed and the locations of these files are the root of your source code, in the .platform/ folder. The .platform/ folder contains 3 config files, each with their own function, as you can see in the list and example below:- routes.yaml for routing
- services.yaml for services
- applications.yaml that will control behavior of all your applications in a single file,
Please note: each of the routes have an id which must be unique and is equal to the name of the application (please
see configure section)
Please note: As the Platform.sh config file is not in the same directory as your api app sources, we then need
to configure the
source.root section with the corresponding api directory.Step 2: Configure the api application
To configure the environment variables, specific to Platform.sh for the api application, create an api/.environment file. When present, this file will be sourced in the applications’ environment before loading any other environment variables such as those present in a .env file.Step 3: Configure admin
Configure admin app by adding the following configuration at the end of the existing .platform/applications.yaml file:Please note: as the defined admin route is
https://{default}/admin, you need to report suffix /admin in the
web.locations section. And considering the Platform.sh config file is not in the same directory as your admin app
sources, we need to configure the source.root section with corresponding admin directory.Step 4: Configure gatsby
To configure the gatsby app add the following configuration at the end of the existing .platform/applications.yaml file:Please note: as the gatsby route is
https://{default}/site you need to report this suffix /site in the
web.locations section. And due to Platform.sh config file not being in the same directory as your gatsby app sources,
we need to configure the source.root section with corresponding gatsby directory.Step 5: Configure mercure
Configure mercure app by adding the following configuration at the end of the existing .platform/applications.yaml file:Please note: as Platform.sh config file is not in the same directory as your mercure app sources, we need to
configure the
source.root section with corresponding mercure directory.