electrify and meteor deploy

[srtucker22]

Hey there,

This is an awesome project.

Maybe a total noob question here, but is there a nice way to connect the electrify version my app to a deployed app (e.g. myapp.meteor.com)?

Was thinking about using this to make a desktop version of an open source video chatroom I've thrown together. Electrify version of the app works like a charm locally, but I'd want to be able to connect peers on different computers obviously :)

Thanks for your help!

[arboleya]

Hello @srtucker22! Thanks for the kind words.

Not a noob question, but a very common requested feature. It's currently not supported but there's a workaround to get this to work, and also another approach using another project.

The ability to package a desktop app in the same way Meteor currently does for ios and android is a must, so I'm gonna leave this open as an enhancement and list my first thoughts below.

Please interact if you have something to add to the table. :beers:

Supporting Client Version only

Supporting a client version only, connecting to a remote server, would imply in some tasks such as providing hot-code-push support (same as ios and android platforms does) and all the needed update routine for this to happen.

Would be cool to know how MDG has handled this kind of thing. Anyone?

Electron integration & Security Notes

One may also want to execute Electron commands from Meteor's client code (which will be running inside an Electron window). This behavior already exists and is supported in Electrify, but in this scenario I'm afraid we can fall into security questions.

Is it common for a remote backend to deliver arbitrary code to clients that can execute local (and potentially malicious) commands on user's machine?

[srtucker22]

Thanks for the awesome response, and a solid writeup at that. Currently investigating something similar to meteor-electron-client for my immediate needs. I've never built an electron app before -- as a meteor nut, I was just expecting something as simple as meteor add-platform desktop to already exist because everything else is typically laid out so nicely for devs.

But I'm totally with you. I think something of a combination of meteor-electron-client and electrify is what the community needs to get to something like meteor add-platform desktop. You could imagine writing something like Meteor.isDesktop much like Meteor.isCordova and fitting all your electron code in the rest of your app, calling electron specific methods ala electrify, hot-code-push support, etc. Desktop is really the last major platform meteor needs to conquer, so this is sorely needed.

I'll stay tuned to this thread, and update with any learnings once I go through the process.

Cheers! :beers:

[ramezrafla]

@arboleya, Amazing what you have done!

How I thought a client-only would work (which is the intended use case for Meteor, a full-stack App) is that the webview would open up the actual webpage deployed online (e.g. myapp.meteor.com) - so you don't have to worry about DDP issues, Electron behaves as a regular browser. But additional wrappers would allow the client code to interact with the user's machine (e.g. fullscreen) and provide a consistent cross-platform browser.

This has the added advantage of reverting back to Meteor's security paradigms. In fact, this is how most Chrome Apps I have seen work (just wrappers for an online source / webpage with local code to access specific user machine needs).

What do you think @arboleya, wouldn't this approach make life easier?

[arboleya]

Hi @ramezrafla, I see this as a first implementation, more simplistic and straight to the point.

But I wonder what are the benefits of caching files locally, with an auto-update routine, much like Meteor did with android and ios?

They did because it was a good design, or they did it because this was the only way to pack mobile apps?

I don't know if one can get an "empty" app, that launches remote a website inside of it, out in the AppStore or PlayStore. Do you know if it's possible?

While this can be a good reason they went down this way, I think this point should be further discussed with more research around the ios and android platforms.

[ramezrafla]

Hi @arboleya Thanks for the reply.

• For iOS, you cannot submit an empty shell app, you need some local content.
• For Android, you can do what you want, but of course, better implementation is a real client, especially for bandwidth. My experience with Android's is that they are not well implemented across the board (some devices are great, the rest are simply garbage). So the more is local the better off you are.
• Desktop, you can do what you want, not sure what the Mac App Store guidelines are, but using webview as a virtual machine and running inside of it, with native system access, is absolutely fine. This is how most ChromeBook apps function anyway.

So for the sake of speed of deployment, I am ok with a dumb client. Implementing custom DDP protocol for desktop is a headache and is unlikely to be needed universally (most Meteor Apps are fine running in the browser).

[arboleya]

@ramezrafla I agree about a dumb client before anything else to speed things up. However I see no reason for a "custom DDP" for desktop.

The only pending thing will be having client files locally, self-updating at each new hot-code push. But it can wait.

I think we have a first draft, I'll find the time to test this.

[hems]

i don't think security concerns should be considered at this very moment, the whole internet was running IE6 and Netspace 4 for "decades" and nobody died.

No to say, once you running an executable file on your machine, you are aware some weird things might be happening anyway ??

great work on the package, btw

[arboleya]

@hems Consider a man-in-the-middle attack, someone could deliver a clone app with their code inside it to your Electron window, and easily gain full access to your file system, keyboard, pressed keys, clipboard, screen, and everything else. This doesn't depends on trust between you and the app owner.

[ramezrafla]

Absolutely, it's up to the developer to make sure the code is secure, and that it is available in a trusted manner.

A cloned app that is similar to yours is likely the user's fault (they should download from your site). Insecure code, is the dev's fault.

Chrome apps are typically like this. A local sandbox accesses the local environment and it communicates securely with the app's back end online.

[hems]

@arboleya a man-in-the-middle attack could also delivery a totally different binary to you even when you download Skype, Chome, or Tor Browser.

ps: I'm not saying it's not a valid concern (( :

[arboleya]

Security is a valid concern, indeed. I'm also not the only one concerned, but it looks like there are some things one can do to deal with this insecurity. Just need to dig a little deeper.