Implementing Hot Reload in Go for a Web Service

This challenge focuses on implementing a "hot reload" mechanism for a simple Go web service. Hot reloading allows you to make changes to your code and see them reflected in the running application without manually stopping and restarting the server. This significantly speeds up the development workflow.

Problem Description

Your task is to build a basic Go web service and then integrate a hot reloading capability. When a change is detected in your Go source files, the application should automatically restart itself with the updated code.

Key Requirements:

1. Basic Web Service: Create a simple HTTP server that responds to a specific route (e.g., /hello).
2. File Watching: Implement a mechanism to watch for changes in the Go source files of your project (or a specified directory).
3. Process Restart: Upon detecting a file change, the running Go application should gracefully shut down the existing HTTP server and then restart itself using the latest compiled code.
4. Error Handling: The system should handle potential errors during compilation or execution gracefully.
5. Non-Intrusive: The hot reloading logic should be separate enough from the core web service logic so that it can be easily enabled or disabled if needed.

Expected Behavior:

• When the application starts, it should begin serving requests on a predefined port.
• If you modify a .go file and save it, the application should detect this change.
• The old process should be terminated, and a new process with the updated code should be started.
• The new server should continue serving requests on the same port.

Edge Cases to Consider:

• What happens if a file change results in a compilation error?
• How do you handle concurrent file changes?
• How do you ensure a graceful shutdown of the old process?

Examples

Example 1:

• Scenario: Initial run and a code change.
• Input:
  1. Run the application. The web server starts.
  2. Make a change to the main.go file, for instance, changing the response message of the /hello endpoint.
  3. Save the main.go file.
• Output:
  1. The application logs something like "Starting server on :8080...".
  2. The application logs "Detected change in main.go. Restarting...".
  3. The old server stops, and a new one starts.
  4. Accessing /hello via curl http://localhost:8080/hello now returns the updated message.
• Explanation: The hot reload mechanism detects the saved file, recompiles, and restarts the server, applying the code modification.

Example 2:

• Scenario: Compilation error after a code change.
• Input:
  1. Run the application.
  2. Introduce a syntax error in a .go file.
  3. Save the file.
• Output:
  1. The application logs "Detected change in [filename]. Attempting to recompile...".
  2. The application logs a compilation error message (e.g., from go build).
  3. The application logs "Compilation failed. Not restarting. Please fix the errors.".
  4. The original, working server continues to run.
• Explanation: The hot reload detects the error during the compilation phase and prevents the restart of a faulty application, keeping the stable version running.

Constraints

• The web service should listen on a configurable port (defaulting to 8080).
• The hot reload should monitor all .go files within the current directory and its subdirectories.
• The solution should be implemented purely in Go, leveraging standard libraries or popular, well-maintained third-party libraries for file watching if necessary.
• Avoid solutions that rely on external tools like nodemon or live-reload browser extensions. The hot reload logic must be within the Go application itself.

Notes

• Consider using os/exec to run go build and then execute the compiled binary.
• A good file watching library in Go might be fsnotify.
• Think about how to signal the current process to shut down gracefully to avoid race conditions during the restart.
• The goal is to create a self-contained hot-reloading development server.