Server side Importing github module On Demand

help
1

Right now I have server side only code that performs a task.

I’d like to break off a portion of that code and turn it into an API that I can, again on the server side, “dynamically import” or “remotely import” this code, when I need the functionality of the API, from a some place like a github repo.

I need to set this up where I can test locally without having to deploy the code to github, then when ready, deploy this API to the github repo and import it on the server when needed.

Meteor would import the remote code from github like a module at build time. I don’t want the code to be accessable during development, I only want the code to be imported like a module from a private github account.

I’m trying to hire a developer to help me with a few things, and I don’t want them to have access to my entire API. So if I could just break out my API into a module and have Meteor load it at build time, it could solve my problem.

2

Wouldn’t have the code developed as a Meteor package provide what you need?

1 Like
3

You can create a meteor package inside the myProject/packages folder, and set it up as a “git submodule” that has it’s own repo.

1 Like
4

Given that all the suggestions haven’t met your needs, maybe it’s time to fetch and eval.
I know it’s been drummed into us that eval is evil, but this is one case where it’s the tool for the job

5

A rough draft of what I"m thinking:

// Api Package located in github

\api-package
  \packages
    \api
      index.js
      package.js

Where the package.js file looks like so:

Package.describe({
  name: "api",
  version: "0.1.0"
});

Package.onUse(function (api) {
  api.versionsFrom("1.4.1");

  api.use([
    "ecmascript"
  ]);

  api.mainModule("index.js");
});

// Meteor app

\main-app
  \client
  \server
    test.js
  \packages
    \api
      index.js
      package.js

Where the api-package app is loaded on demand from github.

// test.js

import { api } from "packages/api/index.js"

...
6

You might try something like this:

  • Create a “mock package” (meteor package, not npm) within your main repository’s project/packages/packagename that exposes the api’s namespace and possibly some small mock functions that perhaps simply console.log the calls to the api or throw errors for improper calls, basically a shell api that only replicates the argument validation layer, thus allowing your developer the piece of mind that they’re not breaking anything
  • Create the real package in a private github repository, using the same namespace and signatures (method names, args etc)
  • Set up a CI pipeline that has access to that private repository
  • CI script clones the repo
  • CI has also METEOR_PACKAGE_DIRS="/path/to/the/local/clone" environment variable set up
  • CI script runs meteor remove aadams:packagename && meteor add aadams:packagename (which essentially swaps the mock api for the real deal)
  • CI builds the meteor app and carry on with deployment and voila!

No hacks, no ev(i)l, no possible breach of source code (even build time access to github module from your developer’s computer means the module source is still available to them), no surprizes for you or your devs.

Edit:
You can do the same with npm packages, too. But you’d need sylinking to your imports directory (rm the local code and ln -s to your local clone)or npm link'ing (npm remove packagename && npm i -S packagename).

2 Likes
7

Hey @serkandurusoy! Awsome idea! I’ll look at giving it a shot as you said and will ping you back.

Thanks!

1 Like