Paragon vs Prismatic: Not All Code-Native Integration Development Is the Same

tl;dr: If you're looking for a code-first way to build integrations that devs like and is versatile enough for any scenario, Prismatic is the clear choice over Paragon.

I recently wrote a post introducing code-native integrations, Prismatic's solution for organizations whose devs write integrations. I explained the basics of our code-native integration building experience in that post.

Since then, Paragon has announced its own dev-focused tool for building integrations. Occasionally, two companies independently arrive at very similar solutions. This is not one of those times.

In short:

• Paragon's new Paragraph solution has made its embedded iPaaS accessible to devs, but only to the extent that devs can now use their keyboards to write the equivalent of what they can build in Paragon's low-code designer.
• Prismatic empowers devs with a code-native integration building experience that is completely free of the constraints of low-code. Devs can reference existing components within our platform or write whatever code they want.

From all the feedback we've received from customers and prospects alike, I know that teams evaluating embedded iPaaS solutions need their devs to be comfortable using the tools to build integrations. Ideally they should actually enjoy using those tools. And, they need to be able to build any integrations they come across.

I'm writing this post to explain to those teams why the Prismatic dev experience supports the way devs work, but the Paragon dev experience does not.

Enjoy some mittens-off code development

We've heard devs refer to working in a low-code designer as "coding with mittens" – the idea that this approach severely restricts developers' dexterity and flexibility. And yes, the fact that a low-code designer is mainly mouse-driven has something to do with this, seeing that most devs are keyboard warriors. But properly supporting devs who build integrations in code takes more than a keyboard-first focus.

What Paragon provides

Paragon's Paragraph supports developers writing integrations entirely in code. Since the integration code can be passed back and forth from Paragraph to the low-code designer, devs can leverage whatever functionality is available via the low-code designer.

But that's also a fundamental limitation, as devs are constrained to write only the code that the low-code designer can parse. If something can't be done in the low-code designer, it can't be done via Paragraph. If it could, it would break when viewed or accessed via the low-code designer.

Why devs prefer Prismatic

Prismatic, on the other hand, allows devs to write whatever code is desired. If the dev wants to use existing triggers, connections, and data sources from already-defined Prismatic built-in and custom components, they can be called from the code. If the dev wants to use a package or library from npm or another repository, it can be referenced in the code. If a dev wants to write an entire integration without calling any external code, that's also fine.

Prismatic's code-native experience allows a dev to actually develop code.

Go ahead, bring custom code to the party

Paragon and Prismatic both support building any number of integrations with a low-code designer. From simple integrations to complex ones, a low-code designer is a powerful tool for non-devs.

But what happens when you need the integration to do something not built into the functionality of the low-code designer? How do you leverage code from outside the low-code designer?

What Paragon provides

Paragon allows for including specified npm packages in an integration. At the time of this writing, it supports approximately 50 npm packages. (For this custom code to run at execution time, devs must wrap it in the Paragon code function step sequence discussed later in this post.)

Why devs prefer Prismatic

Prismatic, by comparison, allows devs to add any npm package to any integration via the code block, custom components, or the code-native integration experience. And, if you have a private registry of packages, you can use any of them as well.

Beyond that, however, Prismatic's code-native experience allows a developer to create any arbitrary code. For example, if the dev devises an elegant solution for data mapping, that code can be used in place of the data mapping functionality built into the platform.

You don't need another framework

Prismatic, like Paragon, supports both low-code and code-native development approaches via a single platform. The difference is that Prismatic recognizes that these approaches build integration logic in substantively different ways and require different rules.

What Paragon provides

Paragon notes that "Paragraph is a TypeScript-based framework for building your Paragon integrations in code." It also refers to Paragraph as as "scripting language."

So, to work with Paragon, your devs must learn the Paragraph framework in addition to working with JavaScript and TypeScript, which they already know.

Here's an example of how branching is handled within Paragraph:

const checkIfExistsStep = new ConditionalStep({
  if: Operators.NumberEquals(actionStep.output.result.totalSize, 0),
  description: "New Contact?",
});

// more code

triggerStep
  .nextStep(searchContactStep)
  .nextStep(
    checkIfExistsStep.whenTrue(createContactStep).whenFalse(updateContactStep)
  );

/**
 * pass all steps here so that paragon can keep track of changes
 */
return this.register({
  triggerStep,
  searchContactStep,
  checkIfExistsStep,
  createContactStep,
  updateContactStep,
});

A dev looking at the above might wonder about a few things:

• How do I set up a ConditionalStep?
• What are Operators?
• NumberEquals: is that == or ===?
• How do I do logical operators (and, or)?
• How do I chain things (but why do I have to chain them since I've already declared them)?
• We have true and false, but how do I do an else if?
• I've declared and chained it, but now I'm passing it to this register. Why?

And those are only the questions from one brief example of Paragraph.

Why devs prefer Prismatic

As mentioned above, your devs already know JavaScript and TypeScript, so they'll be at home with Prismatic's code-native experience.

Here's an example of how branching can be handled within Prismatic's code-native experience:

const resultSize = action.result.totalSize;
if (resultSize === 0) {
  // whatever code you need
} else if (resultSize > 100) {
  // paginate, batch, etc
} else {
  // whatever needs doing
}

And that's how it should be. Requiring devs to follow a framework for things as straightforward as branching and looping makes writing integrations in code more work, not less.

The right approach to writing integrations in code allows for the differences between devs and how they individually create software solutions.

Prismatic understands those differences and empowers devs to code the way they best see fit.

The proof is in the POC

An embedded iPaaS that supports integration development for devs and non-devs should provide both types of users with the tools that best suit their different ways of thinking and working. And it should allow devs to build any integration they need.

Prismatic's embedded iPaaS recognizes and supports this need for flexibility in how people build integrations. Paragon's embedded iPaaS does not. In fact, there are a number of integrations that can't be built in Paragon at all.

Schedule a demo, and let us show you how Prismatic's embedded iPaaS supports the best of both worlds for devs and non-devs alike. Then, move on to a POC (proof of concept) and build an integration from your roadmap to make sure the platform will handle your real-world use cases.

At the same time, work with Paragon to get a demo and then perform a POC of its product. You'll be able to see for yourselves why devs prefer Prismatic.