Node.js - How to write plugins for application? - node.js

So I have a node.js application that I want to have plugins that can one or several of the following:
Data importer
Data outputer
Data storage (mongodb)
View (express/jade)
So say plugin A is a data storage and plugin B is a data outputer and view plugin that requires plugin A?
Is there any existing framework that can solve this for me?
I think I know how to do it kind of with require and some 'magic', but I have requirements:
Plugins should register with the main application so the application can send events or call methods on the plugin.
Should be easy to pull in and out plugins
Should be able to validate that you have the dependency plugins installed for a plugin.

All you have to do is to write your plugin as simple Node.js module and, as you already mentioned, require it in your main application.
Your plugin has to export an activate-function which you call from your main app.
To register functionality (or the plugin itself) in the main application, you could write a node module, that the plugin developer must add to it's developer dependencies. Let's call it plugin-interface-module for now. These module should have a register function which you call inside of your activate-function in the plugin.
Your main app also requires these plugin-interface-module and retrieves all registered plugins from it. Required modules are globaly cached, like singletons, so your main app is able to get the list of registered plugins.
Take a look ad VS Vode (https://code.visualstudio.com). It's written in typescript and uses extensions in the same way.

Related

"Dependency hell" when using same npm module for both sdk and service itself

I'm currently developing a project in Node JS that uses microservices architecture, in which each service has it's own repository that contains both the code for the service itself (NodeJS express server), and also an SDK file that I publish for other services to use with methods that are available in this service and Typescript definitions.
So for instance I have a users-service that handles all of the user related actions, and a reports-service that handles all of the reports that users can CRUD.
users-service has a method called "deleteUser" that also goes to reports-service SDK in order to delete all of this user reports. On the other hand reports-service uses user-service SDK to "getUserById" for instance. So what happens is that user-service has reports-service-sdk as one of it's dependencies, and reports-service has users-service-sdk as one of its dependencies. Because the SDK is inside the same npm module with the service, I get users-service-sdk as one of the dependencies of users-service.
I thought of separating the SDK with a different package.json file, but I wanted to know if it's the right way to go or am I doing something really wrong in my architecture :)
Thanks.
This sounds like Circular Dependency which as you stated in the title is tough to deal with. Microservices are great but this sort of architecture sounds like a lot of extra unnecessary work without any added benefit.
You should look into running your services/packages/repositories as Cloud functions (or Firebase functions). AWS also has their own solution for microservices architecture. The reason being is each service can communicate with other services by using internal authorized calls or authorized REST API calls --- or you can make them totally public.
The great thing about these Google Cloud Functions is each function is automatically an Express end-point that accepts GET, POST, DELETE, PUT. Or if you use the internal call for Firebase, each function automatically contains relevant context from the frontend (such as the user's authentication details).
You also configure IAM permissions to only allow who and what service you want to be able to execute your cloud functions so that you have full control of permissions.
To answer your questions directly though, I would definitely avoid Package A having Package B as a dependency as Package B has Package A as a dependency. You absolutely can make that work but there's no upside and a lot of downside.
Here's an old thread which covers the topic.

Implementing a Plugin Manager in NodeJS Application for dynamic extension at application level

For a NodeJS server application i need to implement dynamic extendability with a plugin-like system. Goal is to be able, to hook in extended calculations by simple plugins, which select when and how to run by events they register for at the main app.
Within a folder "./plugins" each plugin should live in a subfolder.
The plugins should be loaded by the application automatically at startup.
No change at the application code is allowed for introducing a new plugin.
Plugins should be able to register for events in main application.
Communication between the plugins should be possible in some way
Is there any ready to use framwork for this requirement or are there any rock solid architecture approaches for this?
Regards
Boxson
Found a solution after some try and error:
Read the plugins directory (fs) and scan for subfolders
Check if there is a manifest.json file inside the subfolder
if manifest.json exists, read this file and parse content as JSON object
push the JSON object into an array (plugin list array)
iterate over the plugin list array and require the plugin main.js file
plugins register for events of the plugin manager object (made accessable via global.pluginmanager = pluginmanager
With appropriate error handling this seems to work solid.

Using QLPreviewPanel with Electron

We are looking into migrating our Objc Application to an Electron one, since the native one is just a WebWrapper around a website already.
We are missing one important feature: the ability to use QuickLook to preview files.
We managed to wrap qlmanage (Quick Look Server debug and management tool) in a npm module (based on this older code) but this is not the same as using QLPreviewPanel.
qlmanage launches an app in the Dock, and can spawn multiple instances of it, unlike QLpreviewPanel.
Does anyone managed to use Quicklook properly with Electron?
Is it possible to create a npm module in C++ using the Foundation Framework from Apple, and then requiring this module from Electron?
Any insight would be greatly appreciated.
We ended up adding this feature directly in Electron.
This will be released soon on the BrowserWindow api, with the following method signature:
previewFile(path [,displayname])
This way everyone gets to use it!

Plugin system in SailsJS application

I'm working on a NodeJS application, using SailsJS, and I want to implement (or use if exists) a system to manage plugins. By "plugin", I mean a module that I could add in a "plugins" directory.
Is someone has ever tried to do something like that ?

Node js plugin permissions

I create a web server with Sails.js, and want to allow third dev to create node.js plugins installable from a web page (store).
My problem is I don't want this plugin to require sails (or other critical modules) and have access to database and services and do what they want.
For example using fs and delete all files.
How can I do that ? I have no idea if node.js can lock some scripts on this own directory
I don't think that node expose some sandboxing functionality so when you load a js code into node that code can do what it want.
From your description yours plugins are more like browser javascript code so I think that you can use a headless browser to execute your code and retrieve the result. I've never tried it by myself but it should work. You just have to figure out how to pass parameters to plugin and get the result, also performance will be very bad because the headless browser is quite heavy. Try looking at
http://phantomjs.org/
Another solution is to run the plugins directly inside node but sanitizing the code before running. There are some projects like:
http://gf3.github.io/sandbox/
https://github.com/asvd/jailed
They can help you limiting the powers of the plugins.
Anyway are you sure about it ? in any major CMS platform that I've seen (wordpress, joomla, drupal, liferay ...) the platform's author trusts plugins authors and plugins can always do what they want.

Resources