Data Infrastructure at IFTTT
engineering.ifttt.com
Data Infrastructure at IFTTT
1–10 of 25 posts
Re: Data Infrastructure at IFTTT
#2Can a moderator such as dang fix this please?
Re: Data Infrastructure at IFTTT
#3> This way if you query Elasticsearch to find all API errors in the last hour, it can find the answer by looking at a single index, increasing efficiency.
This is a really good way to know if third party APIs are having problems. Staying up to date with all those APIs they support must take up significant amount of engineering effort. Many APIs are just second-class citizens for their product owners. Bugs are introduced, changes are made without announcements, and even if there are announcements when you're dealing with so many different APIs it's hard work keeping track of them all and making changes in your app to keep it running especially when APIs are turned off, or schema changes are happening. This seems to be the hard problem IFTTT is solving, integrating into APIs.
I'd shy away from starting a project that involves so many other companies APIs just because of how hard of a problem that is to manage, but IFTTT is doing a great job here.
Re: Data Infrastructure at IFTTT
#4Original link: http://engineering.ifttt.com/data/2015/10/14/data-infrastruc... Can a moderator such as dang fix this please?
Re: Data Infrastructure at IFTTT
#5Original link: http://engineering.ifttt.com/data/2015/10/14/data-infrastruc... Can a moderator such as dang fix this please?
He is probably just syndicating this to medium with the new api's introduced.
Re: Data Infrastructure at IFTTT
#6Earlier quoted context omitted.
He is probably just syndicating this to medium with the new api's introduced.
To hijack your tongue-in-cheek comment...I genuinely would appreciate it if someone, at some point, looked at analytics before and after syndicating to Medium to not just compare number of visitors between the original blog and Medium, but whether PageRank for the original blog dropped due to duplication penalties applied by Google's algorithm.
I don't think they would have done that if there was a knowing SEO downside. It would hurt everyone.
Re: Data Infrastructure at IFTTT
#7Just found this one. Managing your data archive in the AWS Cloud http://cloudacademy.com/blog/managing-your-data-archive-in-t...
Re: Data Infrastructure at IFTTT
#8Re: Data Infrastructure at IFTTT
#9Earlier quoted context omitted.
To hijack your tongue-in-cheek comment...I genuinely would appreciate it if someone, at some point, looked at analytics before and after syndicating to Medium to not just compare number of visitors between the original blog and Medium, but whether PageRank for the original blog dropped due to duplication penalties applied by Google's algorithm.
It's worth nothing that Medium described this syndication workflow as an expected use case during the announcement. I don't think they would have done that if there was a knowing SEO downside. It would hurt everyone.
It would be relatively easy for Medium to appropriately set that tag -- I mean, if "original URL" is captured somewhere in the API, or in the Medium post-create-admin interface (I don't know, I haven't logged into my own Medium for awhile)...that would explicitly resolve the ambiguity, though at an obvious cost to their own SEO.Re: Data Infrastructure at IFTTT
#10To the author (or anyone else with experience): Any insight on why you guys chose Kafka + Secor over Kinesis?