remote plugins support

[theuargb]

I want to implement something like an "HTTP-driven plugin", where the config is passed to an HTTP server and a new one from the response is returned. I felt the "init" nature of buildConfig and wrote something like:

// remotePlugin.ts

const fetch = require('sync-fetch');

const addRemotePlugin = (url: string, params = {}) => {
    return (config: Config): Config => {
        try {
            let collections = fetch(url, {
                method: 'POST',
                headers: {
                'Accept': 'application/json',
                'Content-Type': 'application/json'
                },
                body: JSON.stringify({params, config})
            }).json();

            return {...config, collections: collections};
        } catch {
            return config;
        }
    };
};

export default addRemotePlugin;

// payload.config.ts

import addRemotePlugin from './remotePlugin';

export default buildConfig({
  serverURL: 'http://localhost:8080',
  admin: {
    user: Users.slug,
  },
  collections: [
    Users,
  ],
  plugins: [
    addRemotePlugin("http://localhost:5678/webhook/4c4d226b-e143-4389-ae2c-83bf13eab410"),
  ],
  typescript: {
    outputFile: path.resolve(__dirname, 'payload-types.ts')
  },
});

which works perfectly, except that the payload sends the request to the remote server multiple times. Once as expected - when the server starts. While the admin page also does this "HTTP-request" via browser capabilities when loads.
I thought that when the app starts - configuration is parsed and the admin page may request it from the backend.

So is there a way to provide a remote service with the ability to modify collections (or entire config)? OR to easily fix the current impl to store the response somewhere in the payload's server data so the plugin can behave like "do request if not cached, cache till restart"?

[jmikrut]

Hey @theuargb — I don't think this is going to be possible, because Payload configs are not able to be serialized as JSON. They contain functions and even full React components, which would be lost / difficult to maintain in HTTP transit.

Also, as you've noted, the Payload config is built in multiple places (server, client) and those two places run in entirely separate environments. One is on your server, and one is in the browser like you've noticed.

Can I ask why you're interested in doing this? What is the goal?

[theuargb]

Hi @jmikrut. I got it, thanks)

My problem is this: I have is a set of microservices that store data in a common mongo storage. I want to add them all to 1 common "admin panel" web view.

My original idea was to write a plugin to manage config remotely - so each microservice would be polled when running the admin panel and the payload would display a unified interface. I have POC but did not continue because of just the complexity of serialization).

Now I plan to make a "companion plugin" for each of the microservices which would provide the "correct" config for the microservice, and it in turn would simply use the rest\graph APIs.

However, I'm still not sure what would be the best solution)