Dockerfile/Ability to run this in a pipeline

[brandonmcclure]

I work for a non profit healthcare organization and we are using Twilio as our SMS provider. In general, our business users do not understand the nuances of SMS segments and we often send messages in languages other than english, which can make it difficult to balance the queuing/rate that we send out messages with any given message that we want to send.

What I would like: When the business requests a new SMS message sent out, I want them to submit the message as code into our git repository, and then use that to run the message through this tool to let us know how many segments it has (and therefor how quickly we can send messages out given our phone number/subscription with twilio given whatever population we are sending the message to)

A docker image would work really well for my use case, and I think would help provide opportunities for groups that do not have solid node experience. (ie #2 ) I have a fork where I have created a Dockerfile and Makefile that I used to run the playground/index.js file with the message passed in via the cmd line which worked very well for me. I am happy to submit a PR, let me know your thoughts on this.

I had to move the devDependencies into the Dependencies property of the package.json file to get it to run and I am not sure of the effects of that. Also what is the difference between playground and dist? I feel like ideal state the Makefile/Dockerfile should be able to build/run the full website/app in addition to the cmd line/playground/index.js invocation, but I could not get any response when I ran node dist/index.js and did not spend much time digging into it any further because the playground/index.js script does what I need atm.

[vernig]

Hey @brandonmcclure thanks for the suggestion. Actually the whole refactoring we did few weeks ago was to create a package to do exactly what you need. It's an npm package, so you can install it on any server / docker image / GitHub actions without having to clone this entire repo. The usage instructions are in the README of this repo. I would advice against using the repo directly, since there are several artefacts that are not needed to run the core functionality (e.g. calculating the number of segments an SMS would take).

When the business requests a new SMS message sent out, I want them to submit the message as code into our git repository

I'm not sure how are you planning to design this service. The best approach is to create your own API services for your client that take the message body, calculate the segments using the sms-segments-calculator and return the number of segments. Alternatively you can use the browser release of the package to provide this functionality in the frontend (i.e. browser). Can you clarify what advantage the Docker image can bring over the npm package? It seems to me a bit of an overkill in this use case

I have created a Dockerfile and Makefile that I used to run the playground/index.js file As mentioned above, this is not the way this repo is intended to be used. The main reusable component released with this repo are the npm and the browser package (more on this below)

I had to move the devDependencies into the Dependencies property of the package.json file to get it to run and I am not sure of the effects of that This is needed only because the playground is not the intended way to use the code. Adding devDependencies to dependencies will have an impact on the npm package, so I'm not keen on doing that.

Also what is the difference between playground and dist? Let me explain a bit more how this repo is organised (most of this info are in the README):

• src: this contains the Typescript code of the library
• dist: this contain the transpiled code (from the typescript code in src) for the package. This is the same code that gets uploaded to npm in sms-segments-calculator. It's standard practice to not have the dist folder in the repo, so we may remove it at a later stage.
• playground: this folder gives you an example of how to use the npm package code. The main purpose of it is to experiment with the transpiled code (and any local changes you make to it) in the dist folder. But you can achieve the same without having to clone the repo. You simply have to follow the nodeJS usage instructions in the README
• doc: this folder has two purpose: It's used by GitHub pages to serve the static files you access at https://twiliodeved.github.io/message-segment-calculator/ and contains the browser version of this package (segmentsCalculator.js). Once again, you don't need to clone this repo to use this library, and you can just follow the usage instructions in the README (section "Browser")

Let me know if that clarify how this repo should be used.

[brandonmcclure]

Thanks for the explanation! That does clarify a lot!

I enjoy building via docker images because it simplifies the dependencies needed for a developer to build/run the app (Where I work we don't have much node experience). It also makes it easier for me to build/test different branches. If my dockerfile installs via the npm package but I want to test out some custom development from my/other's forks then I need to hack around my dockerfile to make it work with the patched code.

I don't have a good example on gihub, but this article outlines the general idea of building/test/release all via a single multi-stage dockerfile/multiple different images: https://medium.com/@cyril.delmas/how-to-keep-the-build-reports-with-a-docker-multi-stage-build-on-jenkins-507200f4007f

If I stood up a API service I would do so via docker/k8s, so personally I would prefer a docker image that is officially released vs one that I am managing via the npm package because it would be less work for me :-)

[vernig]

Thanks @brandonmcclure for getting back. The docker image is definitely an interesting idea. Jut to make sure I understand, your ideal flow would be to spin a docker image on your laptop and use the script (e.g. playground/index.js) to calculate the number of segments. Am I correct?

I still think that this repo contains too many artefacts and scripts that are not really needed in a docker image. If you confirm that the flow is the one above, I can attempt to create a small docker image that only contains the node environment, dependencies and the playground/index.js script.

[hughrawlinson]

Looks like this issue is stale, closing - but do let us know if you would like any help using the package in your docker image.