Remote vs local API for local web app development

Question

I'm developing both a REST API and a frontend web app. What's the best way to go about plugging the API into the web app while I'm developing locally on my machine?

1. I could spin up a local copy of the API and point my web app to localhost:api-port, but that seems like unnecessary administrative work to have a local copy of both the API and web app running. Every time I want to do any development work I'll have to spin up the API, then spin up the web app.

2. I could set up a remote dev environment and point my web app to dev.api.mydomain.com for local development, but it seems counter intuitive to have to set up a remote API sandbox to develop the web app locally.

3. I could mock schemas and data with JSON files for local development. Instead of the web app doing a GET to api.mydomain.com it'll just read ./mock-data/some-resource.json. Seems like extra overhead to keep schemas and data matching production. Also wouldn't handle any logic that's built into the API on top of returning raw resources.

Best way forward?

Answer 1

Option 1 is definitely the best route in my experience. I sometimes use Option 2, typically in scenarios such as hooking my local application into a remote database (that usually also has another instance of the application hooked up to it, do this with extreme caution).

Advantages of running all applications locally for development:

1. You can debug integrations with your API without the hassle of a remote debugger.
2. You can see the logs for both applications without needing to access a server (log analysis tools like Splunk can mitigate this point).
3. You can do whatever you want to the underlying data of the application without affecting anyone else who works on the app (assuming you run the application database locally as well).
4. You can prototype changes in both codebases without deploying.

Running everything locally does incur a setup cost (depending on how complex your runtime dependencies are, this can be anywhere between a few minutes to several days of work), but even so, the overhead is a one-time effort.

Every time I want to do any development work I'll have to spin up the API, then spin up the web app.

To address this, you could write a startup script that launches both services together, or use something like docker and docker-compose for running your apps locally. Using docker-compose, if you register dependencies between docker containers in the docker-compose.yml file, the API will launch when you start the front-end app. This kind of application orchestration is exactly what docker-compose is made for. Also on the plus side, with Docker you only have to solve the environment setup problem once, and it can be highly repeatable for other developers.

The downside of Docker is that it can be tricky (or impossible) to hook an IDE debugger into the container depending on your runtime. In those cases it may be best to set up your local development environment natively on the machine and use the startup script approach for orchestration of services.

• mgw854: I work in a shop that chose option #2, and it can cause a lot of issues (inadvertently when a developer messes up, or purposefully for large changes that require coordination). Knowing what we know now, and with the proliferation of tools like Docker, we'd chose #1.