GitHub Universe 2017 - GitHub For Business, 1 Dec 2017

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: Interop's Labyrinth: Sharing Code Between Web & Electron Apps - GitHub Universe 2017

Description

Presented by Machisté Quintana, Slack.

One of Electron’s most compelling draws is the ability to not only build a desktop app with web technologies, but also to build around a pre-existing web app as a foundation. However, here there be dragons - performance hiccups, security vulnerabilities, and maintainability woes lurk in the shadows, waiting for you to unwittingly take a wrong turn. Come learn about best practices and common pitfalls to sharing code and UI components between the web and Electron worlds, learned from working on one of the most widely used production Electron apps.

About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.

For more information on GitHub Universe, check the website:
https://githubuniverse.com

A

All right thanks everybody for coming. My name is machiste I work as an engineer on the desktop team at SLAC I'm here today to talk to you all about some approaches to sharing code between electron apps and web apps, or put it another way we're going to be entering interrupts labyrinths together.

A

So it give you a little more background. I work on the cross platform, slack desktop app, so it's the one that runs natively on Mac, Windows and Linux, and it's no secret that this app is built on electron with web technologies, and this is a really compelling draw for electron, say you have a web app where you're working on a web app in tandem. Wouldn't it be cool if you could somehow rework this some way into an electron app into a desktop app. So y'all can go something like this start with a web app.

A

Okay, then you add electron of something some. There has to be some way to get these two pieces to glue together to interoperate together, and then you have your desktop app. But what is this missing piece whatever? Could it be? It's missing piece? Oh, it's a labyrinth, I'm, sorry to tell you this is in traps labyrinth.

A

This is the piece that will allow you to glue your web app with your electron app and we're gonna be entering it together, but don't worry they guide you all through it and we'll get through so today. First we're gonna be talking about why? Why I do this at all, then we're going to be going through some of the possible paths through interrupts labyrinth, and then we will summarize at the end.

A

So before we start running this maze first ask yourself: why are you building a desktop app when you already have a perfectly functional web app? You know it's a fair question. Honestly. The web platform has in Vault has evolved tremendously and there may it may very well be the case that does everything you need already so, for instance, if your reason for wanting to build an electron app is something like this.

A

You know you might want to think a little more, so I find it really helpful to first think through what capabilities your app can never have as a standard web app. So, for example, for slack this means having fine-grained control over native notifications for things like spell checking and language detection for screen sharing and calls for having native app tasks, tray task bar and context menus.

A

These are things that we can't currently get exactly the way we want with the web platform. So just take some moments before you enter into this maze at all. To think.

A

Through what capabilities your app wouldn't be able to have so some things to consider if you are interested in building a desktop app just to display a website in a dedicated window, a chrome app will be a much more secure option and you will avoid having to run this maze at all if you're building a to build some kind of browser, customized highly customized browser like app that can visit any arbitrary website. Electron is not the right choice for you. Electron is not a platform for building browsers and you'll avoid a lot of pain.

A

If you, if you look elsewhere for a solution there, alright, so once you've taken some time to think through what capabilities your app can't have as a standard web app- and you know you're ready to enter this maze. Let's do it so there's a path that seems you know it's pretty close by. Why don't we check that one out first, so this first path, we can call the shortcut also what could possibly go wrong so on our first path. This is what we would do.

A

We would just load your remote web app into electron, as if it were browser just like into a browser tab. This might be easier to visualize with some kind of diagram. So it's important to remember that electron is chromium and know'd combined into one runtime, and we do this by interacting with two primary processes. We have the main process which you can think of as the process that launched that sits in the background being able to launch browser windows, launch browser tabs in chrome, for instance, then we have the render process.

A

That is the browser tab. So keep this in mind as we go along, because these diagrams are going to get a bit more complex. So what we're doing is we're starting by creating some kind of browser window from within the main process and then we're pointing it at our remote web app.

A

So what does this look like? We're? Creating a new electron browser window object we're pointing this at our remote web. App with this very browser like method load, URL, much like if you typed in the URL in the address bar, then your web app will load with full access to node and electron api's.

A

So in short, your web page will be super powered and you can do things like require node modules use any number of node built-ins like access the file system- and this is you know it seems very promising, like all of a sudden, your web app will be able to have native desktop powers.

A

So what does this look like in code? A very very short example here. So this is exactly what I was describing. So we are creating a new browser window object and we're loading a URL into it and much like a browser tab. Alright.

A

So now that we've gone through what this path looks like, how do you think this will turn out? Let's find out.

A

No Oh No, Oh where'd. We go so wrong. Alright, let's talk about this, so there are some benefits or some boons to this approach and it's natural that you might be drawn to try this out yourself. It's definitely the simplest approach. It's also the one that you'll find many tutorials pointing you at at some point, but there are also a lot of pitfalls to watch out for so one thing, I find helpful when thinking about security concerns is to ask yourself: what are you trusting and what kind of risks might that trust expose you to?

A

So what are we trusting when we're loading our remote web app here into a browser window, so.

A

We're trusting remote and local content in this case. It's really the remote content. That is maybe worth a second look.

A

This remote web app has full access to node, so it can do anything. Absolutely anything. This means things like say, for instance, copying over all of the users files to a private server. This could be something like mining Bitcoin. These are probably things you don't want your app doing, but they could happen in some terrible case scenarios, so it in these terrible scenarios.

A

This approach can be wildly insecure if you're not incredibly careful about verifying the content that you are loading from your own remote web app and it's you know you it's it's not the default. You would have to bacon a lot of these verifications yourself, so might be worth keeping in mind. Don't trust remote content, even if you trust the source, because you know really think about what you're trusting and what risks you're exposing yourself to all right. So what's the verdict here, the shortcut path? We were just loading our remote web app into electron.

A

It's definitely the fastest and easiest path to implement, but it's really insecure. If you aren't careful so.

A

Don't do it, it's a trap, all right, so we tried that path out. It didn't quite work, but there's another path. It looks like right. Next door seems like it might be promising.

A

This path is the path of remote isolation or not so solitary confinement. So what was the problem with this first approach problem was that our remote web app had full access to node and note is extremely powerful.

A

Normally, it only runs on, say a server on the back end, which is why it has full access to everything that you know the user running note on that server would have access to meaning files, meaning network, but we have to be very mindful when we're doing this loading our remote web app in two-electron. Do we want that that look that same level of trust? Do we want to extend that same level of trust to our remote web app? So it seems like the problem.

A

Is our remote web app having unfettered access to node, so one way we might be able to get around? This is by gating access to node, and so we can do this by loading our remote web app in an isolated context of some kind. So what does that mean?

A

So remember our two processes. We have the main process, which is responsible for launching browser tabs essentially and a render process that actually renders the content in those tabs. So one of the things we can do is disable this access to node from within the renderer process.

A

You might be thinking, though, isn't that half the point of electron is having access to node from within your web page, and you would be right, but there is a way out here. What we can do, instead is define an Interop api via a preload script.

A

This preload script gets run before we actually create the render before we actually load our guest page into the renderer, and then from within this preload script, we can have access to node, so we can still expose some functionality to a remote web app, but without having complete access to node. So, okay, you do this by loading your remote web app inside of a browser window again or you can also load it inside an electron container. You might have heard of web view or a browser view.

A

It depends really on what you're looking for, for simplicity's sake, we're going to cover the browser window approach mostly today, but you might need to look into web view or browser view if you need to load multiple isolated contacts or you need to nest them for whatever reason. So, okay, that's the first step. It's pretty much the same as the last step, with the addition of the possibility of an electron container.

A

This is the crucial step, though, is that you need to disable node integration and enable context isolation, so node built-ins can't be accessed from within your guest page from your remote web app and your remote web. App can't go and do things like modify the prototypes of the elektron API itself that seems like it could be risky. Probably don't want that.

A

But you can still give your guests webpage or remote web app some superpowers by exposing a desktop Interop api and you define this in a preload script. So, let's dive into that a little more.

A

So this preload script, as I mentioned, is run before we load the remote, the remote guest page and before we run the remote guest page, we still have full access to node. So since we have access to node built-ins, we can design an API that exposes the absolute bare minimum that you need for your web app to do some kind of desktop magic to actually extend it into a native ish app all right. What does this look like in code?

A

So this is the more simple browser window approach. We are loading a browser window again, but this time we're setting some options on it, we're defining a preload script where we can define our Interop api. We are disabling node integration so that our remote web app doesn't have complete unfettered access to node and we're enabling context isolation so that we can't accidentally go and mutate the electron or node api's from within our remote web page. Ok, so jumping into the preload script, we are defining our Interop api.

A

So in this case, what we're doing is just setting a global in the window that will be injected into our remote web. App once it's it into the renderer, and so what we're doing is we are setting the badge count on our app icon.

A

So if you were on Mac OS, for instance, and like you ever see a badge with like a red number in it, that's exactly what we're doing here so we're exposing the ability to set this badge count and then from within our remote web, app from within the guest page that we're loading into this isolated context, we're checking for the existence of this Interop api and then calling a method on it, and so we have access to that method. But we do not have access to this remote method or this remote object.

A

We don't have access to require from node. We don't have access to any other node built-ins, but we do have access to whatever we expose on this Interop object. Okay, so are you ready to try this path out and see how it goes all right? Let's see what fine, oh, it seems so promising too. huh Okay, let's, let's talk through this, because there definitely some benefits here, so some boons to this approach.

A

There definitely some benefits to maintainability, so we are sharing the exact same client as our web app. This is pretty great because it means that we can take advantage of our remote web apps, continuous deployment processes. This me normally, if you're, really seeing a desktop app. You are constrained by things like App Store approval time and that can take you know anywhere from days to week. Who knows, and if you have a critical bug to fix this could potentially be an issue.

A

One other huge benefit is that your electron app should automatically have feature parity with your web, app assuming no bugs, of course, but in theory you should have feature parity as opposed to having to build a completely separate native client, where you would have to ensure that your new client meets all the same specs as your web app you just get that all for free. Essentially, there are, of course, some security benefits. So remember ask yourself again: what are you trusting and what kinds of risks might that expose you to?

A

So one of the things we're doing differently with this approach is we're no longer trusting remote content. We do still trust local content so like, for instance, our.

A

Our browser window, initialization logic, we would be shipping locally with our app, so we're still trusting that.

A

But we're no longer trusting our remote web app because it exposes us to risk that we may not be comfortable with, and so we're doing this by restricting access to node built-ins like require and third-party dependencies so with require you would be able to load any node module that happens to be shipped with your app and possibly any node module period.

A

If you were able to load it over the network, and that is quite a risk and probably not one that we want to expose our users to in theory, if compromised, the worst your remote web app would be able to do is abused your Interop API again in theory it'll. It always plays out differently in practice, so this renders it definitely more secure than our first path.

A

The shortcut there are some pitfalls to this approach, though this does add some amount of CPU and memory overhead, especially if you use an electron container like webview or browser view. Every container is its own separate process and that automatically adds some overhead. So that is something to keep in mind. If you are wary about memory, usage and performance, it's still possible to make your app really slow. This way, too, if you abuse, IPC message passages to communicate between the main process, the render process and your guest page or remote web app.

A

If you aren't careful, these calls can block threads and your users will experience a really slow hanging app. It's probably not what you want.

A

There are also some maintainability pitfalls.

A

One downside to this approach is that it's really really difficult to reuse parts of your remote web app. You really get all or nothing so. To give you an example say your web app had a really really nice modal dialogue, UI component, and you wanted to reuse that for something completely exclusive to desktop apps, say it's something like handling connections to remote corporate proxies or something, and you want to use a modal dialog from the web app you don't want to break style guy. That's that's a bad time for everyone.

A

So how would you do that with this approach? uh Well, you probably are gonna have to copy and paste it. It's it's sad, but true, because what you're doing is you are connecting to your remote web app? So unless your remote web app exposes something on the level of a single UI component like your modal, you aren't really going to be able to access it.

A

So that's unfortunate.

A

Another problem is that it encourages implicit dependencies on the global scope. This can be bad depending on what your web app is doing with the global scope. So remember that we are injecting our Interop API as a global on the window object, and this can be mutated, so any module anywhere in our web apps dependency tree can go in and modify our global and then sort of mutate. The state for some other components somewhere down the line, and this can make debugging really difficult.

A

If you aren't careful, so you could all- and if you aren't careful too, you could potentially conflict with other Global's in the web, app, especially if those come from any third-party dependencies that inject Global's, like some jQuery plugins, for instance,.

A

Another maintainability pitfall is that, depending on which isolated context approach you choose like whether you're going with the browser, few isolated context or sorry, the browser window, isolated context or webview, you may be creating a source of endless bugs for yourself and your users.

A

So let's say you decide you wanted the flexibility of being able to nest or create multiple contexts like if you needed multiple, completely separate instances of your remote web app running at a time, for example, or if you need to handle something like single sign-on, and so you decide to give webview a try since it lets you do this and regular browser window approach. Does not here's a little sampling of some webview bugs you might run into the render process could crash when you drag and drop something in there input method, editors or imes?

A

What users might use to enter Korea and Japanese or Chinese characters might render at one corner of the screen instead of at where the user is inputting their message when you're resizing the window, the webview might noticeably lag or just never resize at all navigation events might fire and consistently and break sign-in. Constant CPU usage might kill your battery life so just just a little sample of what bugs you might run into. If you try one of these electron container approaches, there are still some like things to consider about security too.

A

One thing, that's really important to keep in mind is that you must be extremely mindful when designing your Interop api I think it's helpful to sort of build a threat model of how your Interop methods could be abused in some of the worst case scenarios.

A

So, for example, don't do things like expose references to node modules, because that is exactly the same as being able to require them directly from your remote web. App don't expose like the require function you could just easily assign require to like window and then game over.

A

Don't expose generic IPC interfaces so, for instance, don't let your remote web app send arbitrary messages via IPC to your other processes, because that could also be disastrous. If you're not careful, it's a little fiddly to to really get full true, node context, isolation. You have to fiddle with a lot of knobs and levers and much more than I can go into detail about today.

A

Other things to consider, please, please make sure that you serve your remote web app over HTTPS. Otherwise, you know, there's really no point. Also. It's really helpful to define a robust content security policy so that you know you can't easily violate like cross-origin resource sharing policies and stuff, like that, and also very helpful, is to read through the entire electron security guide.

A

There are a lot of great tips in there that will help you around some of these issues and help you achieve full node context, isolation, all right, so there's a lot going on in that path. So what we were trying to do was gate access to node by loading your remote web app into an isolated context. It's definitely an improvement over the first path, where we were just loading it directly with no isolation whatsoever, but there are some performance, and/or maintainability costs. Still so should you try this out?

A

If you were planning on doing the shortcut path, then? Yes, definitely, this is better, but there might be other paths that work out better for us, let's find out.

A

So there's another path off to our right. It looks a little scary, though, not sure how this one will go for us, but let's find out this path is the path of local resources or, if you prefer, the cloister of trials. So what we're trying to do with this path is to build your desktop app as a separate client composed of shared local resources. Ok, what does that mean?

A

Let's take a look at a diagram Wow. It's escalated quickly, all right! So, let's break down what's going on here, so it looks like we've broken up our web app into discrete modules that we were then publishing to some kind of publicly accessible rectangle and then we're importing those somehow into our electron app.

A

Ok, it's probably what's going on here. Let's dive into this a little more oh one! Other thing I want to point out is: if you take a look at the renderer process, rather than pointing to a remote URL like HTTP, slash whatever we're now pointing to a file URL, so we're pointing to a local HTML file to boot, our remote web app. That's weird! huh Ok, let's dive into this a bit.

A

So, unlike the other two approaches, there are a lot of steps to this one so, but we'll get through it. I think there might be something good at the end of this path. So one of the first things you will want to do is to decouple your front end from your back end.

A

Why would you need to do this? It would be pretty difficult to reuse parts of your web app in your desktop app. If they depend on the server injecting some kind of state into them, then you it's not something you can handle entirely yourself without duplicating a lot of logic.

A

Another thing that you would want to do is to decouple your web apps UI components from data models. Why would you need to do this? Well, it's a lot easier to reuse, the same set of UI components if you can just plug a completely different model, and especially if the model you're plugging in is say a desktop specific model for your electron app. Then, all of a sudden, once you plug this new model in your same UI components, can do slightly different things in your desktop environment, and that sounds pretty good.

A

It sounds like what we might want.

A

Another thing we would want to do is to decouple front-end client from our globally scoped third-party dependencies, so I mentioned earlier, say if you had like jQuery plugins that were modifying prototypes or injecting Global's, we want to stop doing that, because that can make our modules unpredictable and harder to interoperate with each other.

A

So to think about it. Another way what we did with our first couple approaches it's kind of like if we had a Lego set, and we got the Lego set pre-built as a model and remember like oh, but it's not quite the, but not quite the right shape that we want. So then we went and got other pieces and then glued them on the smooth sides to try to turn it into the shape that we want. Well.

A

We're aiming for with this path is to take the same set of pieces from the same Lego set and assemble them into the shape that we want without having to resort to gluing things where they shouldn't belong.

A

So we can do this in part by extracting code from our remote web, app to discrete well-defined commonjs or es2015 modules.

A

Keep in mind that electron is chromium and node combined. So that means that we are working in a common jeaious environment means you load dependencies via require, or you know, eventually we're getting to a world where es2015 is supportive native support natively and then you can use native JavaScript imports.

A

So we need this to be able to interoperate our web app modules with our electron app. So then we probably need to make sure that our electron app can get to these modules somehow. So we can do this by publishing to some secure location that you can access from your electron, Apps repo. This could be something like a node module package registry like NPM enterprise or artifactory, or public NPM. If you're working on an open source project, you could also do something like working in a single repo and just requiring modules from local paths.

A

In that repo, you could use get sub modules. If you really wanted to. There are a lot of ways to approach this, although, like the package registry seems probably the most straightforward of these all right totally. There are a lot of steps next step is we want to import these modules as just regular old dependencies so that we can create a completely separate, desktop client? So I mentioned earlier that the other two approaches we were really sharing the exact same client as our remote web.

A

App this time, we're using our Lego blocks to build up a completely separate client from the same pieces all right once we have all this and we've imported everything we need to ship these modules and any other shared resources like fonts or images, style sheets and ship that, in our electron app bundle that we would eventually be publishing to the world.

A

Once this is all bundled together, then we can boot the app via a new browser window pointing to an HTML file. It's like an app shell sort of that points to our now local resources, some of which are shared with our remote web, app all right. That was a whole lot of steps. So let's look at a more simplified code example.

A

So in an imaginary world, where our entire app consists of a header and a sidebar and nothing else, we are importing our header and sidebar from our remote web app that we've extracted earlier and published to some location in this case we're using a package registry we're importing our desktop model that would be able to do things like interact with OSAP is maybe like bounce. The dock icon create native notifications and then in this pseudo react component.

A

We are passing it in as a prop that we can now use to do slightly different things based on whether this component lives in our electron app versus the web app, and so what we're really doing is we're building up a completely separate client from some of the same components in this case just UI components, but it need not be limited to you components you could be pulling in some like utility modules. It could be pieces of them.

A

The model itself could be coming from your remote web app, it's sort of sky's the limit here, all right. Where do you think this? Will it will end up? Let's find out? Okay, this seems promising. Okay, let's talk about some things that we get with this approach. So there are some maintainability boons. One thing: that's really great. Is we get ad duplication of efforts between our electron app and our remote web app? So, for example, I mentioned this imaginary modal dialogue. Before that we want to reuse from our remote web app.

A

So now we can just import it as we would any other third-party dependency and reuse and be like confident that we're reusing the exact same code paths that the web app is using, but we can be much more granular about what we want to use and how we want to use it. So we would have had to otherwise duplicate these components, ourselves duplicate the logic and that's not great- that can lead to bugs and inconsistencies that may frustrate your users.

A

There's some other maintainability benefits. It's encourages building loosely coupled encapsulated modules as building blocks for your app. This is awesome because it makes them a lot easier to test and it makes them a lot more predictable. So no longer, hopefully, will you have to worry about one module will get getting loaded and then interfering with the operation of another one. Unless that was your intent, hopefully they're definitely some boons to performance two.

A

You should see a much faster cold boot time because remember in our first two paths, we are loading our remote web app much like a browser. So the first time you ever open your desktop app. You have to make a remote network request period so, depending on your users, network environment that could take a while or you know it could be really painful on first boot, of course, you can cache things after first boot, but this this could be bad depending on how much you value startup time.

A

So again, we don't require a network connection to boot.this. Gets you part of the way to having an offline mode for your electron? If that's something you're interested in there should be less resource overhead fewer processes spawned, especially if you were using an electron container with the second path with the remote isolation path. So these are great. What else do we get so remember to ask yourself: what are you trusting? What risks might that expose you to?

A

In this case, we are avoiding the question of loading remote content altogether, but we do still trust our local content, because we are shipping. These extracted modules from a remote web, app with within our electron, app bundle.

A

All right, there are some pitfalls to this approach worth considering. This will require engineers working on your remote web, app to adopt some kind of package publishing and versioning workflow. This is really the most most maintainable way of sharing code between two projects, but it will require some process changes and that can take some time or some training to implement. It will force you to make some kind of call between having many repos and a mono repo.

A

So I mentioned earlier, you can publish the code you intend to share to a package registry, but where will that code live will live in your main web app repo? Will you split each module out into its own repo and then, if you do like you know, how are you gonna pull that into your web app? So these are you know decisions you will end up having to make one way or another. So it's something to consider.

A

One downfall is that you can say goodbye to continuous deployment. Unfortunately, so before, since we were loading, our remote web app anytime, anyone pushed say a bug-fix to our remote web app the next time your users would reload their app, they automatically get it. We didn't even have to do anything from the elektron side. That's not the case anymore. This could be a good thing depending on your luck. Really.

A

So, if say on your remote web app side, somebody shipped a bug after your last release, then users of your desktop app won't run into it. But if you're really unlucky and the bug was created right before you created your release from those same modules, then you know your users are kind of out of luck until you can convince App Store's to approve your your hotfix.

A

So this means that your electron app will always lag behind your web app to some degree. This might be okay depending on your priorities. So it's worth considering other things to consider how granular do you want to get in your component or dependency trees? So, for example, you could do something like have every component extracted and publish to import into your electron app. So that's the example we saw earlier in this imaginary world, where an app consists entirely of a header and a sidebar.

A

That's exactly what we're doing, but you could also just import your route UI component, so imagining we just have an app. That's all we extracted from our web app and that's all we're importing and we're trusting that from the web. App side that there are composing the pieces in the right way to work with electron so either way is a totally valid approach to go. It's just something worth considering.

A

So how would you maintain interfaces so adhering to semantic versioning helps, but you know humans, so it depends on or it relies on engineers actually bumping the major version of these modules when there are breaking changes, but it does help it's definitely better than like, not versioning at all, using some tooling to set up static type. Checking like warned if an API contract breaks without bumping major version number can also help definitely recommend using some automated tooling for this.

A

So if you have shared components that need to do different things in desktop land, you can just check for the existence of this special desktop model that we're passing in. For instance, then, you can just have separate code paths in your shared modules that are coming from your remote web app. That will do slightly different things if our desktop model exists all right.

A

There are some security considerations still does your app pull and remote data, and not just remote assets, not just your JavaScript or your HTML or your CSS that you need to load the site. Is any of this data user-generated? Do you need to handle cases like single sign-on? If any of these things are true, you might still need to run in an isolated context. Just shipping local assets might not be enough.

A

Remember to ask yourself what you're trusting alright. So, how did this go? This path was path. The local resources we build our desktop app as a separate client composed of shared local resources, give it a shot. There are definitely some trade-offs here, but there are plenty of benefits to go along with them. Alright, there's one more: we can try, add one more path: I'll see how this one goes. This is the hybrid path or I heard you like labyrinths, this one's kind of a mouthful.

A

So what we're doing with this is we're shipping, a local snapshot of common resources, resources that we've extracted from our web app and then we're going and updating them remotely with background Delta updates, but still in an isolated context. I think it helps to think of this, as we are combining path two and three and adding background updates. So we are getting context, isolation and we're also shipping local resources. So what would this look like?

A

We are shipping the most current versions of some shared modules at Build time in our app bundle, then we would do something like check for updates. In the background, we could do this with a custom updater that we build, or we could do this with a serviceworker possibly, and we would have to verify them, make sure that they are what we expect make sure that they're trusted.

A

Then, in the background, you can download a delta update. So only what has changed since the last update and then you can even maybe do something like hot load those changes. So your users don't have to reload your app okay. Why don't we go into this path and see what happens.

A

Yeah, it seems pretty futuristic here, so what we're aiming to do here is to strike some kind of balance between remote isolation and local resources, so we can get some of the performance and maintainability benefits of local resources, but still some of the trust benefits of remote isolation.

A

We, this is an approach. We're really excited about it slack and are actively investigating, but we're still learning a lot about it. So we don't entirely know what all of the pitfalls or the boons might be. So should you try this out, probably seems cool I mean I, think it's worth investigation, alright. So to summarize, in our first path, the shortcut we just loaded our web app into electron light as if it were a browser, didn't quite work out for us. It's a bit of a trap. I wouldn't recommend it.

A

Then we tried remote isolation where we gated access to node by loading a remote web app in an isolated context.

A

Definitely do it if you were looking at the shortcut path, but you might want to try out the third path, local resources, where we are building a completely separate client composed of shared local resources or the hybrid path where we're combining that with remote isolation and adding background Delta updates, probably it'll, probably work so with the power of electron comes the responsibility, your responsibility as electron app developers to navigate, interrupts labyrinth. So your users won't find themselves trapped in the pitfalls of the path that you chose. So in Interop labyrinth.

A

We must all face the choice between what's right and what is easy so in about a month or so, if you prefer, there will be an article version of this talk on our engineering blog slack that engineering, which is a real URL as it turns out it's not up yet. But if you're walking watching this talk in the future, it should be up check it out. There's a lot of other really great articles on our engineering blog if you're curious about some of the problems that we're trying to solve it slack.

A

So, thank you so much for having me and, very importantly, if any of this sounded interesting to you we're hiring. Thank you.

A