SMS Gateway: Working with Go Programming Language
It’s been a very eventful past 1 month. Business was just starting to pick up after a very dull January. BusinessPhone was doing good on the market – the calls were coming in, and there were a few call centres to setup in and outside Lagos.
Then the NCC hammer came down! …but that’s story for another day if I do come around to it. All I can say for now is that while our providers sorted themselves out with the regulator and we were putting out the fire from now frustrated customers, we were literally “jobless” again…then customer X calls.
Customer X is Indian and his colleague had found me through my blog – yes, this one. I had lent my expertise to customer X in the past, and while he was discussing his CRM and 3CX problem with me, he also wanted an SMS provider that would deliver notifications from his CRM to his customers, every time to all networks irrespective of DND and whatnot; and no bulk SMS provider could do that…not even the Bulk SMS service from Tekart.
It was obvious he needed a GSM gateway, one that would be hosted in his office and which would integrate with his CRM which was hosted in the cloud. SIM hosting was not an option.
2 years ago, on the request of those “ghost mode” customers, I had spent time researching a similar solution. I’ve been a fan of the yeastar line of GSM gateways and I knew it was the right device for the job; solid build, great support, capable hardware, useful APIs all at a great price.
Immediately we got down to the task, some of our more detailed findings were
- This would not be trivial because…
- Sending SMS via the provided APIs does not take delivery reporting into account – and this was a requirement.
- We’d need an “agent” running on the gateway. This agent would be responsible for interfacing the gateway with the “backend.” Fortunately, the GSM gateway is a capable ARM-arch Linux-OS computer running a stripped down Asterisk PBX.
- In order to make deployment flexible (without tacking the device onto the public Internet or tweaking firewalls), we needed a networking solution (which would also support real-time communication) that allowed this happen.
Three components immediately jumped to our attention
- Go lang! Ta ta tan taraan!! Which is what this post is about.
- Websockets
- Django channels.
- …and several dozen other things we had to consider.
So, not 3…more like 15. Didn’t I say it turned out not to be trivial?
Why Go?
1 month ago, I personally took it upon myself to play around with arduino. The plan was to build a prototype landline phone. That was the plan….mmhn…that was the plan. Anyway, there’s no landline phone, but I did get to revive my C/C++ programming and I was prime for the “low level” pointers and heaps/stack and compiling etc. etc. Ohhh Python!
We’d never done any project in Go, but we’d heard it was THE systems language. We also heard it sat between C and C++ in terms of performance, supported coroutine type of concurrency out of the box, had a thriving ecosystem of packages, had a garbage collector, would compile against the ARM platform, no problemo with dependencies, was easy to learn (debatable). Wow! You sha check all the boxes.
Ehm guys, this is all I can put down for now. I’ll be following up with more on our experience with Golang in the coming days. Specifically, you’ll learn
- The resources that helped us learn go
- What we found most interesting about go (channels, structs etc.)
- …and update on our project.
Stay tuned…and don’t hesitate to drop your comments in the comments section below.
You must be logged in to post a comment.