Praneeth,

We have an example in the SEAGrid electron  client that you may want to look 
at. Please see the link from sharepoint below. Please let me know if you want a 
quick demo of this.

https://indiana-my.sharepoint.com/:u:/r/personal/pamidigs_iu_edu/Documents/Projects/SEAGrid/SEAGrid_Client.dmg?csf=1&web=1&e=vgMcTg


Thanks,
Sudhakar.

From: Praneeth Kumar Chityala <praneethchityal...@gmail.com>
Date: Monday, June 26, 2023 at 7:40 PM
To: dev@airavata.apache.org <dev@airavata.apache.org>, machr...@iu.edu 
<machr...@iu.edu>
Subject: Re: Architecture for Cybershuttle Orchestration App
Dear Marcus and All,

Thank you for the valuable feedback. I did incorporate the services as 
suggested.

Below is the design choices I finally picked and implemented a couple of 
services:

  *   For the desktop app I went ahead with the electronJS+Vue3 setup. As 
electronJS is more widely adopted and easier to migrate electronJS apps to web 
apps, electronJS is selected over Tauri.
  *   For the client side communication used grpc-web, which has a new 
implementation of gRPC which can be used on the browser side as well.
  *   Electronjs app code can be accessed with 
https://github.com/cyber-shuttle/cybershuttle-agent/tree/electron/cybershuttle-app<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-agent/tree/electron/cybershuttle-app__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXRLH8vz8w$>

     *   @Marcus As suggested by you used provide-inject with the userService 
pointing to UserServiceGrpc, which can updated to other services as needed

        *   UserServiceGrpc service: 
https://github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/api/grpc/auth.js<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/api/grpc/auth.js__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXQYfKk63Q$>
        *   provide grpc service in main: 
https://github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/main.js#L13<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/main.js*L13__;Iw!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXRxbQl8oA$>
        *   injection grpc service in a view: 
https://github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/components/Signup.vue#L97C1-L97C71<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/components/Signup.vue*L97C1-L97C71__;Iw!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXSSxgcmOA$>

     *   For now I went ahead and built the total app with JavaScript as 
official grpc-web has good support for it.
     *   @Marcus please let me know if this implementation looks good to start 
with.

  *   Server side is built with Springboot and java 
(server<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-server/tree/main/app-server__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXTNXDbXEQ$>:
 
https://github.com/cyber-shuttle/cybershuttle-server/tree/main/app-server<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-server/tree/main/app-server__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXTNXDbXEQ$>
 . It for not reads clients request and respond with static data)
  *   As grpc-web sends request with http1 and gRPC server works on http2, used 
an envoy proxy server to mediate the communication between client and server 
(envoy 
proxy<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-server/blob/main/envoy.yaml__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXQiNR7z9w$>
 - 
https://github.com/cyber-shuttle/cybershuttle-server/blob/main/envoy.yaml<https://urldefense.com/v3/__https:/github.com/cyber-shuttle/cybershuttle-server/blob/main/envoy.yaml__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXQiNR7z9w$>)

I will be working on building the Appview where users will be able to see 
available applications/projects to launch from the desktop app.

Best,
Praneeth


On Fri, Jun 23, 2023 at 9:27 AM Christie, Marcus Aaron 
<machr...@iu.edu<mailto:machr...@iu.edu>> wrote:
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<https://urldefense.com/v3/__https:/github.com/machristie/service-dependency-injection__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXTBR2UmRA$>

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<mailto:aarms...@example.com>'
      },
      {
        firstName: 'Alex',
        lastName: 'Applegate',
        email: 'alexa...@example.com<mailto:alexa...@example.com>'
      },
      {
        firstName: 'Arnold',
        lastName: 'Avanoff',
        email: 'arnav...@example.com<mailto: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://urldefense.com/v3/__https:/vuejs.org/guide/components/provide-inject.html__;!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXR2L47pQA$>
- 
https://vuejs.org/guide/typescript/composition-api.html#typing-provide-inject<https://urldefense.com/v3/__https:/vuejs.org/guide/typescript/composition-api.html*typing-provide-inject__;Iw!!DZ3fjg!9-FMCuUrkI9eCAN_UxgOEAhPPTmHo4rYB83HbBizdeUxp7I0AqagtxTZ2OOHfH4W7zk4qEKpSWOMCC15381JYXRwH1ojpg$>

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<mailto:praneethchityal...@gmail.com>> wrote:
>
> You don't often get email from 
> praneethchityal...@gmail.com<mailto: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
>

Reply via email to