Replies: 3 comments 3 replies
-
|
Could you explain why we can't use the higher level API client then? I am a bit confused by the statement :) |
Beta Was this translation helpful? Give feedback.
-
|
You can't use it without depending on the whole SDK because they live in the SDK, that's all. |
Beta Was this translation helpful? Give feedback.
-
|
ATM, the API repositories are simple: they are just gRPC APIs with auto-generated python stubs, and maybe in the future auto-generated rust stubs. Any additional functionality that the API implementation slaps on top of it will increase the scope of our API repositories, and will affect release cycles. E.g., there could be a bug in this upper layer, which we fix and make a patch release. However, this will not be a patch release of the API, but a bug fix in the upper layer interface. This will be confusing for users. Also, note that it will make adding PRs for API changes difficult, because then for every breaking API change, we will need to mandatorily update the python upper layer. IMO this should ideally be kept separated, because it will slow down API changes. Sorry, but I think it is a good idea to limit the scope of API repos, like the way we are doing now. |
Beta Was this translation helpful? Give feedback.
-
|
OK, I think these are valid points. I still don't like the monolithic approach of the SDK though, because it makes it hard for projects not needing the whole SDK unable to use parts that are useful on themselves without pulling the whole thing. But we can eventually make the Python API clients their own project. In fact, my long term vision of the SDK is that is is only (or at least mainly) just importing other projects and adding some glue code. By definition and SDK should be just that. But I think it is fine to keep the monolithic approach to move fast at first, and we can pull out projects as they mature and it makes sense, as we did with the channels project. |
Beta Was this translation helpful? Give feedback.
-
As far as such modular-monoliths are concerned, if we look at other examples, like android or .NET frameworks, we can see that these too cover a vast array of functionalities under one hood. But agreed that the repository hierarchy itself could be made more modular, as needed. Just as an idea, I think we can split the SDK features into two broad categories:
|
Beta Was this translation helpful? Give feedback.
-
|
I think we could split frequenz-specific stuff too, because the platform is expected to grow a lot, so maybe if you want to write an app that is only trading you don't want to pull all the code for dispatching, weather forecasting, microgrid handling, etc. if you don't need that. Is good to have and SDK that pulls all the tools needed to develop any project that uses the platform (for simplicity and easy start), but it would be nice to also allow using individual parts when needed. In any case, plans for the future, not now :) |
Beta Was this translation helpful? Give feedback.
-
We have higher level interfaces for gRPC APIs in the SDK (well, only the microgrid API for now, but we'll add more soon). Since these clients are very tightly coupled with the API itself, and it is generally useful to interact with the API using Python, I think it might make sense to move those clients to the APIs projects.
For example, #434 proposes to add a tool to produce a graphical representation of the component graph. This could use the API directly (and also be part of the microgrid API project), but if we do that we can't use the higher level API client, which is a shame.
Opinions @frequenz-floss/python-sdk-team and @frequenz-floss/api-team ?
Beta Was this translation helpful? Give feedback.
All reactions