Reflecting on over 20 years of online technology, I feel there is no more important concept that has emerged than the API. Originally an acronym for Application Program Interface, the meaning has evolved to basically define how anyone understands the concept of any two entities communicating with each other.
Looking back at my own history, it’s clear that the concept of an API has influenced me heavily. Everything I have ever done as a technology solution is designed as an interface to serve other programmers. I continue to envision every new opportunity as a chance to interconnect everything on the Internet in the best and most amazing ways possible.
We all spend a lot of time focusing on how humans can communicate over the Internet, it’s been my core business for at least 15 years. I have also spent a lot of time studying how programs or devices can communicate directly the same way humans do. We didn’t have a name for it in the old days but today we like to call it IoT. Is it a new and exciting frontier or just a cool name for stuff we have been trying to do for years? Either way, it’s great to see it take off.
A lot of modern API interfaces have evolved from early WWW technology. Since HTTP, the protocol used to power the web was the most widely available resource, it was the logical choice to carry information from one system to another in simple implementations.
HTTP is an amazing protocol that allows web browsers to communicate with servers world-wide. It took us out of the stone age of text based gopher clients and gave us visualization of the Internet.
As a programmer, I was intrigued on how to leverage this new thing and make services that could run over this magical new protocol. I fell in love with CGI immediately. Not Pixar, Common Gateway Interface, CGI is the way that a web browser could submit metadata from a form to the web server to a server-side program.
Learn more here: https://en.wikipedia.org/wiki/Common_Gateway_Interface
I didn’t know it then but I was staring down the barrel of the future of API that would carry us through the next many years. I was so excited by the promise of all of this fancy new stuff. I never learned traditional user interfaces. I focused on making browsers and the Internet my interface to the world.
When my skills matured and I started working on C code I really got my first dose of what an API really was. In C, everything is organized into libraries that are loaded into an application extending specific features to the main program. Some of libraries just existed on your system by default and some had to be obtained manually and installed for specific enhancements.
Learn more here: https://en.wikipedia.org/wiki/C_standard_library
I spent a lot of time messing with the Apache web server. At first I was amazed with myself for even configuring it properly. Later I learned how to load modules into it to do all sorts of cool and interesting things. I eventually learned how to write a module myself. This is where APIs came in super handy. There was a whole slew of functions I could use that made writing my module easier.
I had one module for web hosting that allowed no configuration at all to load a new website when a customer signed up. Just by creating the directory in the appropriate place, the site would start working. If your domain name was signalwire.com you could just drop a folder into some path like /var/websites/s/i/g/signalwire.com and it would start working.
One really cool thing about working with programs and API interfaces is that it’s kind of like a game. You get to make up rules and situations and make it even a little fun if you want. And if you sprinkle in just the right amount of abstraction, things start happening on their own that you might not have even planned. This is especially true with protocols.
A protocol in the context of the Internet is basically the way information is transferred over a network, i.e. The Internet. HTTP, for instance, is an example of a protocol. Many of them are acronyms and end in P, which stand for…, yep never mind. A protocol is an amazing compliment to an API because you can basically bridge software calls over a long distance.
There is also a dark side to protocols. Many of them are fluid in how they are specified and not always easy to implement yourself. Sometimes nobody implements them anywhere close to how they were defined which can lead to a lot of trial and error when working on communication.
When I started working on FreeSWITCH I had already spent several years contributing to Asterisk which was an open source PBX that had the same affinity for modules as Apache. Back then there were already some interfaces for SIP and other popular protocols. Working on open source was always a great practice for dealing with APIs because if you wanted, you could look at not only the interfaces made available but the guts inside that made the code work.
Until this point, I had only made APIs that work over HTTP. Before it was cool, we all used to make CGIs that were designed to accept requests from command line tools like wget or curl that could be used as part of a local system. Someone ran with this idea at some point and called it REST. I feel like Forrest Gump sometimes when I think back to all the stuff I was part of in the early days of the Internet.
Once I decided I was going to start a project to create a communications platform, I really had to start thinking about the convergence of APIs and protocols. Our goal was to be disruptive and bring change to the telecom industry. One priority was to try to add programmability to a rigid communications industry. We really wanted to bring the same amazing concepts to telephony that I always enjoyed having at my disposal as a web programmer.
The result of that effort, FreeSWITCH, has APIs for EVERYTHING. We have modules that can make HTTP requests to retrieve dynamic configuration. We have modules that allow you to remote execute several functions over a TCP socket. We have modules that add new APIs to the list of things you can do with the other modules. We even allow popular language bindings to translate APIs to embedded interpreters. Internally in the software itself, we have APIs you can use from the core of the software platform to extend functionality just like all the great software that inspired me.
Here are some super interesting details (not really it’s probably boring unless you are a developer) about some of the protocols and API interfaces we have created as part of our journey. These tools help most popular first generation CPaaS and other IP telecomsleverage our technology for their businesses.
https://freeswitch.org/confluence/display/FREESWITCH/mod_xml_curl
https://freeswitch.org/confluence/display/FREESWITCH/mod_event_socket
https://freeswitch.org/confluence/display/FREESWITCH/mod_verto
https://freeswitch.org/confluence/display/FREESWITCH/mod_commands
https://freeswitch.org/confluence/display/FREESWITCH/mod_httapi
Our high level APIs like these are popular but internally we also have almost 2000 public APIs in our codebase. Everything we create in the core of FreeSWITCH is designed to help some developer get something to work the way they want and to reduce the complexity facing them in the code.
Users of our technology stack rely on all of our APIs every day to communicate with their software. For over a decade we have been working hard to figure out how to make communication scalable and as programmable as possible. A large number of popular commercial PBX and CPaaS platforms on the market are using our stack and some form of our APIs internally behind their REST interfaces or in some cases directly as part of their offerings.
Once FreeSWITCH had evolved to a powerful modern telecommunications platform, we knew the next logical step was to scale it to the Enterprise. From this, SignalWire was born. SignalWire is rooted in trying to solve the problem of how do we deploy resources for developers in the mainstream who need communications services to be as easy to control as every other thing they interface with but also scale to any requirement. This required some thought.
FreeSWITCH is designed to be versatile and run anywhere. It runs on a Raspberry Pi as well as on a 60-core Linux or Windows server. Its a low-level engine or a standalone Soft-Switch. It is extensible in many ways but that also presents a problem when trying to deliver a uniform experience to the masses.
My main focus on architecting how we interface to the world with SignalWire is usability and command over resources. We want to produce a layer of indirection between the developers and the complex infrastructure that is necessary to scale telephony. This means taking everything important and making it possible to achieve over an API interface and using a protocol that can handle scaling requests to match the volume needed.
We feel that there is a lot of work to do to solve these problems. There are some solutions out there that have paved part of the way but we’re still kind of stuck using the cool HTTPtricks of the past. The simplified diagram below shows how most legacy platforms make their API available. This works for some paradigms but in the case of Real Time Communications it’s pretty challenging. There is a lot of back and forth on the customer application side and a requirement to bring up web services even on the consumer end.
Behind these HTTP servers, there is a giant pile of virtual machines with another translation layer to try to manipulate a hodge podge of resources. In most cases a middleware layer must be established to direct traffic to and endlessly growing pile of dedicated virtual machines trying to duplicate software instances that only were designed to scale to a single computer.
I am working with my engineering team to build a bi-directional API that can control real-time resources and scale them to anywhere across an array of disparate micro-services that scales horizontally and vertically at the same time.
Our new creation called RELAY, is the concept of an API that can be bound to multiple languages and function as an RPC layer over the Internet. The design is inspired by our previous work creating FreeSWITCH which in turn was built on the influences of my past.
Our new API is designed to allow you to create remote resources and provision accounts as well as send messages, control calls and everything else that becomes possible as we move into the future.
Internally the receiving end of RELAY is routed to an interconnected fabric of micro-services handling all the heavy lifting, using FreeSWITCH and many other key components who work together to provide a seamless experience and provides developers with powerful control.
When we zoom into the swarm we see a repeating pattern of interconnected components so applications can be rapidly developed and not bolted on. This allows the applications to become part of the fabric and scale with the core.
If we zoom out to a global view we see the same pattern again. The design is to interconnect nodes of nodes of nodes to scale like a balloon and those balloons connect to each other spanning the globe.
Enabling machines and programs to communicate with each other just as well as humans is the paramount focus of our infrastructure. Human communication flows across the top layer but machine communication plays a big role in the backend and remote side. Just like with humans, it’s important to keep everyone involved in communicating.
One of the most amazing things that brings this whole discussion full circle is that because of WebRTC, a new initiative to bring telecom to the browser, I now get to combine the two most critical components in my entire career into the same effort. We now have achieved the concept of web browsers that can interface to each other, and to our platform with live audio, video and messages.
This gives me the ability to innovate on enabling RELAY to build thin access to serious communications tools that can perform in the most popular and widely used environments, the web browser and in mobile applications. Running on trillions of devices in the world, the possibilities are endless.
We are working on adding all of the supporting tools including RELAY clients to Github as part of our signalwire.community We are also hosting a Slack space where everyone can come and chat about everything under the sun. Just go to signalwire.community and you can invite yourself. Come join us and give us your feedback.
For more information on SignalWire in general please visit signalwire.com