How is Transposit different than IFTTT?

I recently joined Transposit and a friend and I were emailing back and forth about what the Transposit platform offers. He asked:

“This reminds me of IFTTT. How would you say it’s different?”

I immediately unfriended him. Ha! (Do people even do that anymore?) Actually, I replied with a few ways that Transposit differs, and wanted to expand on that in a blog post.

Now, I’m still getting my feet under me as I come up to speed, but there are a few major differences between what Transposit offers and what IFTTT offers (or other tools like Zapier; for simplicity’s sake I’ll refer only to IFTTT for the rest of this blog post). But first, how they are similar?

• Both integrate APIs. These APIs (Application Programming Interfaces) allow you to perform complicated operations and logic (sometimes, as with Lyft, affecting the real world) by sending a properly formatted message.
• Both help busy people get stuff done with minimal coding and infrastructure.

Now, to the differences.

Target audience

IFTTT is designed for the non-programmer, the business user who has a logical, structured mindset. IFTTT allows them to make those logical connections between applications with a visual builder. Transposit is focused on developers, the folks who view IFTTT as coding with the mouse instead of the keyboard.

Transposit gives you access to JavaScript and SQL, which are general purpose languages. IFTTT’s visual metaphor is more approachable for the non-programmer, but is constrained. You can’t do what its designers didn’t anticipate users doing.

Events as an integration paradigm

IFTTT is event-based (even if the event is a time based trigger). Something happens and another thing is triggered. You post a new entry to your blog, and IFTTT will happily post a link to your Twitter feed. Responding to events is a powerful means of connecting APIs, and works for many use cases.

Not all, however. You can end up with large flows that are hard to understand and debug. One time I built a flow with fifteen steps that set up a new client based on a row being added to a Google spreadsheet: create a Google Drive folder, copy some files into it, create a Slack channel, add some users to it, and more like that. At the end it worked, but felt fragile. The fragility was an acceptable tradeoff in this case because I didn’t have time to build and support a more robust solution.

Built In Extensibility

When building with IFTTT, you are limited to the integrations that IFTTT makes available, as mentioned above. If you want to query an API and trigger an action, but they haven’t built that integration, you have to write your own. I’ve wanted to trigger on an event but, though the API was supported, that particular event was not. With Transposit, supported APIs are completely exposed. And because the audience is more technical, there’s plenty of support for incorporating your own APIs. To be fair IFTTT and the other services allow you to do such integrations as well, but I’d venture it is less common as a percentage of users due to the audience.

Additionally, Transposit handles more than just events. Take for example, Slack. Using IFTTT, you can take actions once on an event in Slack: when someone posts a message, you can send a file. With Transposit, you can do all the same event triggered processing, but you can also perform other more complex actions. For example, you can query to see how many Slack messages were posted and email a report, or copy all files older than 30 days up to S3 (except the annual reports and any cat gifs) and then delete the files from Slack. These more complicated use cases are better served by a programming paradigm.

IFTTT supports workflows, Transposit supports applications.

Sharing your solutions

When you write out a workflow for IFTTT and you want to share it with colleagues or friends, documentation is your best option. Start a wiki page and document the steps:

• step 1: you need to grab your blog’s RSS feed
• step 2: add the RSS step for IFTTT
• step 3: configure your Twitter account
• …

With Transposit, you can create an application that others can login to and configure.

For example, I can write an application to, say, send a summary email every day of all the Slack channels that had messages posted on them. I’ll need to send emails, so I set up an account with SendGrid as well as granting permission to my Slack workspace. Suppose I worked with you a few years ago and we’re having coffee. I mention how useful getting this summary email has been. You say “Hey Dan, can I check it out?”. How do I share that?

Well, I share that application with you by sending you a URL. You configure the application: set the destination email to your address and connect it to your Slack workspace. Both the SendGrid account and summary report logic are shared, but everything else is configured on a per-user basis.

When the application runs, I’ll get an email about the N messages in my Slack workspace; you’ll get an email saying there were M messages posted in your Slack workspace.

Voila, I just shared an API integration. This example integration is pretty trivial, but you can share apps interacting with three or more APIs or with complicated business logic just as easily.

Final thoughts

Hopefully this sheds some light on ways that Transposit is different than IFTTT and similar low code/no code solutions. For more examples of what you can build on the Transposit platform, check out some other apps, and currently supported APIs.