Revise `internal/neofs` package #235

New issue

Open

opened 2025-12-28 17:36:41 +00:00 by sami · 1 comment

sami commented

2025-12-28 17:36:41 +00:00

Owner

Originally created by @cthulhu-rider on GitHub (Jun 3, 2022).

Initial idea of creating a type nspcc-dev/neofs-s3-gw@dbfac29171/internal/neofs/neofs.go (L34) 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.

Originally created by @cthulhu-rider on GitHub (Jun 3, 2022). Initial idea of creating a type https://github.com/nspcc-dev/neofs-s3-gw/blob/dbfac29171c7acbb14700d7dd29924e397aa51bc/internal/neofs/neofs.go#L34 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.

sami added the

enhancement

good first issue

labels

2025-12-28 17:36:41 +00:00

sami commented

2025-12-28 17:36:41 +00:00

Author

Owner

@cthulhu-rider commented on GitHub (Jun 3, 2022):

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.

@cthulhu-rider commented on GitHub (Jun 3, 2022): ## 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.