Both our sdk and backend (once revamped) will be using essentially the same pydantic models to build and parse json in request bodies. Since we don't want to end up with conflicting schemas for EntrypointMetadata, PublishedGarden etc in both codebases, we should factor out the common models into their own package which both the sdk and backend can have as a dependency. A motivating example of this pattern is the globus-compute-common repo.
In the short term we can add the full sdk to the backend dependencies, but in the medium term I also think this can double as an excuse to revisit and possibly clean up our object hierarchy to make it more maintainable in the future.
Both our sdk and backend (once revamped) will be using essentially the same pydantic models to build and parse json in request bodies. Since we don't want to end up with conflicting schemas for
EntrypointMetadata,PublishedGardenetc in both codebases, we should factor out the common models into their own package which both the sdk and backend can have as a dependency. A motivating example of this pattern is the globus-compute-common repo.In the short term we can add the full sdk to the backend dependencies, but in the medium term I also think this can double as an excuse to revisit and possibly clean up our object hierarchy to make it more maintainable in the future.
Assumptions: