# Cloning Capability API dependencies

What Spawn API dependencies should we reuse and what can be removed or replaced?
Note: This document doesn't take into account Sharks' plans to rewrite Spawn API in Go. There's no ETA for this refactoring at the moment, so we should have a plan on how to cooperate within the current codebase in the mid-term.

**Spawn.Engine <- IConnectionStringProvider**

It would be good to use the same connection string formatting both in CC and Spawn, because it's a core functionality xonsumed by end-users.
However, referencing whole Spawn.Engine only for this seems like an overkill.
**Verdict:** Extract this functionality into a separate package

**Spawn.Engine.String <- RandomStringGenerator**
Used to generate suffix for data containers' names.
Data container naming is an internal concern. There's no need to share it.
**Verdict:** Copy the code if we want to reuse it.

**Spawn.Kubernetes.Client <- ISpawnContainerLogRetriever**
Used to get container logs
While helper layer on top of Kubernetes can be a resonable reusable module, currently we use only 20 lines of code from there. Current architecture vision expects API no additional Kubernetes-related logic, so it's unlikely that we will have more sharable code.
However, CorrelationIDEnricher is also used by Spawn.Services.
**Verdict:** Reuse as a package?

**Spawn.Logging <- SpawnTemplateTextFormatter**
Used to set log formatting
Having similiar log formatting in Spawn and Cloning Capability can make debugging easier. However, because of a different environment Cloning Capability can have slighlty different logging expectations.
**Verdict:** Implement our own log formatting based on Spawn's format.

**Spawn.Messaging.Models**
Contains NATS message defintions
We will be sending the same messages and we want to be sure that they are exactly the same.
**Verdict:** Reuse as Nuget Package
**Note:** We should consider using code generation to make sure that the messages are the same in C# and Go.

**Spawn.Models**
Contains domain models (e.g. DataContainer)
Domain models is an internal concern. CloningCapability API should implement its own domain models, since they're going to be at least slightly different from Spawn's ones.
**Verdict:** Implement our own

**Spawn.Services <- IMessagePublisher**
Used to publish messages to NATS
This is a core integration bit. Reusing the same code helps us ensure that Cloning Capability is properly integrated with Spawn Core
**Verdict:** Reuse as Nuget Package

**Spawn.Store**
Used for database communication
Cloning Capaiblity is going to use its own database.
**Verdict:** Implement our own

**Spawn.Crypto**
Used for data container password encryption in Spawn.Store.
We are not resuing Spawn.Store, but we will need to decrypt password in our own implementation.
**Verdict:** Reuse as Nuget Package