zubairov

The downside are opportunity costs - not using other models to make better decision, I guess, right?

This is very cool! Amazing work guys!

Trigger.dev is awesome, use it every day. A feature list is quite impressive and complete, the only thing on my wish-list is a `wait/resume` for long running jobs

Good example of survivorship bias :)

Gmail, Calendar, Google Accounts down in Germany

Nice, just curious counting the filled and dotted lines - how this software is integrated together?

That's nice feature, we would need to look into it, however DNS A or AA does not contain port information limiting us to the 'default' ports.

That's not possible right now

+1 for us it's CDN (CloudFront) - only HTTP 503 responses

Many see tools like http://Zapier.com or http://elastic.io (disclaimer - I'm a founder) as alternative to Pipes and IFFT.

The simplest PaaS ever, nice approach - should have been done by AWS

Open source is a different business model - you won't be able to do SaaS and open source at the same time. You could try open core where open source would be your marketing channel, this one works - e.g. Talend or RedHat.

Very interesting... paid IFTTT account, I'm quite sceptical about that, I would expect the licensing contracts with Philips, Belkin, et al. are the main revenue source and will remain to be it in future...

Quora discussion on that topic here:

http://www.quora.com/Whats-the-difference-between-Zapier-and...

Simple to use add-on - JavaScript integration widget that can be embedded in your app and immediately connects it to multiple APIs like Google, LinkedIn, Salesforce, Xing, etc.

I am building a JavaScript widget that give you access to over 10 different sources of contact data and storage services, check it out at http://www.elastic.io/product#samples

Good point, however as you already noted, it's not a single app or single chat client that can change the situation - it's the acceptance of it among the bigger community. It's not a technical but an educational topic where ecosystem leaders should take the responsibility to educate ordinary people (not just HN readers) on that. I strongly believe this kind of initiatives should have a strong legal/governmental support and/or control.

Thanks for the tip, we'll look into WP REST plugin again.

I'm not the prismic.io developer but I believe it depends on you - how you fetch the content fragments from prismic.io. We are doing it on the backend, so it's perfectly searchable by Google ;) See here - http://www.elastic.io/blog/82796857416/why-we-chose-api-base...

We count number of records we transfer between two systems. For example in case of contact import one data records === one contact record that is imported into your application. In case of File Exporter one data record will be one single file, but in this case you might guess that 'bandwidth' limits are more critical than 'data records' :)

Problem is not that Zapier or any other system want access to your whole Dropbox. Problem is that Dropbox API is constructed in such a way that no granular access is possible to request from a user. Google Drive in comparison is more fine-graned however more complicated to use (from API side) too.

Absolutely agree on this one with you. We are working on similar product http://elastic.io and it's clear that in this business (IFTTT, Zapier, elastic.io, FoxWeave.com, etc) you need to work on two customers - business customers who pay and developers who are platform multipliers. That's the reason Zapier and IFTTT are trying to open up. Important is however business users (who pay) do not need 'developers' view on things, they don't need the 'flexibility' and complexity that developers needed, so essentially it's two different products. Think AppStore/App - Xcode.

Thanks Tom! As we switched from Java to JavaScript it gave us incredible boost in productivity. And also staying on the shoulders of giants like node.js, twitter bootstrap speed things up allot.

Exactly! We are Yahoo pipes on steroids.

Good points are covered in this blog post, however what if we would push it even further?

Why would people need to download a package? Why would anybody need to learn a programming language you package designed for (or assume you distribute packages for many programming language)?

When using APIs for integration or mashups, especially in business world, person who know how solution should looks like may not have time to code. So we at http://elastic.io think API could be via visual designer.

We believe it's also a way to make API usage _simpler_ for enduser, even the one who can not, or have no time to code.

Yes. Good point. It's indeed quite expensive to do the graphic generation on the server.

We use a caching from Amazon CloudFront. They have a great feature 'custom origin'. We just put our heroku server URL as an origin for CloudFront and configured HTTP headers properly. After that we were able to significantly reduce the load on a server.

We also blogged about it: http://blog.elastic.io/post/22773181715

Awesome tool. I really like how you integrated the component functionality into the UI, so that you could select a particular form from Wufoo or list the Salesforce object. What components do you have right now and what are planned for the future?

Hi,

No 1005 ms was not a cache miss it was a request to the origin server. Latency was 799 ms.

I assume CloudFront will contribute some latency, however in our case (we are using Heroku) our servers were already on Amazon platform, therefore CloudFront --> our server latency should be significantly lower. So CloudFront cache miss latency for the enduser will be not significantly higher than origin server latency for the enduser.

Good question. It depends on the caching strategy. As we essentially serve Gists we have two types of URLs one something like [gist-id]/ meaning the latest version of that particular gist and another URL is [gist-id]/[revision-id] which is a particular revision. For 'latest' URL we just do a redirect to particular latest version. For first type of resource we have 60 seconds expire, however it is also not too expensive to re-generate it. For second type of resource (with particular revision) we have much higher expire time (several days). By this type of caching strategy I assume we will get only 20% of all requests to our servers so saving is significant.

Hi

You can try http://elastic.io We are in private beta and still missing some of the components but it can be fixed rather quickly. Sign up for beta access and drop us a line on info at elastic.io

Renat