Ask HN: Should front end developer run API locally or use shared staging env? | Hacker News Reader

Ask HN: Should front end developer run API locally or use shared staging env?

5 pointsilmiont4 comments

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.

As a front-end dev, 3 things matter to me:

Can I trash the database without affecting the rest of the team?

Can I work on branches other than staging/prod (in case staging/prod is down or there is a bug)?

Can I perform common tasks (starting it up, querying the API, testing against it, etc..) without feeling like I'm pulling teeth?

If the answer is yes to all of them, I think the rest of the discussion becomes moot as it won't matter where the API is hosted.

One idea I'm currently toying with is having a completely automated build process for the API - ie, you call something like "docker-compose up" and it fetches the newest stable version of the API, migrates the database and sets up everything with sane defaults.

Most companies use remote dev APIs. You can have a versioned staging/production and then a dev API under continuous deployment is ideal, imho. This is an area where CI/CD shines.

A small company may run them locally as docker instance, but I think it's suboptimal and lots of unneeded overhead as you point out. If a frontend dev really needs to be offline, they can always switch to a docker instance (I haven't always had that option) but it's probably wise to normally use a remote dev API.

How do the backend devs test changes to the API and to the DB schema? Are they not running versions locally themselves? Can the frontend devs just do whatever the backend devs do?

> The frontend team would need to be instructed to "pull the changes"/"spin up new image".

With a small investment in tooling you can probably get away without asking too much of frontend devs.

Write your "launch local api" script (checked into the frontend repository) to just work without taking any parameters: put the latest docker image tag into version control. If you have a `latest` tag for your image then you don't even need to update the frontend repo, instead you can just always pull the image as part of the launch script. Anyone working on an API dev branch can just replace the image tag (either in the script, or you can provide a flag to override it).

Write your launch script to also start up the database if it's not running. You can check at API startup whether the db version matches the API, and inform the dev if there's a mismatch.

> However, they're now dependent on having an internet connection (developers work remotely).

Internet is a necessity anyways, they better have it and the company better cover it.

> 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.

Can try 3 environments. Dev, Staging, and Prod. An advantage on centralizing these environments is your frontend devs dont worry anymore if their local api version is outdated.

Reply on news.ycombinator.com