I love to demonize big tech as much as the next guy, but I really think the public consensus in India against Internet.org is inherently biased. The catalyst for the movement was a Youtube video. The chosen method of lodging protest was via email. AIB themselves would not be the thought leaders they are today if internet access was restricted to them. Every activist has been, by definition, in a position of privilege with respect to internet access. It seems we are cautiously ignoring the situation of the millions who have not had internet penetration till date and to whom the internet is broadly synonymous with "major" services like Facebook and Wikipedia. I am not in favor of Facebook forming their own internet cartel and I think anti-trust laws should work tirelessly to prevent that. But I think if you gave the average unconnected Indian a choice between no internet on ideological principles, and free internet, but restricted to Facebook and a few other services, they would choose connectivity any day of the week
ekimekim summarized the reasoning quite well - primarily it was because I wed myself to HTTP early on in the project. To the question of knowing where the service registry itself lives, that is the one dependency which cannot (to my knowledge) be resolved dynamically. A persistent DNS record, which you update whenever the registry location changes, is the best I can think of atm.
Would someone care the elaborate on the following?:
"They use nginx to route requests to either the microservices or the main Ruby app... The Go microservices treat the Ruby application as an API client or upstream proxy, which allows authentication to be simple."
What I read this to mean is that the Ruby app accesses the microservices over HTTP with some kind of token-based authentication. This would make sense if there some form of shared session store which each microservice could validate the token against. What I'm confused about is how nginx fits into this? Is it routing requests directly from the client to microservices? Or is it a proxy layer in between the Ruby app server and the microservices which allows the Ruby app to forward auth-token information? In the former scenario, would the Ruby app server be pinging the same nginx instance that forwards it requests in the first place?
This, I like. I'm interested in seeing a progression towards client-side code assembled around libraries like intercooler.js rather than frameworks. I'd like to be able to pick and choose libraries to handle DI, routing, templating, HTTP et cetera in a manner that allows me to tweak/override as needed. I'm fine with foregoing the prescriptive structure that a framework like AngularJS lends to an app - structure is something you will spend time thinking about framework or not, and enough tools exist to let you write modular client-side code without being prescriptive