DEV Community: Joseph Thomas

Setting up PM2 CI deployments with Github Actions

Joseph Thomas — Wed, 26 Aug 2020 04:59:11 +0000

I spent the afternoon wrestling with getting some Github actions set up for CI using pm2. I had some issues & confusion around SSH issues, and couldn't find anything online, so I wanted to post this here --- even if it's just for me to refer to later. In particular, I was dealing with Host key verification failed. when attempting to deploy from the Github action.

If you're not familiar with PM2, it's a process manager that will run your node.js apps, allowing you to stop, restart, and view logs.

I'm deploying to a DigitalOcean droplet, but the following should be the same for any other VPS. Here are a few tutorials you can follow to recreate the same setup:

Once you have your server set up and your repository hosted on Github, follow these steps:

1. Set up PM2 configuration

Create or update ecosystem.config.js. Mine looks like this:

module.exports = {
  apps: [
    {
      name: 'myapp-api',
      script: 'yarn start:api',
      time: true,
      instances: 1,
      autorestart: true,
      max_restarts: 50,
      watch: false,
      max_memory_restart: '1G',
      env: {
        PORT: 3000,
        DATABASE_ADDRESS: process.env.DATABASE_ADDRESS
      },
    },
  ],
  deploy: {
    production: {
      user: 'username',
      host: '165.232.50.103',
      key: 'deploy.key',
      ref: 'origin/main',
      repo: 'https://github.com/username/myapp',
      path: '/home/username/myapp',
      'post-deploy':
        'yarn install && yarn build && pm2 reload ecosystem.config.js --env production && pm2 save && git checkout yarn.lock',
      env: {
        NODE_ENV: 'production',
        DATABASE_ADDRESS: process.env.DATABASE_ADDRESS
      },
    },
  },
}

Make sure you aren't missing the deploy.production.key value, and that your ref matches the branch you want to deploy from on github. (I've renamed my master branch to main, see npx no-masters)

2. Create a SSH key pair

To get things to work, we need to be able to ssh into our remote server from the machine running the github action. Our next step is to create some new SSH keys. (You could use ones you already have, but it's safer to create new ones just for this project).

On your local machine, run:

ssh-keygen -t rsa -b 4096 -C "username@SERVER_IP" -q -N ""

When prompted about the file location, enter gh_rsa, or anything else you'd like - we will delete these files after getting the information we need from them.

3. Remote server setup

Copy the contents of the public file: cat gh_rsa.pub | pbcopy (or if you don't have pbcopy, just cat and then copy from the terminal output).
SSH into your remote server: ssh username@SERVER_IP
Add the public key to your user's authorized_keys:

echo "ssh-rsa AAAA....YOUR_PUBLIC_KEY..." >> ~/.ssh/authorized_keys

4. Github Secrets setup

Next, we'll add some secrets to the Github repo for use in the action. Go to your repo's Settings > Secrets pane, then add two new keys:

Secret key:
- cat gh_rsa | pbcopy to copy the private key to your clipboard
- In Github, create a new secret named SSH_PRIVATE_KEY and paste in the contents.
Known hosts:
- ssh-keyscan SERVER_IP > pbcopy
- In Github, create a new secret named SSH_KNOWN_HOSTS and paste in the contents.

5. Github Action configuration

Lastly, on your local machine, create or update the file .github/workflows/main.yml (or whatever file you are using for your action):

name: CI - Master
  on:
    push:
      branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      #
      # ... your other steps, such as running tests, etc...
      #
      - name: Set up SSH
        run: |
          mkdir -p ~/.ssh/
          echo "$SSH_PRIVATE_KEY" > ./deploy.key
          sudo chmod 600 ./deploy.key
          echo "$SSH_KNOWN_HOSTS" > ~/.ssh/known_hosts
        shell: bash
        env:
          SSH_PRIVATE_KEY: ${{secrets.SSH_PRIVATE_KEY}}
          SSH_KNOWN_HOSTS: ${{secrets.SSH_KNOWN_HOSTS}}

      # (optional - only needed if your config uses environment variables)
      - name: Create env file
        run: |
          touch .env
          echo DATABASE_ADDRESS=${{ secrets.DATABASE_ADDRESS }} >> .env

      - name: Install PM2
        run: npm i pm2

      - name: Deploy
        run: env $(cat .env | grep -v \"#\" | xargs) pm2 deploy ecosystem.config.js staging
        # Or alternately, put this deploy script in your package.json's scripts and run it using yarn/npm:
        # run: yarn deploy

The key steps here are:

Set up SSH: this creates the deploy.key file, so when pm2 deploys, it matches the public key that we added to the server's authorized_keys.
Create Env File: If your PM2 configuration uses environment variables, we need to use our Github secrets to populate process.env with these variables. In our "Deploy" step, we use the env command to load the file we created.

6. Cleanup & security

Add deploy.env to your .gitignore file.
Delete the gh_rsa and gh_rsa.pub files that we created. Most importantly: if you created your SSH keys within your project's directory, be sure to not commit them.

Conclusion

That should do it! If you have any issues, please leave a comment and I'll get back as soon as I can. :)

Show dev: `npx no-masters`

Joseph Thomas — Sun, 05 Jul 2020 00:57:45 +0000

There has been a lot of talk recently on the topic of renaming the default git repository branch to something other than master.

I'm for it - and I made tool to make it easy:

`npx no-masters`

will:

Create a copy of your master branch and rename it to main
(optionally) push this main branch to github and update the default branch
(optionally) delete the local and remote master branches
(optionally) set up your local git config to use main as the default branch when creating new repositories with git init.

Enjoy, and please share!

If you have (constructive) feedback or come across any issues, DM me on twitter @typeof_goodidea or start an issue in the github repo: https://github.com/good-idea/no-masters

Building Co-Touch: Goals & Introduction

Joseph Thomas — Tue, 07 Jan 2020 19:52:58 +0000

Building Co-Touch: Goals

Today was my first day at the Recurse Center, where I'll be spending the next six weeks taking some time off of client work and focusing on learning some new things. My goals for my time here are:

To work with new programming languages for both backend & frontend.

I have been working as a freelance full-stack developer for the past 7 (almost 8!) years. During that time, I've worked with PHP, Python, Javascript, and a little bit of Ruby - but, Javascript has become my go-to and is what I use for almost all of my work at this point (Last year I made the switch to Typescript, but that's another blog post). On top of that, all of my frontend web work is usually done in React: it's what I know best, and I don't want to jeopardize or slow down a client project by diving into something new.

So, having the space and time to work on something of my own, I want to branch out.
Publish a cross-platform app.

Other than some small projects using Cordova, I haven't had the opportunity to build native iOS and Android applications. I want to grow in my career as a developer, and mobile apps have felt like an un-checked box for a few years.
Write more.

That's what I'm doing here. I never had any formal training in programming; instead, I learned through people who were posting questions, blog posts, tutorials, and classes online. Most of what I have learned from was shared freely. It is amazing to be part of a community that values learning together in this way, and I want to be better at making a contribution.
Form a healthier relationship with work.

This is a "meta" goal for my time at the Recurse Center. As a freelancer, it is easy to overwork. You don't see coworkers clocking out at a regular time, and if you mostly work alone, it's hard to get a sense of how much work is "enough" for one day. I tend to work compulsively, and too much, and have experienced burnout too many times. I won't be writing about this much in subsequent posts, but this is a big goal for me this year, and I also think it is important that we (as developers, as humans) are open about things we struggle with.

Co-Touch 👉👈

This idea is fairly new, and I'm still not sure of the best way to describe it. But, after meeting a handful of other fresh Recursers this morning and discussing what we will be working on, I've formed a bit of a sound-bite: Co-Touch will be a kind of chatting app, using collaborative drawing instead of messages. I want it to be simple and playful, inspired by apps like Flight Simulator and Dialup.

The general idea is that you'll share some kind of canvas with another person, and "draw" to each other instead of sending messages. The drawings will be simple, ephemeral, and time-based - like drawing with your finger on a foggy window.

I don't have any mockups - things are all still very loose, and, since I don't have any collaborators, I think it's OK to just keep it all in my head for now.

The Stack

Mobile Apps

Right now, the choices I have come to for mobile app development is either React Native or Flutter + Dart. The latter is appealing because I want to learn a new language, but Flutter doesn't include the kind rendering engine I can use to "draw" in the way I am hoping to. But, it is able to interoperate with Javascript, which leads me to:
Drawing

I've decided to use a web-friendly renderer for the drawing, maybe working directly with HTML5's canvas, or using a library like p5.js. This part of the project may be the most technically difficult one, so trying to achieve it in a new language might be taking on too much.

Also, it's important to me that the drawings can exist online, so using javascript seems like the natural choice. While the experience I want to create is primarily a mobile one, I may still want to be able to include some functionality in the browser.
Backend

I will need some kind of backend & API. Users will need a way to connect with each other somehow, and I want them to be able to save and replay the drawings they have created together. A simple REST API feels like it makes the most sense, but I'll still need to consider:

Real-time collaborative drawing - websockets will be involved, and I'll need a way to stream users' "touches" (or strokes) to others as efficiently as possible.
Database - Each drawing will be stored as a long list of touches, and not as static images, as I was originally planning. A drawing could potentially be made up of thousands of touches, so I'll need a database that can performantly save new entries and fetch many at a time. I am most familiar with Postgres, but I have also done a little work with DGraph and might give that a try.

Six weeks is not a lot of time - especially when you are surrounded by dozens of people working on all sorts of interesting projects. We'll see how much of the above I can really get through in my time here. If I end up with a simple MVP, or even just getting the hang of a new programming language, I'll leave happy.

Stay tuned here on dev.to for more posts as I continue working. If you have any questions, advice, or feedback, please chime in in the comments, or on twitter at @typeof_goodidea.

A little bonus: this morning I had a pair programming exercise to build John Conway's Game Of Life - here is what we came up with.

Developers using Macbooks, have you made the Touch Bar useful?

Joseph Thomas — Fri, 06 Sep 2019 18:22:19 +0000

I recently upgraded to a newer Macbook, one with a Touch Bar. So far, I haven't found its defaults useful for me in most apps I use for work. I've re-mapped esc to my Caps Lock key, but otherwise haven't done anything.

Any way to make this weird thing useful for programming?

What does a healthy and productive work day look like to you?

Joseph Thomas — Tue, 23 Jul 2019 19:28:31 +0000

I've been freelancing for 7 years, mostly working solo. I recently realized that my own understanding of what constitutes a "productive" day is based only on my own experience --- and, even though I have been able to work much more effectively, I still have a hard time feeling like I have done "a good day's work".

I think that part of this is that I only feel like I am productive when I'm in a "deep working" state - which often takes me a couple hours of busywork/surfing to warm up to. Then, it's hard to wind down at a regular time because I feel like I should take advantage of being in the zone. Then, I burn out.

I don't want this discussion to become about "how to be productive" - there are plenty of articles about that (and I think our culture prizes productivity in an unhealthy way anyway).

Instead, I'm wondering:

How much of your work day is "deep work"?

How do you maintain a healthy pace throughout your week?

How do you maintain a healthy separation between work & the rest of your life?

Any other thoughts / questions / experiences about this?

Git help: Merging updates in a classroom repo

Joseph Thomas — Fri, 31 May 2019 04:15:50 +0000

I have a repo of lessons that I'm using to teach a React class. (You can see it here).

Each lesson has a few files:

a markdown document
a test file
an exercise file
a solution file
maybe some sample data

The students will work within the exercise file, building out react components to get the tests passing. Most of their changes will be here, but they will also be changing a few lines in the test file (changing it.skip to it when they are working on a new test.)

Everybody has created their own fork of this repo, and have cloned that. I have an init script that adds the original repo as an upstream remote.

I'm making updates to the main repo as we move along: fixing some typos, and cleaning up the notes. I would like to figure out a way for my students to pull in these updates without losing the work that they have done.

A simple solution is doing git fetch upstream && git merge --strategy-option ours upstream/master - which will pull in all new updates, but opt for the student's work whenever there is a merge conflict.

But, I also want the students to be able to merge in the updates if they choose to do so. One scenario would be if they had been struggling on a particular exercise and wanted to "reset" it.

An ideal tool would be an interactive CLI where:

The student runs the 'update-lessons' script
For each merge conflict, they can choose to either:
- Keep their own work
- Back up their own work, and merge in the new updates. For example, if there's a conflict in ./src/lesson1/exercise.js, they could choose this option and end up with:
  - ./src/lesson1/exercise.js (The updated file)
  - ./src/lesson1/exercise.5-30-2019.js (The work they had already done)

My students are fairly new to git, so I would want to provide them with something simple.

I don't know git well enough to figure this out, but if I were pointed in the right direction I could write some kind of bash script.

Does anyone know of any tools, workflows, or git magic that could do something like this?

How to fake AWS locally with LocalStack

Joseph Thomas — Mon, 11 Mar 2019 18:54:15 +0000

If you're anything like me, you prefer to avoid logging into the AWS console as much as possible. Did you set up your IAM root user with 2FA and correctly configure the CORS and ACL settings on your S3 bucket?

🤷‍♂️ nah.

I also prefer to keep my local development environment as close as possible to how it's going to work in production. Additionally, I'm always looking for new ways to fill up my small hard drive. I can't think of a better away to achieve all of the above than putting a bunch of S3 servers inside my computer.

This tutorial will cover setting up Localstack within a node app. Localstack allows you to emulate a number of AWS services on your computer, but we're just going to use S3 in this example. Also, Localstack isn't specific to Node - so even if you aren't working in Node, a good portion of this tutorial will still be relevant. This also covers a little bit about Docker - if you don't really know what you're doing with Docker or how it works, don't worry. Neither do I.

You can see the demo repo for the finished code.

A few benefits of this approach are:

You can work offline
You don't need a shared 'dev' bucket that everyone on your team uses
You can easily wipe & replace your local buckets
You don't need to worry about paying for AWS usage
You don't need to log into AWS 😛

Initial Setup

First, we'll need to install a few things.

Install Docker if you haven't already.
Install the AWS CLI. Even though we aren't going to be working with "real" AWS, we'll use this to talk to our local docker containers.
Once the AWS CLI is installed, run aws configure to create some credentials. Even though we're talking to our "fake" local service, we still need credentials. You can enter real credentials (as described here), or dummy ones. Localstack requires that these details are present, but doesn't actually validate them. Thanks to @alexiswilke for pointing out in the comments that I missed this step!
Make a few files. Create a new directory for your project, and within it: touch index.js docker-compose.yml .env && mkdir .localstack
Add an image to your project directory and rename it to test-upload.jpg
npm init to set up a package.json, then npm install aws-sdk dotenv

Docker

(disclaimer: I'm not a docker expert. If anyone has any suggestions on how to improve or better explain any of this, please let me know in the comments!)

Docker Config

You can run Localstack directly from the command line, but I like using Docker because it makes me feel smart. It's also nice because you don't need to worry about installing Localstack on your system. I prefer to use docker-compose to set this up. Here's the config:

docker-compose.yml



version: '3.2'
services:
  localstack:
    image: localstack/localstack:latest
    container_name: localstack_demo
    ports:
      - '4563-4599:4563-4599'
      - '8055:8080'
    environment:
      - SERVICES=s3
      - DEBUG=1
      - DATA_DIR=/tmp/localstack/data
    volumes:
      - './.localstack:/tmp/localstack'
      - '/var/run/docker.sock:/var/run/docker.sock'

(August 10, 2019 edit: LocalStack now has a larger range of ports, the yaml above has been updated to reflect this. Thanks to @arqez for mentioning this in the comments)

Breaking some of these lines down:

`image: localstack/localstack:latest`

Use the latest Localstack image from Dockerhub

`container_name: localstack_demo`:

This gives our container a specific name that we can refer to later in the CLI.

`ports: '4563-4599:4563-4599'` and `'8055:8080'`:

When your docker container starts, it will open up a few ports. The number on the left binds the port on your localhost to the port within the container, which is the number on the right. In most cases, these two numbers can be the same, i.e. 8080:8080. I often have some other things running on localhost:8080, so here, I've changed the default to 8055:8080. This means that when I connect to http://localhost:8055 within my app, it's going to talk to port 8080 on the container.

The line '4563-4584:4563-4584' does the same thing, but binds a whole range of ports. These particular port numbers are what Localstack uses as endpoints for the various APIs. We'll see more about this in a little bit.

`environment`

These are environment variables that are supplied to the container. Localstack will use these to set some things up internally:

SERVICES=s3: You can define a list of AWS services to emulate. In our case, we're just using S3, but you can include additional APIs, i.e. SERVICES=s3,lambda. There's more on this in the Localstack docs.
DEBUG=1: 🧻 Show me all of the logs!
DATA_DIR=/tmp/localstack/data: This is the directory where Localstack will save its data internally. More in this next:

`volumes`

'./.localstack:/tmp/localstack'

Remember when set up the DATA_DIR to be /tmp/localstack/data about 2 seconds ago? Just like the localhost:container syntax we used on the ports, this allows your containers to access a portion of your hard drive. Your computer's directory on the left, the container's on the right.

Here, we're telling the container to use our .localstack directory for its /tmp/localstack. It's like a symlink, or a magical portal, or something.

In our case, this makes sure that any data created by the container will still be present once the container restarts. Note that /tmp is cleared frequently and isn't a good place to store. If you want to put it in a more secure place

'/var/run/docker.sock:/var/run/docker.sock'

Starting our Container

Now that we have our docker-compose.yml in good shape, we can spin up the container: docker-compose up -d.

To make sure it's working, we can visit http://localhost:8055 to see Localstack's web UI. Right now it will look pretty empty:

Similarly, our S3 endpoint http://localhost:4572 will show some basic AWS info:

(If you don't see something similar to these, check the logs for your docker containers)

Working with Localstack

AWS is now inside our computer. You might already be feeling a little bit like you are the richest person in the world. (If not, don't worry, just keep reading 😛)

Before we start uploading files, we need to create and configure a bucket. We'll do this using the AWS CLI that we installed earlier, using the --endpoint-url flag to talk to Localstack instead.

Create a bucket: aws --endpoint-url=http://localhost:4572 s3 mb s3://demo-bucket
Attach an ACL to the bucket so it is readable: aws --endpoint-url=http://localhost:4572 s3api put-bucket-acl --bucket demo-bucket --acl public-read

Now, when we visit the web UI, we will see our bucket:

If you used volumes in your docker settings, let's pause for a moment to look at what's going on in ./.localstack/data.

Here, we can see that Localstack is recording all API calls in this JSON file. When the container restarts, it will re-apply these calls - this is how we are able to keep our data between restarts. Once we start uploading, we won't see new files appear in this directory. Instead, our uploads will be recorded in this file as raw data. (You could include this file in your repo if you wanted to share the state of the container with others - but depending on how much you upload, it's going to become a pretty big file)

If you want to be able to "restore" your bucket later, you can make a backup of this file. When you're ready to restore, just remove the updated s3_api_calls.json file, replace it with your backup, and restart your container.

Uploading from our app

There are a lot of S3 uploading tutorials out there, so this section won't be as in-depth. We'll just make a simple upload function and try uploading an image a few times.

Copy these contents into their files:

.env, our environment variables



AWS_ACCESS_KEY_ID='123'
AWS_SECRET_KEY='xyz'
AWS_BUCKET_NAME='demo-bucket'

Note: it doesn't matter what your AWS key & secret are, as long as they aren't empty.

aws.js, the module for our upload function



const AWS = require('aws-sdk')
require('dotenv').config()

const credentials = {
   accessKeyId: process.env.AWS_ACCESS_KEY_ID,
   secretAccessKey: process.env.AWS_SECRET_KEY,
}

const useLocal = process.env.NODE_ENV !== 'production'

const bucketName = process.env.AWS_BUCKET_NAME

const s3client = new AWS.S3({
   credentials,
   /**
    * When working locally, we'll use the Localstack endpoints. This is the one for S3.
    * A full list of endpoints for each service can be found in the Localstack docs.
    */
   endpoint: useLocal ? 'http://localhost:4572' : undefined,
   /**
     * Including this option gets localstack to more closely match the defaults for
     * live S3. If you omit this, you will need to add the bucketName to the `Key`
     * property in the upload function below.
     *
     * see: https://github.com/localstack/localstack/issues/1180
     */
   s3ForcePathStyle: true,
})


const uploadFile = async (data, fileName) =>
   new Promise((resolve) => {
      s3client.upload(
         {
            Bucket: bucketName,
            Key: fileName,
            Body: data,
         },
         (err, response) => {
            if (err) throw err
            resolve(response)
         },
      )
   })

module.exports = uploadFile

Thanks to @mcmule for the hint about the s3ForcePathStyle option above. If you're getting an ECONNREFUSED error, take a look at his comment

test-upload.js, which implements the upload function



const fs = require('fs')
const path = require('path')
const uploadFile = require('./aws')

const testUpload = () => {
   const filePath = path.resolve(__dirname, 'test-image.jpg')
   const fileStream = fs.createReadStream(filePath)
   const now = new Date()
   const fileName = `test-image-${now.toISOString()}.jpg`
   uploadFile(fileStream, fileName).then((response) => {
      console.log(":)")
      console.log(response)
   }).catch((err) => {
      console.log(":|")
      console.log(err)
   })
}

testUpload()

the testUpload() function gets the file contents, gives it a unique name based on the current time, and uploads it. Let's give it a shot:

node test-upload.js

Copy the URL in the Location property of the response and paste it into your browser. The browser will immediately download the image. If you want to see it in your browser, you can use something like JS Bin:

Then, if you look at .localstack/data/s3_api_calls.json again, you'll see it filled up with the binary data of the image:

Finally, let's restart the container to make sure our uploads still work. To do this, run docker restart localstack_demo. After it has restarted, run docker logs -f localstack_demo. This will show you the logs of the container (the -f flag will "follow" them).

After it initializes Localstack, it will re-apply the API calls found in s3_api_calls.json:

When you reload your browser, you should see the image appear just as before.

🎉 That's it! Thanks for sticking around. This is my first tutorial and I'd love to know what you think. If you have any questions or suggestions, let me know in the comments!

Pusher Contest idea: 🚁Garbage Drones♻️

Joseph Thomas — Tue, 08 May 2018 21:15:21 +0000

The year is 2020

Jeff Bezos acquires Los Angeles County waste management. All garbage trucks are replaced by drones, which are piloted by Amazon Mechanical Turks. You, a Turker, race against others to pick up the county's garbage.

🕹Game design

It's 5am LA time. You and your competitors start up your drones and fly across the city to pick up garbage. At the end of the day, whoever picked up the most garbage wins.

Each game is a series of 2-3 minute rounds, representing a full day.
Players navigate using their arrow keys.
A scoreboard displays how much garbage each player has picked up.

Base Game

Users visit the website and can opt to:

join an existing game. Games have a max number of players. When you join a game, you enter your username and pick an emoji avatar. (No persistent login at this point). Games have a max number of players. When you join an active game, you are an observer until the next round begins.
observe a game: A game can have any number of observers
start a new game

Play:

At the beginning of each round, you see the pickup points on the map and have a limited amount of time to select your starting point. You can change this until the game starts.

Chat:

Observers and players can send "chat" messages that appear for a few seconds on everybody's GUI. Perhaps active players' chats appear as bubbles above their avatars.

Stretch Features

A lot of this is probably out of scope for the length of the contest, but would be fun to have:

Garbage types: Waste, Recycling, and Green garbage. When you start a new round, you pick a drone with different capabilities. Example:

Single-type drones can only pick up one kind of garbage, but they are the fastest.
All-purpose drones can pick up anything, but are slower.

Dropoff points:

Drones have different pickup capacities. When they are full, they can't pick up any more garbage. Various dropoff points are located around the city, and must be dropped off before the player gets the 'points' for these pickups. Garbage that hasn't been dropped off at the end of the day doesn't count.

Map View:

In the base game, the view of the map will be static. But, having a larger map would make play more interesting. There would be a minimap that showed your location and all pickup points, but you wouldn't know where your competitors were until they were in your view.

Stack

Frontend in React, using the Google Maps API for the base map.
Served with Zeit Now.
Client communication with, of course, Pusher
Backend: TBD!

How do you encourage clients or employers to open source?

Joseph Thomas — Sun, 06 May 2018 18:26:56 +0000

I just got a new job building an MVP for a small startup. We're building an interactive web-based app to be used in K-12 education - something that is fun and engaging for students, and helpful for educators to build in lesson plans and view their students' engagement.

As a developer, I'd like it to be open-source. I don't expect that it's a project that the community would be contributing to - as our use case is somewhat specific - but, I'd like to be able to keep a public journal of my experience working on the project, and allow others to see how I am approaching problems with a production-scale app. Spectrum recently open-sourced their platform and looking through it has been illuminating.

In short: I couldn't be where I am now without learning from open source software, and I'd like to find ways to share what I have learned in the context of a "real" production app.

I think many business owners would err on the side of closed source, the most obvious reason being that they wouldn't want to provide any benefits for competitors.

🤔Has your business or the business of your client benefitted from open-source?

🤔Have you had this kind of conversation with your client or employer?

🤔If you've thought about this for your business, what went into your decision making, and which route did you take?

How to keep functionality in sync between codebases?

Joseph Thomas — Sun, 11 Jun 2017 01:10:41 +0000

I'm building up a new project that will consist of a central API, which a number of different sub-projects will link into.

For simplicity's sake, let's say that part of the functionality of the whole platform is to get an image's metadata. This might happen in the core API, or on either the server or front-end of one of the sub-projects.

All of this will be written in Javascript, and functions like this will be pure and contained in their own modules. I'd like to have a single place where I can create and edit these modules, so that in any instance above, I can do something like:

import getImageMetaData from 'getImageMetadata'; // it's within node_modules

const resource = 'http://example.com/image.jpg'
const metaData = getImageMetaData(resource);

...

Is the simplest way simply giving this module its own github repo, then including it in package.json on all of the different sides of the service, and constantly run (using hooks or whatever) npm install upgrade my-package?

Any smart ways to keep this all in sync? Preferably as automated as possible ~ there might be up to a dozen of the front-end sub-projects, and I want to be sure that I can fix all of them at once.