my 2 cents on goa design

[pot-code]

For me, goa is the third - party library that comes closest to my ideal of code - first design. It uses DSL to define interfaces and I can design more advanced APIs based on this DSL to simplify API definitions. These designs are very ingenious.

Let me first provide some background. Currently, I'm migrating a Python project written with FastAPI to the Go language. Since FastAPI also adheres to the code - first concept, goa is almost my only choice. Other similar tools like huma don't seem to be fully mature yet. The overall migration process has been smooth, but there are still some design aspects that puzzle me.

1. In goa, the payload includes field declarations for four types of data: path parameters, query parameters, headers, and request body. I was quite shocked when writing interface declarations. Moreover, when generating code, all this data gets stuffed into a single struct, and the service function has to manually split and parse it. In contrast, in FastAPI, I can use Query(), Param(), Body(), and Header() to categorize and handle these parameters separately, which significantly reduces the workload. Not to mention that goa doesn't support the declaration of object - type query parameters.
2. In my project, I use a custom primitive type. When generating OpenAPI documentation, it appears as a string type, and during the decoding process, it converts to an int64 type. Currently, I've managed to meet my requirements by combining Attribute and Meta("struct:field:type"... ). However, when I want to use this type in a scenario where both path parameters and the request body are involved, the generated code has a syntax error: I'm trying to assign a string type to my custom type. After checking the documentation, I found that when both the body and path parameters are present, path parameters must be of primitive types...

As I progress deeper into the migration, I'm increasingly feeling like I'm "fighting with goa." I have to resort to all sorts of hacky ways to achieve my requirements.

So, I'd like to ask if there are more elegant solutions to the problems I mentioned above. Thank you.

[raphael]

Thank you for the feedback! It seems a lot of what you find surprising in Goa is probably due to a couple of fundamental different requirements that Python/FastAPI and Go/Goa are satisfying:

1. Transport specific vs. Transport agnostic: Goa strives to make it possible to express endpoints independently of transport. The idea is that a remote service has methods which have payloads and results. The implementation (business logic) only cares about the final data types and that they are valid by the time it gets invoked, it should not care about how the payload and/or results are marshaled. This responsibility is left to the generated transport code with directives described in the design (which parts of the payload come from the body, headers, params etc.). On the other hand FastAPI is HTTP only and focuses on exposing HTTP constructs to the user code. If you are implementing a low level HTTP service where HTTP details are important and cannot be abstracted then Goa might not be the right choice.

2. Strong typing vs. dynamic typing: Since Go is strongly typed Goa must generate precise marshaling code for the data structures used by method payloads and results. One of the expected benefits is that Goa can generate very efficient code because it knows the layout vs. using something like reflection for example. This does mean that Goa must know about all possible types that can be marshaled. The Meta trick adds a little bit of flexibility for cases where the underlying data has a compatible marshaling profile as a type known by Goa. Obviously this is very different from Python where everything is dynamic.

[pot-code]

Thank you for your explanation. The code generation capability of goa is truly excellent, which is unparalleled by other libraries.

Since goa can also define gRPC services simultaneously, it achieves the principle of "single source of truth". These are all great designs. If I need to support microservices in the future, the migration process will also be very smooth. Goa is really an outstanding library.

Currently, I'm mainly focused on the HTTP part. Due to some edge cases in my requirements, I may explore other solutions for now. Thank you again for your reply!