[go-nuts] Re: Bulky (Payload) Structs in API

[dc0d]

Thanks!

The bot package was just an example. This is a general concern IMHO. 
Interfaces do nicely when we want to hide implementation details (on 
accepting things as an interface). For example package A is a low-level, 
infrastructure package at Infrastructure layer/area. Now at the Interfaces 
layer, the package B is placed, which provides a nice set of abstractions 
for package A. In a use-case package named C, those abstractions from 
package B is used.

So far, so good! Now, as explained, package A has those bulky fat payloads; 
which forces us to use package A, directly inside package C.

This nullifies the purpose of package B.

This indeed, happens when a generic bot is being implemented. But even if 
that was not the case, I failed to find a way to prevent A from leaking 
into C.

At the end of the day it's all about trade-offs! I think you are right that 
there is no other way around and we have to either use A directly or write 
a translation layer.

Yet I'm curious about using type aliases as (yet another level of) an 
indirection.

On Monday, November 13, 2017 at 12:00:27 PM UTC+3:30, Egon wrote:
>
> Is there a problem created from sharing the package or creating a separate 
> package? Or why is that dependency a problem?
>
> There's some knowledge about the requests/responses shared between 
> packages. Trying to hide it, doesn't gain anything -- it only makes the 
> sharing implicit rather than explicit.
>
> When you are writing a "telegram-bot" you should know the request/response.
>
> However, when you are writing a "generic-bot" that works with "telegram" 
> then the solution is to implement some sort of translation layer and 
> provide a minimal API for the "generic-bot".
>
> In the end -- you will either have some shared artifact or a translation 
> layer. I see no way of escaping it.
>
> + Egon
>
> On Monday, 13 November 2017 09:48:07 UTC+2, dc0d wrote:
>>
>> Thanks!
>>
>> That's what I do, though not happy with it. I had to write some helper 
>> apps and scripts (I'm not fluent in playing with Go ast yet).
>>
>> An example would be the API to Telegram Bot (package 
>> ). Requests and 
>> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
>> Go structs are the one in question.
>>
>> As it can be seen, they are pretty big and bulky (can not be helped, it's 
>> how the Telegram API is). But passing them up/out, makes other packages, 
>> become dependent on *tgbotapi* package.
>>
>> As for functionality, interfaces work great. But for payloads that are 
>> being passed between packages (even if they are POGOs) I can not find a 
>> clean approach for sharing them.
>>
>> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>>
>>> One possibility is copy-paste the structure and convert at call 
>>> boundaries.
>>>
>>> https://play.golang.org/p/5LFw6U3yi6
>>>
>>> But, can you show a real-world example to ground the conversation?
>>>
>>> + Egon
>>>
>>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:

 It is a Go best practice to "accept interfaces, return concrete types". 
 Which helps greatly in implementing different architectures/designs (like 
 Clean Architecture or the like).

 There are times that a package is used which returns fat structs (as 
 the concrete type) - mostly POGO.

 Problem:
 Redefining some domain models for those payloads is cumbersome and 
 sometimes impractical. At the same time using them directly, exposes other 
 packages to that package that we want to abstract out it's functionality. 
 Some unwelcome dependency.

 Question:
 Should we redefined all those data types in upper layers for using 
 them? If no what is the solution?

>>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Bulky (Payload) Structs in API

[Egon]

Is there a problem created from sharing the package or creating a separate 
package? Or why is that dependency a problem?

There's some knowledge about the requests/responses shared between 
packages. Trying to hide it, doesn't gain anything -- it only makes the 
sharing implicit rather than explicit.

When you are writing a "telegram-bot" you should know the request/response.

However, when you are writing a "generic-bot" that works with "telegram" 
then the solution is to implement some sort of translation layer and 
provide a minimal API for the "generic-bot".

In the end -- you will either have some shared artifact or a translation 
layer. I see no way of escaping it.

+ Egon

On Monday, 13 November 2017 09:48:07 UTC+2, dc0d wrote:
>
> Thanks!
>
> That's what I do, though not happy with it. I had to write some helper 
> apps and scripts (I'm not fluent in playing with Go ast yet).
>
> An example would be the API to Telegram Bot (package 
> ). Requests and 
> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
> Go structs are the one in question.
>
> As it can be seen, they are pretty big and bulky (can not be helped, it's 
> how the Telegram API is). But passing them up/out, makes other packages, 
> become dependent on *tgbotapi* package.
>
> As for functionality, interfaces work great. But for payloads that are 
> being passed between packages (even if they are POGOs) I can not find a 
> clean approach for sharing them.
>
> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>
>> One possibility is copy-paste the structure and convert at call 
>> boundaries.
>>
>> https://play.golang.org/p/5LFw6U3yi6
>>
>> But, can you show a real-world example to ground the conversation?
>>
>> + Egon
>>
>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>>
>>> It is a Go best practice to "accept interfaces, return concrete types". 
>>> Which helps greatly in implementing different architectures/designs (like 
>>> Clean Architecture or the like).
>>>
>>> There are times that a package is used which returns fat structs (as the 
>>> concrete type) - mostly POGO.
>>>
>>> Problem:
>>> Redefining some domain models for those payloads is cumbersome and 
>>> sometimes impractical. At the same time using them directly, exposes other 
>>> packages to that package that we want to abstract out it's functionality. 
>>> Some unwelcome dependency.
>>>
>>> Question:
>>> Should we redefined all those data types in upper layers for using them? 
>>> If no what is the solution?
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Bulky (Payload) Structs in API

[dc0d]

BTW another approach that I've tried is to use Type Aliases. A third 
package created and type aliases (with the same names) defined for those 
POGO payloads.

Then type aliases (and interfaces) from this third package can be used in 
upper/other packages.

But I've not used it heavily because I still do not feel being confident 
that the approach is proper or not.

On Monday, November 13, 2017 at 11:18:07 AM UTC+3:30, dc0d wrote:
>
> Thanks!
>
> That's what I do, though not happy with it. I had to write some helper 
> apps and scripts (I'm not fluent in playing with Go ast yet).
>
> An example would be the API to Telegram Bot (package 
> ). Requests and 
> responses from the API are big, fat JSONs; wrapped up in Go structs. These 
> Go structs are the one in question.
>
> As it can be seen, they are pretty big and bulky (can not be helped, it's 
> how the Telegram API is). But passing them up/out, makes other packages, 
> become dependent on *tgbotapi* package.
>
> As for functionality, interfaces work great. But for payloads that are 
> being passed between packages (even if they are POGOs) I can not find a 
> clean approach for sharing them.
>
> On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>>
>> One possibility is copy-paste the structure and convert at call 
>> boundaries.
>>
>> https://play.golang.org/p/5LFw6U3yi6
>>
>> But, can you show a real-world example to ground the conversation?
>>
>> + Egon
>>
>> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>>
>>> It is a Go best practice to "accept interfaces, return concrete types". 
>>> Which helps greatly in implementing different architectures/designs (like 
>>> Clean Architecture or the like).
>>>
>>> There are times that a package is used which returns fat structs (as the 
>>> concrete type) - mostly POGO.
>>>
>>> Problem:
>>> Redefining some domain models for those payloads is cumbersome and 
>>> sometimes impractical. At the same time using them directly, exposes other 
>>> packages to that package that we want to abstract out it's functionality. 
>>> Some unwelcome dependency.
>>>
>>> Question:
>>> Should we redefined all those data types in upper layers for using them? 
>>> If no what is the solution?
>>>
>>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Bulky (Payload) Structs in API

[dc0d]

Thanks!

That's what I do, though not happy with it. I had to write some helper apps 
and scripts (I'm not fluent in playing with Go ast yet).

An example would be the API to Telegram Bot (package 
). Requests and 
responses from the API are big, fat JSONs; wrapped up in Go structs. These 
Go structs are the one in question.

As it can be seen, they are pretty big and bulky (can not be helped, it's 
how the Telegram API is). But passing them up/out, makes other packages, 
become dependent on *tgbotapi* package.

As for functionality, interfaces work great. But for payloads that are 
being passed between packages (even if they are POGOs) I can not find a 
clean approach for sharing them.

On Monday, November 13, 2017 at 11:05:07 AM UTC+3:30, Egon wrote:
>
> One possibility is copy-paste the structure and convert at call boundaries.
>
> https://play.golang.org/p/5LFw6U3yi6
>
> But, can you show a real-world example to ground the conversation?
>
> + Egon
>
> On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>>
>> It is a Go best practice to "accept interfaces, return concrete types". 
>> Which helps greatly in implementing different architectures/designs (like 
>> Clean Architecture or the like).
>>
>> There are times that a package is used which returns fat structs (as the 
>> concrete type) - mostly POGO.
>>
>> Problem:
>> Redefining some domain models for those payloads is cumbersome and 
>> sometimes impractical. At the same time using them directly, exposes other 
>> packages to that package that we want to abstract out it's functionality. 
>> Some unwelcome dependency.
>>
>> Question:
>> Should we redefined all those data types in upper layers for using them? 
>> If no what is the solution?
>>
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.

[go-nuts] Re: Bulky (Payload) Structs in API

[Egon]

One possibility is copy-paste the structure and convert at call boundaries.

https://play.golang.org/p/5LFw6U3yi6

But, can you show a real-world example to ground the conversation?

+ Egon

On Monday, 13 November 2017 08:48:18 UTC+2, dc0d wrote:
>
> It is a Go best practice to "accept interfaces, return concrete types". 
> Which helps greatly in implementing different architectures/designs (like 
> Clean Architecture or the like).
>
> There are times that a package is used which returns fat structs (as the 
> concrete type) - mostly POGO.
>
> Problem:
> Redefining some domain models for those payloads is cumbersome and 
> sometimes impractical. At the same time using them directly, exposes other 
> packages to that package that we want to abstract out it's functionality. 
> Some unwelcome dependency.
>
> Question:
> Should we redefined all those data types in upper layers for using them? 
> If no what is the solution?
>

-- 
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.
For more options, visit https://groups.google.com/d/optout.