goa provides a design first approach for building microservices in Go.
It consists of three parts: a DSL for describing the API design, a code generation tool that generates an OpenAPI specification as well as boilerplate code for the service and the clients, and a set of library packages leveraged by both the generated and non generated code. goa is the culmination of 2 years of work spanning 5 complete rewrites. During this time goa evolved from being a pet experiment to becoming a strategic tool used by many organizations and with a striving and growing community.
Developing APIs is an iterative process that requires the collaboration of many teams. Often times the API design needs to go through a review process where the API developer is responsible for providing a detailed documentation of the current API and for implementing all the changes approved during the review. This puts a lot of burden on developers as they need to keep the design documentation up-to-date and visible to all the stakeholders at all time.
goa provides a real time detailed documentation readily available to all stakeholders. Even more importantly goa provides the confidence that the implementation matches the documented design thanks to its code generation tools. The data types, validations, documentation, encoding, security schemes and many other aspects described in the design are directly reflected in the generate service and client code alleviating the need for writing all the associated boilerplate code. The initial v1 announcement can be read here: https://goa.design/en/blog/001-h...
Report
Impressed with this concept, getting and example get today.
@vadivelk I'm going to guess that you are asking about how goa helps with writing multiple services that need to send requests to each other.
The design is written in a Go DSL which means that the corresponding packages can be imported in other designs using the standard Go `import` mechanism. This means that you can write the designs of services sharing any data type, endpoint definition, security scheme etc. as needed.
Another interesting scenario this enables is writing a single design package that gets implemented by multiple microservices. This is especially interesting for externally facing APIs where hiding the details on which service implements which endpoint is important.
@vadivelk To follow on to what Raphael said, Goa will work with any system you put in place like Consul or others. The focus is on the backend services, which you can then tie together using any orchestration framework.
Report
@derekperkins Isn't orchestration considered anti-pattern in microservices world?
@vadivelk Not trying to get too into the weeds, my point was that Goa helps you built out the service descriptions for the microservices and generates a lot of the boilerplate code for the backend service. However you want to connect those services is out of the scope of Goa and up to each user to wire them up as they see fit.
Report
@derekperkins Ok. I see. I thought there may be a road map to see goa help wiring them up. However, in Choregraphy style and not bringing any orchestration in the stack.
goa
goa
Nozzle.io
Nozzle.io