6 Money converter: CLI around an HTTP call

This chapter walks through building a pocket-sized Go CLI that converts money amounts between ISO-4217 currencies by combining clean domain modeling, careful numeric handling, and an HTTP call. It motivates a command-line approach for speed and composability, then sets practical requirements and limitations: parse a single amount and two currencies, round safely to each currency’s precision, and avoid non-decimal systems and malformed inputs. From the outset, it stresses that real-world money demands exactness and guards against floating-point pitfalls by using fixed-precision representations and explicit validation, making the project educational rather than production-grade.

The implementation centers on a small “money” package with immutable value objects: Currency (code and precision), Decimal (fixed-precision subunits), and Amount (quantity plus currency). Parsing functions turn strings into valid business types, expose meaningful domain errors, and simplify trailing zeros; tests use table-driven cases, validation functions, and helpers to keep design testable. Conversion avoids floats by multiplying Decimals via an ExchangeRate, adjusts precision with pow10, and validates results against bounded ranges. For usability, types implement Stringer; for the CLI, the main package reads flags and arguments with the flag package, parses inputs into business types, and prints readable results—while deliberately keeping parsing/validation inside the library.

To fetch real exchange rates, the chapter adds a separate ecbank client that calls the European Central Bank’s XML endpoint with net/http, checks status codes, decodes with encoding/xml, and computes cross-currency rates via EUR. Dependency injection decouples the money package from the HTTP client: Convert accepts an interface for fetching rates, enabling stubs in tests and mock HTTP servers via httptest. The chapter closes with pragmatic improvements—caching rates, adding timeouts and a dedicated http.Client, inspecting errors with errors.As, and noting alternative project layouts—reinforcing robust error handling, testability, and maintainable design around a simple, useful CLI.

• The flag package exposes functions that allow us to retrieve both arguments and optional parameters from the command line. We can even set default values to our flags. Remember to call flag.Parse() before checking the values of the flags!
• When implementing a functionality, it is good to declare types that mirror the core entities that we will have to handle. In our case, we created a Currency, a Decimal, an Amount, and we defined what Convert should do before writing a single mathematical operation or calling a single function. We also knew from the start how to organise our code, which types and functions should be exposed.
• The fmt.Stringer interface is a simple interface that will make printing complex structures nicely.
• Floating point numbers are inaccurate, at best. There should always be room for a margin when comparing two floating point numbers. Operations on floats will sometimes seem nonsensical, because of the precision limitation. Knowing their precision and the precision of the computation they’re used for will help make a choice of float32, float64, big.Float - or to go for something else.
• A package is most often built starting with its API, and finishing with its unexposed functions.
• Go’s net/http package offers functions to perform HTTP calls, such as GET or POST requests, over the network. It offers a default client, which can be used for prototyping, but shouldn’t be kept in production-level code, for security reasons.
• A HTTP call will return a response that contains a status code. Checking this status code is mandatory - the code informs how meaningful the body of the response is. Status codes are divided into 5 classes, but the most important are 200 (and 2xx), which means everything went fine, 400 (and 4xx) which means the request might be incorrect - some fields could be missing, some authentication could be wrong, … -, and 500 (and 5xx), which mean the server faced an issue and couldn’t process the request.
• Testing HTTP calls should be agnostic from external behaviour. Go provides a httptest package to mock HTTP calls by providing an infrastructure to set up an HTTP server for tests. a useful NewServer function.
• A clean code separates the responsibilities of each package. Retrieving data isn’t the same task as computing data, and should be handled in a separate piece of code. Go offers extremely simple interfaces that allow for dependency injection. Dependency injection makes code simple, and tests even simpler.
• Stubs are a very nice way of implementing interfaces. Simply declare a struct where you need to implement an interface - usually in a _test.go file - and have it implement the interface. A stub is very useful when trying to improve test coverage, but it can only be used for unit tests, as they don’t check the whole logic of the call.
• Exposed functions, in a package, should return sentinel errors. This makes using a package clean and simple. Within the implementation of the package, the decision of creating the sentinel errors in exposed functions or in unexposed functions is left to the developer.
• Using errors.Is how we test if an error is a sentinel. Using errors.As is how we access an error’s fields and methods.
• Go’s encoding/xml package provides a function and a method to decode an XML message. In order to be able to decode some bytes into a structured variable, Go’s syntax requires that the fields we want to decode be described with the XML path where their value can be read. It is even possible to skip layers by using the > character in that path.
• The toolchain offers the go build -o path/to/exec . command, which generates an executable file at the specified location.

FAQ