Reaction: Transition Meteor App Plugins to Services

[aldeed]

Transition Meteor App Plugins to Services

Goals

• All code moved into /imports/plugins/core
• No code imports between plugins
• Registry through a core NPM package registerPlugin function
• All communication through hooks (don’t directly call methods you shouldn’t be aware of, etc.)

Why

Before we can move plugins to become separate micro-apps, they need to be built according to service object principles, respect boundaries, and use proper inter-service communication.

Plan

Prerequisites

1. Define the plugin hierarchy. Which plugins are aware of which plugins?
2. Define schema ownership. Which plugins own which schemas?

Steps

1. Find a place in /imports/plugins for all code that is currently outside of the imports folder. Create a new “core” plugin. For now, keep schemas and collections in here.
2. Move all SimpleSchemas and collections to the plugin folder in which they belong.
3. Move all GraphQL schemas and resolvers to the plugin folder in which they belong.

4. Create a registry NPM package

   addQuery(name, func, [methodName])
   addMutation(name, func, [methodName])
   addGraphQLSchemas(schemas)
   addGraphQLResolvers(resolvers)
   addMeteorMethod(name, func)
   addMeteorPublication(name, func)
   addUtil(name, func)
   registerPlugin
   // and a way to use all of the “added” things from other plugins
   

5. Update the core graphql plugin to do schema stitching of all schemas and resolvers registered by addGraphQLSchemas and addGraphQLResolvers

6. Update core plugins one by one to use the registry package. While doing so, find all other extraneous imports that come direct from other packages and rewrite.

[dhonig]

This is a very complex task, but exciting to see. Once one starts looking at the architecture of reaction and realizing everything is a plugin, the next step is to see reaction as a kind of micro-service architecture. Looking forward to seeing this develop!

[zenweasel]

No one asked me, but if we were going to move something that's in the core right now into a service, I would vote for moving the jobserver out. In a production environment I would love to not run this on web servers and only run it on dedicated job-servers.

[aldeed]

The title of this might be a little confusing. To clarify, this Epic is for getting the current plugin code properly separated such that we can later move to services. So there is quite a bit of work before we actually move anything to a service, including not only this Epic but also finishing the new auth system, designing the service communication pattern, and incorporating data streams.

At the end of this Epic, they will be "services" in the code sense, but not separate apps connected over HTTP.

But I agree that background jobs would be a good one for the initial trials.

[zenweasel]

Oh, I thought this would be the PR that removes Meteor. So disappointed. :😢