IFTTT vs. Zapier vs. DataFire
IFTTT vs. Zapier vs. DataFire
DataFire needs a lot of polishing before it's ready for use by the average user, but I don't think it will take much to get there pretty quickly.
Join the DZone community and get the full member experience.Join For Free
Your feedback matters—tell Capital One DevExchange what you would do with their Money Movement API.
Integration Platform as a Service (iPaaS) solutions are something I've been tracking on for a while, and an area I haven't seen too much innovation in (except by Zapier for most of that time). I'm a big fan of what IFTTT enables, but I'm not a big fan of companies who build services that depend on APIs but do not offer APIs in turn, so you don't find me highlighting them as an iPaaS solution.
Instead, you'll find me cheering for Zapier, who has an API, and even though I wish they had more APIs, I am grateful they paying it forward a little bit. I wish we had better solutions, but the politics of API operations seems to slow the evolution of iPaaS, usually leaving me disappointed.
That was until recently, when some of my favorite API hackers released DataFire.
DataFire is an open-source integration framework — think Grunt for APIs or Zapier for the command line. It is built on top of open standards such as RSS and Open API. Flows can be run locally, on AWS Lambda, Google Cloud, or Azure via the Serverless framework, or on DataFire.io.
DataFire natively supports over 250 public APIs including Slack, GitHub, Twilio, Trello, Spotify, Instagram, Gmail, Google Analytics, YouTube, as well as MongoDB, RSS feeds, and custom integrations.
They have a sample flow available as individual GitHub repositories. Integrations can be added by the URL of an Open API (Swagger) specification or an RSS feed, you can also specify --raml, --io_docs, --wadl, or --api_blueprint.
DataFire is new, so it has a lot of maturing to do as an API framework, but it has everything that iPaaS solutions should have at its core in my opinion. It's API definition-driven, it's open source, and there is a cloud version that any non-developer user can put to use. DataFire is encouraging everyone to share each of the flows as machine readable templates, each as their own GitHub repository so that anyone can fork, modify, and put to work. #IMPORTANT
This is the future of iPaaS. There is lots of money to be made in the sector, empowering average business, professional, and individual users when it comes to managing their own bits on the web — if current providers get out of the way. The problem with current solutions is that they work too hard to capture the exhaust of these workflows and limit their execution to specific walled garden platforms. DataFire acknowledges that these flows will need to be executed across all the leading cloud providers, orchestrated in serverless environments, as well as more managed level of service in a single, premium cloud edition.
DataFire is the iPaaS solution I've been waiting to see emerge and will be investing time into learning more about how it works, developing integrations and flows, and telling stories about what others are doing with it. DataFire and DataFire.io need a lot of polishing before they are ready for use by the average, non-technical IFTTT or Zapier user, but I don't think it will take much to get there pretty quickly. I'm stoked to finally have an iPaaS solution that I can get behind 100%.
Published at DZone with permission of Kin Lane , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.