We have cleanly split projects where a React SPA communicates with a PHP API.The React developers need to be able to connect to an instance of the API in order to test their work.Would you prefer running the API locally, or using a shared staging instance?The backend is already containerised so developers could spin it up with Docker reasonably easily (there are usually multiple environment variables which would need to be set). My concern with asking frontend devs to run the API locally is it will increase friction when changes to the backend are made. The frontend team would need to be instructed to "pull the changes"/"spin up new image". In addition, changes to the database schema would need to be communicated, and it would be hard to provide a unified set of test data.A shared staging environment ("dev.project.company.com") alleviates these concerns. The backend team deploys to staging, updates the database schema on the staging DB, and seeds any useful test data. The frontend team doesn't need to do anything to "receive" these changes. However, they're now dependent on having an internet connection (developers work remotely). It also removes the ability for frontend devs to work against in-development API branches - unless it's merged into staging, it's not accessible.There's tradeoffs on both sides. I'm leaning towards requiring frontend devs to run the API locally, but am conscious this will increase onboarding time and potentially introduce friction as developers will need to remember to pull changes and apply schema migrations/seeds to a local database instance.I've tried to find case studies from other small teams but there seems to be very little writing on how this problem is usually solved, to my surprise. Thoughts welcome.