In today’s mobile world, people just assume every phone number is a cell phone… even if it’s clearly listed as “office” on your business card. And, in most cases, if the phone number belongs to a corporate phone system, or PBX, any text messages sent to that number are lost forever in the great bitbucket in the sky. Until now, that is! If you happen to be using Flowroute as your backend trunking provider, you can now receive any SMS text message via email.
Here’s how to do it…
1. Setup My Proxy App Using Docker I’ve whipped up a simple Node app to make life easy for you. In short, it receives all SMS text messages, from Flowroute, and emails them to you at either a single email address or custom “wildcard” domain. Assuming you have Docker installed a public server, install it via the following command:
Of course, it will be up to you to ensure your DNS and server settings are both setup with a FQDN pointing to that docker container. You’ll also need to have an SMTP account for outgoing messages.
2. Activate the API with Flowroute Once you have a Flowroute account, head over to their Developer Portal and click on the Get API Access button. This will bounce you over to the Flowroute portal where you will enter the URL to the Docker container you setup above:
Sometimes the smallest lil’ gem makes you feel great. For me, Docker’s --format option is one such gem. As much as I love Docker, for me, their commands’ output are far too verbose and noisy. In fact, the net is filled with complaints about this. However, the --format option makes them perfect… or closer to perfect. Even the noisiest command can be transformed…
… from this …
… to this …
… in just a few extra keystrokes!
It outputs just the right amount of info to be particularly great for “4-up” or “2-up” arrangements…
Docker’s info for the ps commandcompletely sucks and offers no info on this option. In short, you basically use it to tell Docker what columns to display. For example, with ps you have the following columns to choose from:
So many of the examples out there, for both Node and Docker, show simple little applications. They might demonstrate how to create a container. Another might show how to crank up your first NodeJS app. However, I have yet to find one that demonstrates how to use these bag o’ widgets in a real world application.
Hopefully, my mean-docker example, on Github, will help show how to bring it all together. Something within me wants to create a small how-to video series surrounding it, however, there are several good folks out there already tackling the meat of this (check out Derick Bailey’s WatchMeCode for back-end goodness). So, who knows? In the meantime, here’s what this project will give you:
(BTW: Here’s the direct link on GitHub, in case you missed it: mean-docker)
Three back-end microservices (for some reason the Node world is referring to them as “APIs”… which annoys the heck out of me) stubbed-out in NodeJS and Express.
The front-end Angular app which calls into the example APIs.
Your example company’s web site. Again, this is just stubbed out.
solution-a & solution-b
Two higher-level solutions containing all of the “good stuff” for Docker & NGINX.
There’s not much to it. Here’s what to do:
Install Git & Docker on your development machine.
Clone the Git repo to your machine:git clone https://github.com/FredLackey/mean-docker.git
Navigate into either solution-a or solution-b (currently identical):cd ~/Source/Github/FredLackey/mean-docker/solution-a
Spin up Docker and let’er do it’s magic:docker-compose up
NGINX is listening to a few URLs specifically, so you may want to edit your /etc/hosts or %SYSTEM32%\drivers\etc\hosts file and add the following entries (a copy is in the provided %SOLUTION%/.docker/etc/hosts file):
Automated “watchers” are already setup to handle all of the compiling, optimising, starting, and restarting for you. Simply do your work in the typical %PROJECT%/src/server and/or %PROJECT%/src/client folders and everything else will be taken care of for you.
On a completely clean dev machine, it should take approximately three minutes for an initial build:
If you updated your /etc/hosts or %SYSTEM32%\drivers\etc\hosts file with the names of the servers, you may check the status of each project using any web browser:
… or …
The goal of this project is to get you started and help demonstrate some of the concepts… getting NGINX to talk to proxy your requests, linking docker containers, automagically detecting changes, etc. That being said, it works for this purpose but it’s not an actual working solution. If you have a need for such a thing, let me know and maybe I can spend some additional time on it.
It’s common knowledge that Docker’s mounted volume support on macOS is pathetically slow (click here for more info). For us Node developers, this means starting up your app is incredibly slow because of the requisite node install command. Well, here’s a quick lil’ trick to get around that slowness.
First, a quick look at the project:
Long story short, I’m mapping everything in my project’s root (./) to one of the container’s volumes. This allows me to use widgets, like gulp.watch() and nodemon to automagically restart the project, or inject any new code, whenever I modifiy a file.
This is 50% of the actual problem!
Because the root of the project is being mapped to the working directory within the container, calling npm install causes node_modules to be created in the root… which is actually on the host file system. This is where Docker’s incredibly slow mounted volumes kick the project in the nads. As is, you could spend as long as five minutes waiting for your project to come up once you issue docker-compose up.
“Your Docker setup must be wrong!”
As you’ll see, Docker is quite vanilla for this lil’ project.
In short, the additional volume causes Docker to create the internal hooks within the container (folder, etc.) and wait for it to be mounted. Since we are never mounting the folder, we basically trick Docker into just writing to the folder within the container.
The end result is we are able to mount the root of our project, take advantage of tools like gulp.watch() and nodemon, while writing the contents of node_modules to the much faster union file system.
Quick Note re: node_modules: For some reason, while using this technique, Docker will still create the node_modules folder within the root of your project, on the host file system. It simply will not write to it.