SDK package organisation

This topic is about the organization of the package SDK and its consequences on the package service/grpc.

I would like to propose the following rules:

Package SDK

  • helper init dependencies function
  • initialize sub-package in New
  • only expose publicly sub-package instance

SDK sub-packages (eg: sdk/execution)

  • initialized by SDK with all dependencies
  • should read / write to only one specific data
  • should call function from other sub-packages if need to read / write from other data
  • dependency between sub-packages should respect the way the data are (eg: instance dependent on service, so sub-package instance can dependant on package service, but not the other way)

Package server/grpc

  • only dependant on SDK
  • each api should call one write function of a SDK sub-package
  • each api can call multiple read functions from SDK sub-packages for error verification (eg: check that instances doesn’t exist before deleting a service)
  • if an api need to call multiple write functions from SDK, a new SDK sub-package should be created to handle it.

@core what do you think?

I’m don’t like such split. I think sdk should remain in one direcotry as long as possible.

reasons:

  • the engine will have 3 or more execution package (sdk/execution, execution, grpc/api/execution?)
  • there will be a mess while talking about each of execution
  • it will be easy to create import cyclic (and it forcing to create helper package or similar)

Also:

  • this split should come naturally when sdk growths and we will have problems with managing it and it will require normal refactoring.

What you are trying to do is refactor (organize too much) before even start coding.

Note: the same is with grpc package.

Actually, grpc package doesn’t follow the same logic as sdk, see Server/grpc package organisation

I agree with you that splitting in sub package will come naturally as the sdk package grows in size.
I don’t want to force but I want to give guidelines for long time development.

Let’s implement stuff :wink: