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> : 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> - 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 > > > >
