No-code automation can be unopinionated and extensible.

I am one of the creators of Activepieces, where we've been working on an open-source automation tool for more than a year. Personally, I've spent a lot of time thinking about the challenges of using no-code platforms and how to avoid feature creep. I would love to share my thoughts about our approach in building Activepieces from a technical perspective.

Quick Wins vs Long-Term Customization

When I speak to people, the arguments divide into two parties, where developers are more concerned about long-term solutions while non-technical individuals are trying to solve the problems they are currently facing. Both of these are valid concerns, and adopting no-code is not a cheap decision that can be easily reverted.

Feature Creep vs Learning Curve

No-code platforms generally trend towards being opinionated and lacking customization, and the more features they have, the steeper the learning curve becomes. This presents a challenge as they create high-level abstractions over programming languages.

Comparison of Existing Tools

Let's take a look at the existing tools in our daily ecosystem and their differences.

Examples:

• Java Spring Ecosystem vs JavaScript Express: Java Spring is known for its comprehensive features and robustness, making it suitable for large-scale enterprise applications, but it offers only one way to implement functionality. JavaScript, on the other hand, is known for its large ecosystem where you can pick your own set of tools according to your needs.

• IntelliJ vs VSCode: IntelliJ IDEA offers a full-fledged integrated development environment (IDE) experience with advanced features, particularly suited for Java development. In contrast, VSCode provides a lightweight yet highly extensible code editor suitable for various programming languages and scenarios, appealing to developers seeking flexibility and simplicity in their workflow.

We clearly know who is the winner :P

The Struggle Between Learning Curve and More Features

Increasing the number of features tailored for power users can lead to a steep learning curve, thereby complicating the process for ordinary users to achieve their goals.

For example, if we examine the differences among workflow builders like Zapier, make.com, and n8n from a technical standpoint, Zapier is primarily designed for regular users, make.com caters to power users, and n8n is oriented towards a developer audience.

How We Build Activepieces?

In the design phase, our key question was: How do we balance a low learning curve with rich features?

We simplified the core concepts in the workflow to include runs, triggers, and actions, while encapsulating all additional complexity within the framework of "pieces" (similar to plugins).

In each of the following section let's discuss the pieces ecosystem in details.

Pieces framework

The framework has a thin layer of abstraction over actions and triggers. It includes lifecycle hooks and a set of tools such as a simple key store tool, providing a unique HTTP endpoint for triggers, handling authentication for third parties, and offering a simple way to define inputs that will be automatically rendered in the interface.

Everything else is a library that can be used alongside the framework, but it's not part of the framework itself, such as a polling library.

Pieces are npm Packages

Each piece within Activepieces is an npm package, which allows us to:

• Use PNPM for caching and other existing tools in the ecosystem.
• Have the ability to leverage other npm packages instead of being limited to the set of tools provided by the framework.
• Leverage the versioning system in npm, which enables us to make breaking changes without breaking the existing flow, as each piece has its own package.json.

Pieces are Typescript

TypeScript allows us to create a type-safe framework. There is no need to use external validation, for example, to validate custom JSON syntax. Functions can be reused across actions and triggers.

Local Developer Experience

Being open source means users can run the entire development environment locally, which includes hot reload. There is no need for a slow, clunky command-line interface (CLI) experience to upload the connectors first to closed-source software for testing. This setup enables users to easily identify bugs by reading the code.

Open Source Community

We've received plenty of pull requests where developers have made certain aspects more configurable, such as broadening Activepieces' language support, resulting in the platform now accommodating nine different languages.

The low barrier to entry in open-source software fosters a large, supportive community. There's no requirement for sales pitches or demos; developers can read the code and easily do the software evaluation.

Examples:

Approval Piece: It's simply a pause flow with an HTTP callback.

Schedule Piece: It's a polling trigger with a user-defined schedule. The properties can change, but the piece will always convert it to a cron expression, allowing for changing the properties freely since pieces are versioned.

Webhook Piece: It's a unique HTTP endpoint like any other piece, but with markdown to copy the URL.

You can read more about our framework here: https://www.activepieces.com/docs/developers/overview

Conclusion

The open-source approach with a plugin system emerges as the clear winner for building an ecosystem. While abstractions are useful, it's essential not to overdo them. Instead, we should focus on fundamental concepts and allow the community to choose their preferred methods.

I hope you found this discussion insightful and helpful.