These are chat archives for gdg-x/hub

19th
Dec 2015
Michael Prentice
@Splaktar
Dec 19 2015 00:00
We already are using OAuth for site login. We need some help with protecting some of our APIs with OAuth as well. Some work has been done there, but no one is too familiar with it now. Someone with JWT and Passport expertise with time to help on this is badly needed.
We are using the HTTP Load Balancer. Our HTTP cache headers could use a review to make sure that they are configured to work properly.
We explored Managed VMs with Node.js, but Google was rebooting them constantly and it was impossible to keep them on a static IP plus any HTTP Load Balancer rules seemed to get broken with each reboot cycle. Plus Managed VMs are Beta, not production ready (very buggy). We would rather move to using the Container Engine.
Michael Prentice
@Splaktar
Dec 19 2015 00:05
But that’s again just something that I haven’t had time to get to. Most of my work over the last 6 months has just been to get the Hub up and running again and then work through bugs and track down issues. Re-factoring and re-arcitecture has not been something I have had much free time for.
Alex Van Boxel
@alexvanboxel
Dec 19 2015 10:12
@Splaktar : thanks for getting me up to speed. First about the rule: I deleted the rule yesterday (it was still open for attack), I doesn't look like a rule that the deployment manager created (I just did a create with the deployment manager on my project and I didn't see a rule popping up) -> so I don't think you need to report this.
@Splaktar : I understand you're pain of keeping it up and running, let me propose 2 things I could help you with. First of all, eliminate Redis (I don't see it as a valid use-case here), this will make the service less complex. And I help with the headers (need to be correct if we eliminate Redis).
Alex Van Boxel
@alexvanboxel
Dec 19 2015 10:17
I could have a look at passport.js for the API (I'm not an expert in node.js, but I am in API design). Or if somebody else picks it up, I would be happy to review
@Splaktar : if you like help or tips to get it on GKE I can always give you a hand. Although I think it's a bit overkill for the use-case...
Friedger Müffke
@friedger
Dec 19 2015 10:39
@alexvanboxel do you know if the situation with managed VMs has been improved? It sounds like the best solution. As GDGs are living on the edge, I would take the risk of using beta versions. However, we would need a concensus here.
Alex Van Boxel
@alexvanboxel
Dec 19 2015 15:15
@friedger : I would first cut out Redis after that you can decide one way or the other. Having that makes it more flexible... I will have a look over the holidays (making sure I didn't miss anything).
Michael Prentice
@Splaktar
Dec 19 2015 15:17
Where would you propose that we do the API rate handling /limiting if we dump Redis? In Mongo? Or can we reach app engine's memcache from a GCE VM?
Why would managed VMs seem like a better solution than Container Engine?
@alexvanboxel the activity log says that I created that rule at the same time that I spun up the latest Redis deployment. I certainly did not create the rule though. I actually verified that no such rule existed. Then sometime later (next day) it appeared and you removed it.
Alex Van Boxel
@alexvanboxel
Dec 19 2015 16:56
@Splaktar : about the rule, you are right about it... seems scary to have this rule created by the deployment manager...
@Splaktar : rate limit, I would not do it at all. Most api calls are open anyway so they could be cached at Google's Edge Cache if the no-cache header is removed
Alex Van Boxel
@alexvanboxel
Dec 19 2015 17:04
I was at an flash-sale webshop and we have thousands of customers hitting our API at the same time. Edge caching will make sure the load on the system is very low (even 15 second caching for some API calls does wonders)
Michael Prentice
@Splaktar
Dec 19 2015 17:50
OK, should be fine. I'm not sure why Sebastian thought it was necessary originally