Hazel: Lighweight update server for Electron apps | Hacker News Reader

Hazel: Lighweight update server for Electron apps

github.com

69 pointsnozzlegear21 comments

A philosophical question: how does the author reconcile his source code being full of ".js" files and saying "lightweight" with a straight face?

And a more practical one: do they not teach people about how power management works anymore? Who thinks this is a good idea...?

  Refreshes the cache every 15 minutes (use INTERVAL environment value for custom number of minutes - more)

Do you update your app every 15 minutes? And are you presumptuous enough to assume your users need each update immediately? Maybe you simply just not care for users' devices' battery lives? If you really insist on the NIH approach to updates, check at app launch time, or once every 24 hours at most for long-running apps..

and then

  Automatically detects the platform/OS of the visitor by parsing the user agent

When did it become OK to trust user agent strings for feature or device detection?

As far as I understand it the cache is a server-side thing, so the update server is polling github every 15 minutes, not the Electron app.

if it runs remotely, then why doesn’t the app just pull from github directly. why an intermediary? something doesn't add up

If your app ever gets popular and causes unreasonable traffic to your GitHub repo, or if GitHub decides they hate you for any other reason, your app will work only by GitHub's mercy and generosity.

> When did it become OK to trust user agent strings for feature or device detection?

I never really understood the complaint against this. UA string detection is good enough 99.99% of the time and sure it's not trustworthy in the sense that the end user can mess with it, but so what? If the user is messing with the the string they know what they're doing.

> UA string detection is good enough 99.99% of the time

I don't believe you, show me the data to back up such assumption.

Why would a browser lie?

Because of this — http://webaim.org/blog/user-agent-string-history/

my own experience? I've been developing for the web for 19 years. I know the issues with UA strings. It's an old argument. On the modern web, for the most part UA sniffing isn't necessary. If you do need it, there are plenty of libraries that will very reliably sniff strings which account for 99.99% of the web. Possibly mobile strings are an issue, but there are services like http://wurfl.sourceforge.net/ which will again get you to your 99%+ range. Of course do all the other things like feature detection, graceful degradation and progressive enhancement, but I find the entire argument a bit overblown.

> Do you update your app every 15 minutes? And are you presumptuous enough to assume your users need each update immediately?

I don't think you quite understand that this project is the server side, so the every 15 minute update frequency (which is user configurable) controls how often the server polls GitHub.

Apparently it's for the server-side component, but even then... Polling every 15 minutes seems like such overkill.

He could register a webhook for ReleaseEvent [0]. To make the process fault-tolerant, he could also have a daily check.

[0] https://developer.github.com/v3/activity/events/types/#relea...

Nothing about this seems to be 'for Electron apps'?

It just sits between the app looking for an update and Github releases; returns the latest release if newer than a supplied version number assumed to be the current.

Is it really so bad to have that `if latest.version > version` logic in the app itself, and download directly from Github?

Github releases are presumably pushed over a CDN and already well-cached - and almost certainly have better up-time than someone running an instance of this somewhere, which of course is still potentially victim to Github's down-time.

Have I missed something? What's the point?

If this works as described, it will be a lifesaver.

I've been running nuts on Heroku for my Electron app and never got it fully working. (It was very good at being able to tell there was an update available, but performing the update wouldn't work)

Does it work for Linux AppImage installs?

This doesn't seem to do any actual updating, it just tells the client the download URL of the latest github release.

Why does every app need its own auto-updater instead of using the OS?

Does windows provide an updater for apps..? I bet they don't on XP or 7, which are still highly used.

Also, I bet it's far easier to write an auto-updater than it is to figure out each OS's update method (building a deb,rpm,etc)

You don't have to, there's tools that do it for you.

> I bet it's far easier to write an auto-updater than it is to figure out each OS's update method (building a deb,rpm,etc)

Write some POS 'blindly overwrite files, no you can't downgrade, what do you mean "changelog"' updater?

Sure, I bet you can do.

Write something that handles user preferences, changed config files, conflicts etc as well as apt/dpkg? I doubt it.

For Windows, you can literally just type `now` in the Releases directory. No micro server needed. Great project though, sorry all those years ago I couldn't convince the Squirrel.Mac folx to do it my way.

I have been looking for something that combines this and something for Cordova like m$ codepush all in one any ideas?

Nice!

Reply on news.ycombinator.com