You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@airavata.apache.org by Praneeth Kumar Chityala <pr...@gmail.com> on 2023/06/14 04:42:14 UTC
Architecture for Cybershuttle Orchestration App
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:
1. 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
2. Tauri in lighter (ex.180MB electonJS app vs 8MB Tauri app for just
"hello world" app) and faster when compared to electronJS
3. 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: image.png]
As we are brainstorming this architecture, any suggestions or comments are
welcomed.
Best Regards,
Praneeth Chityala
Re: Architecture for Cybershuttle Orchestration App
Posted by "Pamidighantam, Sudhakar V" <sp...@illinois.edu>.
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 <pr...@gmail.com>
Date: Monday, June 26, 2023 at 7:40 PM
To: dev@airavata.apache.org <de...@airavata.apache.org>, machrist@iu.edu <ma...@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 <ma...@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: 'aarmstro@example.com<ma...@example.com>'
},
{
firstName: 'Alex',
lastName: 'Applegate',
email: 'alexappl@example.com<ma...@example.com>'
},
{
firstName: 'Arnold',
lastName: 'Avanoff',
email: 'arnavano@example.com<ma...@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 <pr...@gmail.com>> wrote:
>
> You don't often get email from praneethchityala44@gmail.com<ma...@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
>
Re: Architecture for Cybershuttle Orchestration App
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
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 <pr...@gmail.com> wrote:
>
> You don't often get email from praneethchityala44@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 <ma...@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: 'aarmstro@example.com'
> },
> {
> firstName: 'Alex',
> lastName: 'Applegate',
> email: 'alexappl@example.com'
> },
> {
> firstName: 'Arnold',
> lastName: 'Avanoff',
> email: 'arnavano@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 <pr...@gmail.com> wrote:
> >
> > You don't often get email from praneethchityala44@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
> >
>
Re: Architecture for Cybershuttle Orchestration App
Posted by Praneeth Kumar Chityala <pr...@gmail.com>.
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 <ma...@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: 'aarmstro@example.com'
> },
> {
> firstName: 'Alex',
> lastName: 'Applegate',
> email: 'alexappl@example.com'
> },
> {
> firstName: 'Arnold',
> lastName: 'Avanoff',
> email: 'arnavano@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 <
> praneethchityala44@gmail.com> wrote:
> >
> > You don't often get email from praneethchityala44@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
> >
>
>
Re: Architecture for Cybershuttle Orchestration App
Posted by "Christie, Marcus Aaron" <ma...@iu.edu>.
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: 'aarmstro@example.com'
},
{
firstName: 'Alex',
lastName: 'Applegate',
email: 'alexappl@example.com'
},
{
firstName: 'Arnold',
lastName: 'Avanoff',
email: 'arnavano@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 <pr...@gmail.com> wrote:
>
> You don't often get email from praneethchityala44@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
>