We update the application to include Redis and the worker process.
This article is part of a series starting with Monorepo on Heroku in TypeScript: Part 1.
The final example for this series is available for download.
For local development, we need to spin we spin up a Redis Docker container with:
docker run --name some-redis -p 6379:6379 -d redis
For the Heroku application, we execute the following from the project folder:
heroku addons:create heroku-redis:hobby-dev
We configure the Heroku local environment for Redis; the environment for the Heroku application is automatically set.
Update web Package
We install kue; a priority job queue backed by Redis, built for Node.js.
npm install kue
npm install @types/kue
We update (and commit) the Express application; implementing an endpoint to add jobs to the queue; returning results when the jobs complete.
We can then locally run the application with:
and on Heroku:
git push heroku master
- Without the worker process, the web service will not return a result
Create worker Package
We begin by creating a folder, worker, in packages and copying the following files from the web package:
We update (changing the name, entry point to worker.js and getting rid of the dependency on Express):
packages / worker / package.json
We then write the code for the worker process:
- packages / worker / src / worker.ts
We then update the Heroku process file:
We can new start the application locally and browse to it:
- The string, apple, is generated by the worker process from a job in the queue (backed by Redis)
We then commit our changes and push it to Heroku.
git push heroku master
Then enable the Heroku application to run the worker.
heroku ps:scale worker=1
Finally, we can browse it with:
A New Problem
First, we solved our original problem, i.e., each of the packages (web and worker) have completely separate dependencies.
The build time for this particular application is minimal; the code is super simple. On the other hand, as the code becomes more complex and we add more packages, the build time for the application can become lengthy (tens of minutes).
The lengthy build time is especially bothersome when changes only involve a single package; the current configuration always builds all the packages.
While one can imagine complex solutions to determine which packages to build, here is a quick and somewhat hackish solution:
- We change out the simple postinstall command with a more comprehensive script (below)
- The script’s behavior is. If a file named build exists at the root of the project, it will interpret it as a list (one per line) of packages to build; otherwise it builds all the packages
- First, thought to write this as a Node.js application, but in the end found a simple shell script solved the problem
- This particular script requires that the package names (in the respective package.json files) match the folder names
Hope you found this useful.