In Go you can ignore the error value though, and use directly the returned value (`int` in your example). In Rust you cannot do that, you need to unwrap the Result or use the `?`
I believe in the majority of cases SSE are a better technology than web sockets (e.g. WS do not seem to conform to HTTP/2.0, SSE offer transparent (browser-supported) reconnects, SSE event ids allow for replay, etc). The downside is no support in IE/Edge (you can vote at https://goo.gl/bd8V1K), no binary content (but again usually JSON is enough) and no fully bidirectional communication.
I am a bit puzzled about the scalability of listen/notify in Postgres and its use in the article. Each "listener" in the code requires a connection in the database so it's not a good design to have one listen "query" for each user. You will probably need a dedicated connection in a thread (or a limited number of connections) for the database listening functionality. You can possibly use some async PG driver but still on the database end I am not sure how efficient and scalable this solution will be.
I can assume that this is a good solution if you don't have (need) a high rate of "notify" statements and a high number of subscribers waiting on "listen". Any comments on these limits of PostgreSQL?
Well, he recommends to stick to a specific schedule (having a walk at 21:30, going to sleep at 22:00, waking up at 06:00, etc) The exact times do not really matter, but sticking to a specific time schedule is problematic IMHO when you have a family because of the non-determinism introduced (especially by the kids).. Unless everyone in your family agrees to follow (and stick to) a similar schedule..
> This re-imagines passwords as nouns. As a side effect, you get a complete log of whenever anyone changes their password or requests to reset it.
> Want to enforce password reuse policies? Do analysis of password lifetimes? Track down malicious abuse of your password reset system?
> Those things are now pretty easy with a schema like this
I am also proponent of the more "resource oriented" view of an application but I fail to see how the CRUD approach you proposed is unique in order to support the above.. Because, all of the things that you mentioned can be also implemented/supported if you transmit the tokens in query strings. I.e. /password/:token and /reset_password/?token=:token are more or less the same thing from the REST point of view although the first is more user friendly, cache friedly, etc. After all URIs are opaque to the client: http://www.w3.org/DesignIssues/Axioms.html#opaque and that's where HATEOAS enters so the client just needs to know a single (bookmark) URI and the hypermedia will guide to the creation of the rest resource identifiers needed by the application (HATEOAS is indeed the "highest level" of REST: http://martinfowler.com/articles/richardsonMaturityModel.htm...).
Unless you mean that by following the 'noun'-oriented view of the password tokens you can easily spot these operations in the apache logs.. to which I agree if you also include the user id in these URIs...
I have implemented such a functionality for real time monitoring using gevent and works extremely well. This HTML5 feature is supported in recent versions of Chrome, Opera, and Safari and in the beta versions of Firefox, but not in any version of IE: http://caniuse.com/#feat=eventsource