I can't speak to the *auto-generated swagger client* case but I believe gRPC is still doing things the right way -- in that the framework defines an interface I (the framework API consumer) then implements. IOW: I don't see that as a "java style interface" (where the interface defines the API contract).
I suspect you and I are saything the same thing. t. On Monday, August 8, 2022 at 12:51:29 PM UTC-7 bse...@computer.org wrote: > On Mon, Aug 8, 2022 at 12:51 PM Tim Peoples <t...@timpeoples.com> wrote: > >> I don't necessarily consider the "multiple implementations" case as being >> truly preemptive -- if there really are multiple implementations (e.g. the >> "hash" package from the standard library). >> >> I'm much more concerned about interfaces that are defined by an API >> producer -- for one and only one impl -- and then adding a bunch of extra >> (often autogenerated) code to deal with that. >> > > Like a gRPC client/server, or auto-generated swagger client/server? > > I've had many instances where such an auto-generated client had to be > passed down components that have no knowledge of those services. Writing > such components using interfaces declaring only parts of those service > implementations have benefits. An example that I can think of is an > audit-trail service that deals with recording transaction metadata, looking > them up, etc. It makes sense to write components that use only the writer > part of that service, instead of requiring the whole thing. It makes > writing tests easier. It lets you decouple services better, add > adapters/interceptors etc. > > >> >> t. >> >> On Monday, August 8, 2022 at 11:02:31 AM UTC-7 bse...@computer.org wrote: >> >>> On Mon, Aug 8, 2022 at 11:17 AM Tim Peoples <t...@timpeoples.com> wrote: >>> >>>> >>>> For years I've read the old adage, "Accept interfaces, return structs" >>>> and have spent years working to instill this understanding among my >>>> colleagues. I gathered a great many skills while learning Go (and >>>> acquiring >>>> readability) back in the day -- and one of the strongest of those is the >>>> idea that interfaces should be defined by their consumer instead of an API >>>> producer -- but I've now been away from Google longer than I was there and >>>> I'm beginning to suspect that the general consensus among the *Go >>>> Literati* may have shifted around some things -- like preemptive >>>> interfaces. >>>> >>>> My arguments against preemptive interfaces have recently run into more >>>> and more pushback -- especially among the influx of developers coming >>>> from >>>> the Java and/or C# world who seem to continually reject any notion that Go >>>> should be any different from the way they've always done things. >>>> >>>> This has recently come to a head with a brand new job (I'm 3 weeks in) >>>> where virtually all of their services are built atop a dependency >>>> injection >>>> framework having a data model with dozens (if not hundreds) of preemptive >>>> interfaces and my initial, cursory review tells me the codebase is at >>>> least >>>> an order of magnitude more complex that it needs to be. (Note, I was told >>>> that none SWEs at this company (other than myself) knew any Go before they >>>> started). >>>> >>>> So, my questions to the group are thus, "Should I even care about this >>>> at all? Are preemptive interfaces now considered the norm with Go? Or, >>>> should I just shut up and crawl back into my hole? >>>> >>> >>> I believe both approaches have their uses. What you call preemptive >>> interfaces can be effectively used to hide implementation details where >>> multiple implementations can exist. This approach can coexist very well >>> with interfaces defined by the consumer. For example we have services that >>> are written to implement an interface, so it becomes a logical deployment >>> unit. Then we have consumers of that service that define parts of the >>> interface service implements, so the consumer is not dependent on the >>> complete service, and we can add any interceptors/filters. >>> >>> However, I agree with your assessment that especially newcomers tend to >>> choose the traditional "interface is a contract" approach. In addition to >>> the effect of other languages, people seem to like "clean architecture". >>> Nevertheless, even with people dedicated to clean architecture, the idea of >>> "interface parts" seems to resonate, especially when you show that you can >>> define an interface on the consumer side that combines parts of multiple >>> "contracts". >>> >>> >>>> >>>> TIA, >>>> Tim. >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "golang-nuts" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to golang-nuts...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/golang-nuts/f4777928-875d-4c0a-a4a7-9fb57bf9d51fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/34469b98-c37e-4a1d-af13-729b639a71ben%40googlegroups.com >> >> <https://groups.google.com/d/msgid/golang-nuts/34469b98-c37e-4a1d-af13-729b639a71ben%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/535ab749-07e7-466d-b757-26f81ef2734an%40googlegroups.com.
