# Current Architecture evm-cli

package "Actor" {
    [user]
}

package "Client" {
  [evm-cli]
}
[user] -> [evm-cli]

# New Architecture evm-cli

package "Actor" {
    [user]
}

package "Client" {
  [evm-cli]
}

cloud {
  [evm-cli-content]  
}
[user] --> [evm-cli]
[evm-cli] --> [evm-cli-content]

# Sequence current architect evm-cli (service gen)

actor user as u
entity "evm-cli" as cli
database "s3"
u -> cli: Generate Boilerplate
cli -> s3: Get Template
s3 -> cli: Return Template
cli -> cli: Generate Boilerplate Content
cli -> u: Generate Boilerplate Files

# Sequence new architect evm-cli (service gen)

actor user as u
entity "evm-cli" as cli
entity "evm-cli-content" as content
u -> cli: Generate Boilerplate
cli -> content: Send Directory and DDL
content -> content: Generate Boilerplate Content
content -> cli: Return Generated Boilerplate Content
cli -> u: Generate Boilerplate Files

# Opsi 1

Pros:
- We dont need to send any data to server on every changes
-

Cons:
- if we often doing update, user will download updates more frequent
- Will having complex algorithm when auto update

# Opsi 2 (v)

Pros:
- Less update in user side (client app)
- Easily tracking user behaviour
- More fun to develop
-
Cons:
- Transactional will having big request
- Need flexible design in client app that the command will be controlled by server app