What do I need to know before working on an IM app

Question

I'm looking into building an IM-type application using Java stack (for the server at least). I'd be interested to see any information/advice on how applications like Skype/AIM/MSN work, as well as know any technologies/APIs that might be relevant. Without giving away the idea itself, it's perhaps more akin to Google Wave than Skype, but information useful for either is very welcome.

Specific points I have already thought of include:

• Server Vs P2P... for reasons of logging my system will require all communication to go through a central server. Is this how other IM tools work... especially when audio/video comes into the equation?
• Cross-communication with other systems. Are there APIs for this or do all IM providers work hard to keep their protocol secret? The nature of what I'm designing means integration could probably only be limited, but it definitely seems worthwhile from a business perspective

Answer 1

There are two ways to build a mobile messaging app: chat features development:

• build proprietary solutions from scratch in-house

• Integrate with mobile messaging SDK solutions. 


Here’s an article about the rough estimated development cost breakdown, How Much Does It Cost to Develop WhatsApp? It comes to minimal initial fixed cost $260,000 for development for 3 months with about 6 engineers and a product manager in a place like Silicon Valley or NYC to build basic mobile chat features from scratch. Not to mention the cost of running servers, maintenance, scalability, and features expansion in the future. The opportunity cost of spending the dollars and time on building chat features are the resources that cannot allocate on your core features (unless you’re building another WhatsApp or Facebook Messenger).

If your plan is not to reinvent the wheel, or you’re conserving engineering resources and put experts for better use, or simply just testing water with chat features, then it’s often simpler and more cost effective to integrate the 3rd party or open source solutions directly. They often provide ready-to-use customizable UI library, cross platforms SDKs, backend APIs and Webhooks integration, etc. The same idea as using Google Analytics, Parse/Firebase, Crashlytics, AFNetworking, Facebook APIs, Socket.io, Stripe, Twilio for SMS, Hyphenate.io, etc. Many companies decide to build in-house chat solutions initially, but later realize that their solutions do not scale as expected as the customer base grow rapidly.

However, before you start getting hands dirty integrating chat features whether 3rd party integration or in-house solution, you might want to investigate the following areas,

• Cost effectiveness: ROI of in-house solutions? Achieve the economies of scale? Building the engineering infrastructure is very expensive, counting initial fixed development cost, running cost, maintenance, features expansion, etc 

• Scalability: Low latency, horizontal scaling, vertical scaling, scale without downtime, overall performance, etc

• Reliability: stability, reliability, downtime, guarantee message delivery, no lost of message and package, etc

• Mobile Client Device: device battery life, cellular data usage, sporadic and slow Internet connection, 

• Ownership: Proprietary vs. Tiered pricing structure vs. Licensing with private deployment and hosting 

• Security: encryption, authentication, privacy

• Portability: Support across different platforms. i.e., mobile (Android, iOS), desktop (macOS, Windows), and various of Web browsers. 

• Features: one-to-one chat, group chat, large volume and simultaneous conversations, login into multiple devices, file sharing, audio file sharing and playback, video/voice calling, etc

• Technologies: There are many standardized technologies out there, such as XMPP, MQTT, HTTP long-polling, Socket.io, etc. Most messaging build proprietary solutions upon standard protocols, for example, Facebook Messenger is based on MQTT. Many 3rd party vendors already provide great API and SDK solutions to alleviate developers’ headaches, such as Hyphenate.io. 

• Human resources: Are you able to find the engineers with the expertises to fulfill all the requirements above?
 Another thing to consider is the possibility of incorporating trendy chatbots, big data analysis (especially customer service), encryption, etc. Check if 3rd party SDKs, open source, or your engineering team are able to provide those flexibilities or layout the potential runway. Some mobile messaging solutions provider, like Hyphenate.io, have rich chat features set and great flexibility for expansion ready for you to dispose.

Finally, answers to your thoughts,

1. Server Vs P2P... for reasons of logging my system will require all communication to go through a central server. Is this how other IM tools work... especially when audio/video comes into the equation?

Hyphenate handles the communication or message delivery for you as well establishing the video/voice calling.

2. Cross-communication with other systems. Are there APIs for this or do all IM providers work hard to keep their protocol secret? The nature of what I'm designing means integration could probably only be limited, but it definitely seems worthwhile from a business perspective

**In terms of communication security, there're 3 major components that you might want to look into TLS/SSL for transport layer security, OAuth 2.0 for authentication, and end-to-end encryption. **

Answer 2

Get to know XMPP. There's plenty of Java libraries and most major IM clients support XMPP.

Answer 3

As mentioned, use XMPP (which stands for eXtensible Messaging and Presence Protocol). You can probably get away by using an existing XMPP server (e.g., Openfire, ejabberd, etc) without programming one yourself. There is something called libpurple for connecting using proprietary IM protocols.

For doing stuff that standard XMPP doesn't you can look at client bots or external server components.