Plugin system

Hi! i have and idea of a app and am thinking of having a plugin based system i think i have an idea how to do this when if am making all the plugins myself but what am wondering is how do one go about if i want others to also be able to create plugins for my app. Does anyone know of an opensource project that does this or any article or videos that talks about this?
1 Reply
Halu
Halu•2y ago
🧊 ⛏️ I'm not experienced in plugin architecture, but i'd like to break the ice and get a bit more talk here! The freedom you have in designing a plugin architecture will of course depend on your intended service and constraints. By service i mean: platform(desktop, web, mobile, other), client-side extensibility, and/or server-side accessibility additional constraints are usually: accessibility, security, and costs Lets look at some current extensible services: • obsidian: - platform: desktop - extensible area: a client runtime + api - security: non-existant (plugins can easily run malicious code, they utilize community policing) - accessibility: utilizes electrons web apis, meaning wasm and js possible • codepen (et al.): - platform: web - extensible area: a client runtime - security: iframes, maybe webworkers, code sanitization - accessibility: 0 set up, you write it it runs. • google colab: - platform: web/cloud - extensible area: server-side accessibility - security: sandboxed/container runtimes that reset. - costs: abuse detection • Discord bots: - platform: cloud - extensible area: server-side accessibility - security: strict api - costs: api abuse detection, users must host bot • codesandbox: - platform: web/cloud - extensible area: "client portal" + server-side runtime - security: sandboxed/container runtimes - costs: ??? (these examples don't cover things like games, where client and server runtimes often share plugins to work/communicate correctly) If you can tell us what targets you need to hit, we can better guide you. -------- In general, the main strategies are: 1) sandboxing 2) api's here is an overview on some of the different sandboxing methods: web: • iframe • webworker • wasm container (e.g. StackBlitz WebContainers) desktop: • separate processes • if webview, see web too. server: • gVisor The issue with sandboxing is that it can become hard to communicate with the original runtime. ---------- This is usually where api's come into play. web: • server-api: sometimes there is no direct bridge, the server provides the shared context • webworker & wasm api: if sharing state between client web runtimes • iframe & postMessage: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage • iframe & window frameElement, parent, frames: might be able to build an api off this, but prob not recommended desktop: • sockets, ipc, rpc, stdin/out: all be targets to share state/data within the clients machine • server-api: if you provide a web service, this may still be applicable ------------ some more fringe methods: • extensible reactive architecture - its technically possible to load in components from the server to extend the current runtime. not very secure tho if user supplied. • islands and micro frontends - you can serve whole apps or just components to sections of page (you can use code sanitization, iframes, and "reactive" iframe-api to sync state) • custom language - sometimes just parsing a simple markup language, script, or data model can be enough to safely extend your systems. . . . tldr: interested in insecure js: look at obsidian interested in webworkers: workerbox or jsandbox interested in iframes: look into codepen interested in wasm: look into stackblitz interested in server extensibility: prob gVisor i cant recommend any particular sanitizers nor api abstraction
Want results from more Discord servers?
Add your server