Re: Architecture for Cybershuttle Orchestration App

[Christie, Marcus Aaron]

Hi Praneeth,

This looks good. I've been thinking about how we can reuse UI components that 
are developed for this local app in a web browser-based context. I think a good 
approach is a to create a service layer and then provide an implementation for 
those services when running in the desktop app. These implementations will 
communicate with a local gRPC client. But we can also create implementations of 
the same service interfaces that are implemented based on a REST proxy to the 
same gRPC services (or whatever will work within a web browser).

Vue 3 and Typescript have a dependency injection mechanism that make this 
pretty easy to work with. I put together a little demo app here: 
https://github.com/machristie/service-dependency-injection

I was able to create a service interface for "users":

export default interface UserService {
  getAll(): Promise<User[]>
}

And a couple different implementations (A and B) of this service, one of which 
is 

export default class UserServiceA implements UserService {
  getAll() {
    return Promise.resolve([
      {
        firstName: 'Ann',
        lastName: 'Armstrong',
        email: 'aarms...@example.com'
      },
      {
        firstName: 'Alex',
        lastName: 'Applegate',
        email: 'alexa...@example.com'
      },
      {
        firstName: 'Arnold',
        lastName: 'Avanoff',
        email: 'arnav...@example.com'
      }
    ])
  }
}


In the entry point for the app, I can "provide" either the A implementation or 
the B implementation:

const app = createApp(App)

app.provide(UserServiceKey, new UserServiceA())
// app.provide(UserServiceKey, new UserServiceB())


Then it's easy to inject the implementation anywhere in the Vue app. What I did 
was inject the user service into the user store:


export const useUserStore = defineStore('user', () => {
  const users = ref<User[]>()
  const userService = inject(UserServiceKey)

  async function loadUsers() {
    users.value = await userService?.getAll()
  }
  return {
    users,
    loadUsers
  }
})


More details are here: 

- https://vuejs.org/guide/components/provide-inject.html
- https://vuejs.org/guide/typescript/composition-api.html#typing-provide-inject

I don't want to dictate technology choices here, rather I'm suggesting that the 
UI layer should use some sort of dependency injection to inject the components 
that make network requests, and this is just an example of the general concept.


Thanks,

Marcus


> On Jun 14, 2023, at 12:42 AM, Praneeth Kumar Chityala 
> <praneethchityal...@gmail.com> wrote:
> 
> You don't often get email from praneethchityal...@gmail.com. Learn why this 
> is important
> Dear All,
> 
> I have been working on automating MFT agent deployment over compute 
> resources. As an extension to it I am also working on creating an UI for a 
> desktop application which can do the orchestration of MFT agent and 
> Cybershuttle services.
> 
> As MFT and cybershuttle are predominantly using protobufs and gRPC for 
> communication between the respective micro-services, I propose Tauri 
> (Frontend - JavaScript, HTML, CSS and Backend - Rust) into the architecture 
> to build the desktop UI application. I have also explored electronJS but 
> proposing Tauri for 3 key below reasons:
>       • electronJS uses NodeJS as backend which doesn't have integration with 
> gRPC yet, where as the Tauri used Rust which has production ready extension 
> to gRPC via Tonic
>       • Tauri in lighter (ex.180MB electonJS app vs 8MB Tauri app for just 
> "hello world" app) and faster when compared to electronJS
>       • As this proposed UI matures in future we might have to take some 
> heavy lifting tasks, Rust handles them much faster when compared to NodeJS
> Other quick comparisons of electronJS and Tauri are as below:
> 
> Feature       Electron        Tauri
> Runtime       Chromium and Node.js    WebAssembly and Rust
> App size      Larger  Smaller
> Startup time  Slower  Faster
> Maturity      More mature     Less mature
> Community     Larger community        Smaller community
> Security      Less secure     More secure
> Potential     High potential  High potential
> 
> The architecture would look something like below:
> 
> <image.png>
> 
> As we are brainstorming this architecture, any suggestions or comments are 
> welcomed.
> 
> Best Regards,
> Praneeth Chityala
> 

smime.p7s
Description: S/MIME cryptographic signature