Revise internal/neofs package

[cthulhu-rider]

Initial idea of ​​creating a type

neofs-s3-gw/internal/neofs/neofs.go

Line 34 in dbfac29

type NeoFS struct {

was to have a mediator between NeoFS system and all S3 needs.

After subsequent refactors its orientation has been changed to providing application-specific features. I suggest to revise this architecture.

I can think of two possible approaches

internal/neofs - global window into NeoFS

We get rid of any app-specific info from internal/neofs package. It imports only NeoFS SDK Go functionality. NeoFS type provides full functionality required within the framework of S3 needs, but can be used as an autonomous entitiy (true mediator). Each application implements its NeoFS-related needs locally through single internal/neofs.NeoFS type. Seems like

app_1 <=== local dependency (multi-interface struct) <=== internal/neofs.NeoFS
app_2 <=== local dependency (multi-interface struct) <=== internal/neofs.NeoFS

Some local dependencies can be similar, but the are not the same.

internal/neofs - collection of implementations

Differs with previous approach that each type in the internal/neofs package is an implementation of one dependency of one application. The mediator mentioned in the first approach is also present, but it is not exported from the package. Seems like

app_1 <=== local dependency (interface) <=== internal/neofs.NeoFS_App1 (multi-interface struct) [private] <=== internal/neofs.neofs]
app_2 <=== local dependency (interface) <=== internal/neofs.NeoFS_App2 (multi-interface struct) [private] <=== internal/neofs.neofs]

As for me, first approach looks clearer. In both approaches, I consider it important to loosen the coupling of types between applications.

[cthulhu-rider]

Future proposal

We can go further and develop internal/neofs layer into a full-fledged intermediate layer between NeoFS (SDK actually) and S3 needs. I find it extremely useful for the following reasons:

• everything that S3 services need from NeoFS at a glance
• simple and controlled update of the SDK version
• accumulation of practices of using SDK, which can be incorporated into proposals and even supported natively
• almost zero performance overhead: type wrappers doesn't require any extra runtime memory and exist only in source code

Cons: it takes time to implement in the current code base. But if the proposal comes in, I can contribute to the implementation.