Non local pieces

[wenerme]

Is your feature request related to a problem? Please describe.

activepieces is greate, but is hard to customize, I like the trigger's soluttion, you can define the execution(pieces) in any where, but trigger use http callback for this, I highly recommand nats rpc for this, so I can do some thing like

definePieces({
  id:"",
  displayName:"",
  input: Type.Object(),// typebox schema
  run:()=>{}
})

I use nats for rpc, see here, it's supper easy, has simple lb built in, don't worry about sandbox anymore. I really like trigger's cron like ability, but it's not support pull based(only http based callback).

I think maybe activepieces can have something like this too.

Describe the solution you'd like

rpc/registry based pieces.

Describe alternatives you've considered

trigger

Additional context

[abuaboud]

Typebox is something we are considering. Thank you for bringing this up. Although we're still not sure how to ensure we can achieve a 1:1 mapping for the user interface. This is the hard part.

I am not familiar with NATS or NestJS. Can you please explain more? What is the end-to-end use case that would help me understand the full picture?

[abuaboud]

I believe I understand more of what you're trying to achieve. I assume you want to use pieces directly from the code instead of the user interface. If I'm assuming correctly:

You want to build trigger-based pieces, and let's activate the scheduling part for you, and the code would execute natively on your machine that why sandbox is not required, since activepieces will be responsible for the cron job.

Isn't that what trigger.dev is exactly doing? What do you dislike about it?

[wenerme]

I believe I understand more of what you're trying to achieve. I assume you want to use pieces directly from the code instead of the user interface. If I'm assuming correctly:

I want to define pieces in code, I don't care where the invocation come from, this is the trigger like usecase, after the define, can using the pieces in WebUI, just like the normal pieces, maybe the UI is restricted by schema, but most of time this should be ok, can extend later.

activepieces running as a standalone server, it may invoke the pieces by NATS or HTTP callback or Redis Queue, Nast is simplest here, has builtin RPC semantic.

---

• temporal is code first, very heavy, full durable.
• trigger is half-half, the task is in userspace code, the schema is on the server side, major for cron like task.
• activepieces with flow + pieces, but WebUI only, the customize is not easy.
• laf is pure core, runtime only, more like serverless, heavy, not worth it.

I think activepieces can meet the sweet point here with userspace/remote pieces.

[wenerme]

the code would execute natively on your machine

this is the best part I like, the second is react (personaly) sdk & ui.

Isn't that what trigger.dev is exactly doing? What do you dislike about it?

yes, dislike part is

• require http callback

callback is hard for microservice like env.

[abuaboud]

I understood since http callback might be received by another server.

This is very interesting perspective i would love to continue brainstorming with you.

So if i understand correctly, you dont care about the flow UI part and interested in triggers.

Do you mind share one end to end usecase? And the ideal solution for you would be code run in your service but activepieces handle the trigger and communicate through nats

Is my understanding correct?

Edit: I understand the importance of running user code since it can communicate with database and reuse existing code

[wenerme]

So if i understand correctly, you dont care about the flow UI part and interested in triggers.

not excatly, activepieces can orchestration triggers is very lovely.

I understand the importance of running user code since it can communicate with database and reuse existing code

yes, this is the point

By extract this to NATS or somthing, activepieces can also orchestration service write in other languages.

---

The trigger in code can make a lot things eaiser, I can orchestration the bussiness.

e.g. daily rollup job, I want to see the result, but running the job outside of project is impossible.

e.g. I defined a notification in project code, I hope this can be accessable by others easily.

[abuaboud]

Would the action be any valuable?
For example why would someone prefer activepieces slack piece more than official slack npm?

[wenerme]

For example why would someone prefer activepieces slack piece more than official slack npm?

e.g. I can define the template by my own, activepieces can not have all params exposed by notification channel, activepieces can not have all possible nofications.

also, currently the nofitification in code is not generic, it just send data pulled from db to a webhook(lark group webhook for now), but writing code is alot easier by tweaking the ui/config/schemam, I just want to orchestration the trigger with a littel bit config in activepieces UI.

[abuaboud]

This is an interesting thought that would extend the activepieces existing capabilities to be code first used by developers.

I believe it is the different direction and separate product, that we might not be able to develop forward in the short term, as the activepieces are postioned to be used by non-technical people and the pieces framework is purely for the developers

Do you mind if we speak I would love to learn more about this code-first approach and the existing tool landscape as I am not familiar

I would love to scope the possibility of adding resource called events inside activepieces.
https://cal.com/abuaboud

[wenerme]

Hi, maybe the time is't right, I will summary some of my thoughts here.

• I want a bussiness orchestration engine
• Can invoke bussiness related code easily, without expose too much private part
• The whole point to this is make bussiness functions accessable for non-tech users with some config/flow ui
• Existing solutions are not meet the requirement
  • BPMS - toooo heavy
  • Temporal - need maintain alot things, missing the ready to use Flow UI
  • n8n primary for builtin blocks only like activepieces
  • trigger, need http callback, primry for cron like job, only require pg(very sweet, activepieces need redis).
• The enigine should be a simple orchestration flow service, should not focus on support too many builtin jobs
• Trigger only suppport http callback because serverless handle the scale, but by using nats/redis, the scale part should handled by KEDA, it's easy when you have the scale problem.
• The flow can be triggered by NATS/Redis messages, this makes the initial trigger way easier, just like consume a message from queue.

xref triggerdotdev/trigger.dev#430

[abuaboud]

Hi @wenerme,

I missed this notification. I think this is currently out of scope for the Activepieces roadmap, as we align more with a no-code experience and focus on the UI builder.

I am closing this issue, but it's a great reference if we revisit this discussion again in the future.

[github-actions]

⚠️COMMENT VISIBILITY WARNING⚠️

Comments on closed issues are hard for our team to see.
If this issue is continuing with the lastest stable version of Activepieces, please open a new issue that references this one.