Comments (11)
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. 🍻
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?
from electrify.
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! 🍻
from electrify.
@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?
from electrify.
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.
from electrify.
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).
from electrify.
@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.
from electrify.
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
from electrify.
@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.
from electrify.
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.
from electrify.
@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 (( :
from electrify.
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.
from electrify.
Related Issues (20)
- Using --icon when packaging HOT 2
- Method was not defined HOT 1
- Dependencies path length too long in Windows HOT 2
- Issue starting mongod - default storage engine not available HOT 18
- convert from webapp to desktop HOT 3
- Defining methods causes the app to crash HOT 1
- Setting system environment variables before meteor app is started. HOT 2
- Try to package starting example of meteor HOT 4
- How do I build debian package from generated app?
- App size grows with every run of electrify by about 400 MB (MacOS) HOT 1
- my-electrified-app.exe can not start
- No way to pass in --server option? HOT 1
- alternative solution -> meteor-desktop HOT 1
- How-to allow localhost:3000 in package ? HOT 1
- App does not render when packaged - Windows 10 x64 - WinXP x32 HOT 2
- electrify:meteor:index@client: cannot initialize connection. Did you `npm install -g electrify`?
- Error: EPERM: operation not permitted, rename 'C:\Users\username\AppData\Local\Temp\electrify\package' -> 'C:\appname\.electrify\.dist' HOT 1
- show error : core.require HOT 1
- Don't let this die... HOT 2
- Issue starting mongod HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from electrify.