Yogi Yang: [WX] - Need advice on possibilities

Autor: Yogi Yang

Link zum Beitrag: [27130.foren.mysnip.de]

Hello,

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.

TIA

Autor: Steven Sitas

Link zum Beitrag: [27130.foren.mysnip.de]

Hi Yogi,

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 .

I am a great fan of using the right tool for the job.

Regards
Steven Sitas
[www.alpha360.biz]



Edited 1 time(s). Last edit at 09/06/2018 06:44PM by harvey68.

Autor: Peter Holemans

Link zum Beitrag: [27130.foren.mysnip.de]

Hi Yogi,

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,

Peter Holemans

Autor: Fabrice Harari

Link zum Beitrag: [27130.foren.mysnip.de]

Hi

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.

Best regards

Autor: Mary Mary

Link zum Beitrag: [27130.foren.mysnip.de]

[www.udemy.com]

This course has a section where they build such an app.

I expect what you need already exists and available as SAAS; Or, you
could re-invent the wheel?

Autor: Yogi Yang

Link zum Beitrag: [27130.foren.mysnip.de]

Hello,

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.

TIA

Autor: Steven Sitas

Link zum Beitrag: [27130.foren.mysnip.de]

Hi Yogi,

good luck !!!
But "first beta by end of Oct 2018", that means you are really fast

Regards
Steven Sitas



Edited 1 time(s). Last edit at 09/06/2018 06:50PM by harvey68.

Autor: Peter Holemans

Link zum Beitrag: [27130.foren.mysnip.de]

Hi Yogi,

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...
[visualstudio.microsoft.com]
Xamarin:
[visualstudio.microsoft.com]
Sample of doing a video conference app can be found here:
[www.youtube.com]

Cheers,

Peter H.

Autor: Yogi Yang

Link zum Beitrag: [27130.foren.mysnip.de]

Hello Steven,


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.

TIA