Hi Praneeth,

Thanks for putting this together. This looks really good to me.

Thanks,

Marcus

> On Jun 26, 2023, at 7:39 PM, Praneeth Kumar Chityala 
> <praneethchityal...@gmail.com> wrote:
> 
> You don't often get email from praneethchityal...@gmail.com. Learn why this 
> is important
> 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
>               • @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
>                       • provide grpc service in main: 
> https://github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/main.js#L13
>                       • injection grpc service in a view: 
> https://github.com/cyber-shuttle/cybershuttle-agent/blob/electron/cybershuttle-app/src/components/Signup.vue#L97C1-L97C71
>               • 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://github.com/cyber-shuttle/cybershuttle-server/tree/main/app-server . 
> 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://github.com/cyber-shuttle/cybershuttle-server/blob/main/envoy.yaml)
> 
> 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> 
> 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
> 
> 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
> > 
> 

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to