Posté le 17 août 2018 - 06:12
A friend of mine has got a project in which he has to build a chatting mobile app for his client for customer support along with a web back end.
His client has around 1.45 million customers across the country. From these 50% of them are using Android based smart phones.
I am blank as to what technology should one use for build such a solution.
Will WX do for building a mobile solution?
What should be used for building the web back end?
What kind of hardware should one look out for from hosting companies?
Can we think of using Firebase and FireStore from Google for this? As per my research Firebase does not support more than 100k simultaneous users connected to it. Is this correct or am I missing something here?
Should one adopt any third party service like Layer or Slack or PushBullet or something like this? Here my research shows that the cost of supporting such a large number of users will be quite exorbitant.
I have also checked out a very good XAMPP solution called MongooseIM platform but I don't think we can use this if we develop the mobile app in WM or is there a solution? (http://github.com/esl/MongooseIM)
So what approach should one adopt to build a two way chatting app that will work from smart phones as well as have a web interface and that should support the load of around half a million simultaneous users. Where users will be able to message each other and also send media files to each other.
Posté le 17 août 2018 - 10:10
If you are going to support 1.5 million users (concurrently?), I don't think you can rely on current WX Mobile or Firebase technology ...
For a start, Firebase has a limit of 100.000 users per database and that's probably your smallest problem ...
If I had to program this kind of app I would go with Erlang and probably use MongooseIM and have of course a lot of time to complete it [if I hadn't done it before].
I am a great fan of using the right tool for the job.
Posté le 17 août 2018 - 11:34
I wouldn't trust on the WX backend for this kind of scalability requirements but there might be an alternative using WX in part on the client side.
This means you could for example go for a .Net Core C# solution (runs on Windows and Linux and Azure and against a multitude of databases) in the backend. Personally I'ld host it on a platform like Azure where required resources can be scaled automatically and on the fly based on demand. The scalability possibilities will be extreme compared to the WX application server...
In there implement all your bulk backend stuff as Web API's (extremely easy in .Net Core C#) and have it communicate with the clients over this standardized protocol (JSON / XML / Custom).
Having a trustworthy and scalable backend in alignment with most modern technologies and protocols, means you could create the clients (front-ends) potentially in WX.
You'll just have to play around and see how easy it is to use your Web API's including authentication out of the box from WX. Even in V23 most of the Microsoft SOAP and REST web services cannot be consumed from WX being one of the main reasons why we left the platform for the bulk of our work. Either because most of them are constructed around XML insertions into the SOAP parameters (ComplexType) being falsely encoded by the WX runtime and because often they require Kerberos authentication (typically in an enterprise environment) which is still not available in WX after so many many years...
If you implement oAuth2 authentication in your solution, it might work out of the box but it will require validation...
Just my 2 cents,
Posté le 17 août 2018 - 13:59
I don't see why you couln't use the WX products for all that... It would need to be coded the right way, of course, but scalability is completely possible with a replicated DB...
I'm doing just that (not currently with 1.5 million users, but he principle is the same), with each client (mobile or not) being assign a main IP address for its server and several secondary ones of redundancy. as all this is dynamic and DB driven, it means that you can adjust the number of clients on each server based on it's load... and as the servers are replicating their data between themselves, it's completely transparent for the users.
As for the type of hardware needed on the server side, it will mostly depend on the number of users your application (ie your coding) is able to manage per server... That is completely linked to the optimization of your code.
So no, I wouldn't try to use an unknown tool in the hope that I don't find any roadblock on the way... I would just work a lot on the logic of the app and DB to minimize/optimize everything and would work a lot on code optimization.
Posté le 28 août 2018 - 04:42
Posté le 28 août 2018 - 09:30
Thanks everyone for your invaluable inputs. Just as a follow up and to share with the community what we are going to use and do...
For this project we are not going with WM! It would prove to be suicidal to use/stretch WM.
Finally we have decided on the following (in brief):
Develop the app in Android Studio using RX JAVA using Google suggested MVP through Dagger 2
For iOS going to develop the whole app in Swift 4 using RX Swift
For database use MongoDB (with data sharding as necessay) on server
For server platform going to use pre configured Dockers and deploy then on AWS stack as this will allow us to scale vertically and horizontally
API’s written in pure Node.JS as per Rising Stack guidelines
Real Time chat engine powered by Erlang (this is a highly modified version of MongooseIM platform developed by another company and is being offered commercially)
We will try to secure the app infrastructure by using SSL, JWT (JSON Web Token) and reverse proxy with load balancing
For Audio and Video calling we will be using WebRTC (will be implemented in phase 2)
There will be 3 developed working on this project and we hope to reach the first beta by end of Oct 2018
Even after all the decisions are take I would not hesitate to explore new possibilities and technologies along the way.
So if anyone has any other brilliant ideas please do share here. I think this will benefit the community as a whole.
Posté le 28 août 2018 - 10:11
Posté le 28 août 2018 - 10:47
good luck !!!
But "first beta by end of Oct 2018", that means you are really fast
Posté le 31 août 2018 - 08:19
But "first beta by end of Oct 2018", that means you are really fast
Actually we are not that fast but as I said we are going to purchase the XAMPP server pre configured and customized as per out needs and that will come as a Docker it would become easier for us to deploy it on any non windows server that allows dockers and also make it easier to scale up vertically as well as horizontally as needed in future!
So one headache is dealt with.
What we have to focus on is the chatting client and the back end management web interface. As our client needs the chatting app first we are going to first build the app and 3 developers is enough to get the work done in two months!
After the app enters beta we will be taking up the back end management web interface development.
Posté le 31 août 2018 - 10:31
Xamarin might also be an option.
It'll keep you closer to a single toolset (C#) targeting multiple platforms making maintenance probably somewhat easier.
And the community edition of VS2017 is free (for individual developers) and open source...
Sample of doing a video conference app can be found here:
Thanks for the suggestion. But management has take the decision and I have to see to it that the project sails through and completes in given time frame.