Introduction
Now we have to design the basic structure of our service. Firstly we have to get a general idea of how these communication services work, and try to fit them into a common abstract model. Then we need to look at the system requirements and database access. Combina all these, we will get a general system architecture design.
Commnication Service Comparison: Plivo vs twilio
Plivo uses RESTful API. It has C# helper library to make it easier to interact with the API. It also has web/mobile SDKs which you can used to build app using their services in browsal or phone. Since we are only try to make outbound call, the helper library is all we need. Also, it requires token to access its service, and most importantly, XML to custmize the response. From my personal practice, you need to put these XML on a public web server where Plivo can access, that’s kind of annoying.
Twilio is very similar to Plivo as far as I can see, for outbound calls. It’s also a Restful API with helper libaries, needs token for authorize and a url points to the response. The difference is it has its own markup language called TwiML.
Both services support SMS and voice messages, and as for voice message, their processes are very simialr. The only wield thing is, Plivo is much cheaper than twilio. There is a comparison here, seems like twilio’s API is better?
System Requiments
- Must provide abstaction from actual service (like Plivo and twillio)
- Must support both sending text or sending voice instruction
- Must have unit tests for service portion
- Have admin GUI to manage:
- Support API token management for different app
- View audit of all requests, with filter for time range and by api token
- Landing page should be dashboard of SMS stats.
- Create admins for portal management
- callback/ 2 factor authentication
- audits purge afer 2 years.
System Design
- Using XML to specify the api call format
- Common interface called
Service
to which defines the common actions for all services (Plivo or twillio) ServiceController
deals with restful api calls from userAdminController
deals with resquests from adminUser
models stores user infomationResponse
models stores response informaiton- Front-end for admin
- Database for user information, log and response
Conclusion
The system design for now is pretty general, it may change with the development process. I’ll fill in more details later.