Decorators

Package errc simplifies error and defer handling. Package errc is a burner package: a proof-of-concept to explore better semantics for error and defer handling. Error handling and deferring using this package looks like: Checking for a nil error is replaced by a call to Must on an error catcher. A defer statement is similarly replaced by a call to Defer. Error handling in Go can also be tricky to get right. For instance, how to use defer may depend on the situation. For a Close method that frees up resources a simple use of defer suffices. For a CloseWithError method where a nil error indicates the successful completion of a transaction, however, it should be ensured that a nil error is not passed inadvertently, for instance when there is a panic if a server runs out of memory and is killed by a cluster manager. For instance, a correct way to commit a file to Google Cloud Storage is: The err variable is initialized to errPanicking to ensure a non-nil err is passed to CloseWithError when a panic occurs. This ensures that a panic will not cause a corrupted file. If all went well, a separate path used to collect the error returned by Close. Returning the error from Close is important to signal retry logic the file was not successfully written. Once the Close of w is successful all further errors are irrelevant. The error of the first Close is therefor willfully ignored. These are a lot of subtleties to get the error handling working properly! The same can be achieved using errc as follows: Observe how a straightforward application of idiomatic check-and-defer pattern leads to the correct results. The error of the first Close is now ignored explicitly using the Discard error handler, making it clear that this is what the programmer intended. Error handlers can be used to decorate errors, log them, or do anything else you usually do with errors. Suppose we want to use github.com/pkg/errors to decorate errors. A simple handler can be defined as: This handler can then be used as follows:

Package mw provides a Decorate function to cleanly decorate http.Handler interfaces with multiple middlewares. Go http middleware uses the following form You can use it with any existing middleware. Or you can build your own custom middleware. You can use it with gorilla mux. Or with the standard library http.ServeMux.

Package errorfmt provides a helper function to decorate errors with additional context.

Package assert, for writing checks in unit tests This package provides functions to reduce the amount of code needed to write simple assertions. It implements the best practice pattern where the output of a failure explains what the check "got" and what it wanted. The assert functions are defined such that writing requires less code but still are easy to understand. It works by decorating the standard testing.T type in your test and report (Fatal) the offending asserting call if a check fails. Example which will report Examples: (using the dot import) You can create and use your own checks by implementing the RelationalOperator.

Package ct provides ANSI terminal text coloring and decoration support.

Package gurl is a class of High Order Component which can do http requests with few interesting property such as composition and laziness. The library implements rough and naive Haskell's equivalent of do-notation, so called monadic binding form. This construction decorates http i/o pipeline(s) with "programmable commas". Microservices have become a design style to evolve system architecture in parallel, implement stable and consistent interfaces. An expressive language is required to design the variety of network communication use-cases. A pure functional languages fits very well to express communication behavior. The language gives a rich techniques to hide the networking complexity using monads as abstraction. The IO-monads helps us to compose a chain of network operations and represent them as pure computation, build a new things from small reusable elements. The library is implemented after Erlang's https://github.com/fogfish/m_http The library attempts to adapts a human-friendly syntax of HTTP request/response logging/definition used by curl with Behavior as a Code paradigm. It tries to connect cause-and-effect (Given/When/Then) with the networking (Input/Process/Output). This semantic provides an intuitive approach to specify HTTP requests/responses. Adoption of this syntax as Go native code provides a rich capability to network programming. ↣ cause-and-effect abstraction of HTTP request/response, naive do-notation ↣ high-order composition of individual HTTP requests to complex networking computations ↣ human-friendly, Go native and declarative syntax to depict HTTP operations ↣ implements a declarative approach for testing of RESTful interfaces ↣ automatically encodes/decodes Go native HTTP payload using Content-Type hints ↣ supports generic transformation to algebraic data types ↣ simplify error handling with naive Either implementation Standard Golang packages implements low-level HTTP interface, which requires knowledge about protocol itself, aspects of Golang implementation, a bit of boilerplate coding and lack of standardized chaining (composition) of individual requests. gurl library inherits an ability of pure functional languages to express communication behavior by hiding the networking complexity using category pattern (aka "do"-notation). This pattern helps us to compose a chain of network operations and represent them as pure computation, build a new things from small reusable elements. This library uses the "do"-notation, so called monadic binding form. It is well know in functional programming languages such as Haskell and Scala. The networking becomes a collection of composed "do"-notation in context of a state monad. A composition of HTTP primitives within the category are written with the following syntax. Here, each arrow is a morphism applied to HTTP protocol. The implementation defines an abstraction of the protocol environments and lenses to focus inside it. In other words, the category represents the environment as an "invisible" side-effect of the composition. `gurl.Join(arrows ...Arrow) Arrow` and its composition implements lazy I/O. It only returns a "promise", you have to evaluate it in the context of IO instance. The following code snippet demonstrates a typical usage scenario. The evaluation of "program" fails if either networking fails or expectations do not match actual response. There are no needs to check error code after each operation. The composition is smart enough to terminate "program" execution. See User Guide about the library at https://github.com/fogfish/gurl

One Tool to rule them all, One Tool to CI them, One Tool to test them all and in the darkness +1 them. Gandalf is designed to provide a language and stack agnostic HTTP API contract testing suite and prototyping toolchain. This is achieved by; running an HTTP API (aka provider), connecting to it as a real client (aka consumer) of the provider, asserting that it matches various rules (aka contracts). Optionally, once a contract is written you can then generate an approximation of the API (this happens just before the contract is tested) in the form of a mock. This allows for rapid prototyping and/or parallel development of the real consumer and provider implementations. Gandalf has no allegiance to any specific paradigms, technologies, or concepts and should bend to fit real world use cases as opposed to vice versa. This means if Gandalf does something one way today it does not mean that tomorrow it could not support a different way provided someone has a use for it. While Gandalf does use golang and the go test framework, it is not specific to go as at its core it just makes HTTP requests and checks the responses. Your web server or clients can be written in any language/framework. The official documentation also uses JSON and RESTful API's as examples but Gandalf supports any and all paradigms or styles of API. Most go programs are compiled down to a binary and executed, Gandalf is designed to be used as a library to write your own tests and decorate the test binary instead. For example, Gandalf does have several command line switches however they are provided to the `go test` command instead of some non existent `Gandalf` command. This allows Gandalf to get all kind of testing and benchmarking support for free while being a well known stable base to build upon. Contract testing can be a bit nebulous and also has various option prefixes such as Consumer Driven, Gandalf cares not for any prefixes (who writes contracts and where is up to you) nor does it care if you are testing the interface or your API or the business logic or some combination of both, no one will save you from blowing your own foot off if you choose to.