I am setting up server for a group chat mobile application. It is a purely group chatting application i.e. each message will go to multiple recipients. Hence I am choosing HTTP over XMPP.
Also given my back ground in Python, I have started developing the server as -"Apache + Django + MySQL".
Please suggest if there are better alternatives. If the current set up is good enough then also let me know, so that i keep on developing peacefully.
How important is the server vs the app for you? Could you consider hosting the app on a cloud service? Since we are the developers of https://apptimate.io, the most secure point-2-multi point communication service, includung strong encrypion and other goodies, we would like to invite you to take a look att what we can do for you as an alternative.
If you use our backend service you focus on the iOS, Android or HTML5/JS part of the application.
Related
I've been working with Django for one year now, to develop web site applications.
And I've just started to learn about Flutter, the cross-plateform solution by Google to develop mobile app.
Having this 2 IT supports TOGETHER for the same project would be ideal.
That means web site application and mobile app should "share" the same database, at least for authentication (user should have the same account for web app and mobile app) but not only.
Basically, principle of my web site applications is to give a random number from a list. A number can only be assigned once. So, mobile app should share the same database to get access to the list of number to be assigned.
is it feasible?
Please search for "RESTful API".
Maybe I don't understand all your mean. Client-server, Front-end back-end, Cross-platform concepts have been in use for a long time. Flutter(web or mobile) is often used for developing Front-end. Create a back-end which can be used for all of them
We r finally taking a leap into writing a mobile application for some of our platforms core functionality.
After spending some time - narrowed down that it is a HTML 5 application, CSS and Apache Phone gap to support different platforms mainly IOS and Android
We are writing WCF based REST services and have a question about securing the web service calls - specially ones for new user creation and login.
How can we ensure that the web service call to create a new user account or subsequently to log into the app is genuinely originating from a mobile device and not via a brute attack or someone trying to execute a service if they do discover the URL? Is there some kind of device identifier that we can depend on as part of the request (or something we embed into the app) etc or are there other more reliable techniques.
Any help would be appreciated.
Regards
Sid
Good question: I use the device plugin to get the device uuid and then hash it with the user email and the timestamp of the registration to create a key. One way hashing is your friend in this scenario. Keep all of your communication on https secure socket layer and create keys based on the UUID and you should be able to solve this problem.
I am new to Web development. And hence, if the question is dumb, please be polite. For creating my application, I had to take a decision of whether writing a web service or a web application. After searching a few questions in stackoverflow, I came to know that, web service is something which doesn't involve human interaction. And web application is what human uses ( the UI/web page kind of stuffs ).
But lately, I saw gmail is a web service ( email service ). But I was confused from here on, because, gmail provides a UI, and human interactions do occur. And from there on, I got confused again.
So what I figured out from this is, gmail website is like a web application for users to use directly. The web application in turn uses the web service provided by Google for email. Is my understanding right? So can a web application be a client for web service?
If I am wrong somewhere, please do correct me. I hope to be clear after someone throws light on this with some good example. Thanks in advance.
You are quite right. Basically a Web Service has several endpoints over HTTP (normally) that provides data (generally in JSON or XML) and are meant to be consumed by Web Clients. Sometimes the are also called Web API's (Application Program Interface).
A Web Application is quite similar to a Web Service but it provides an interface where the user can interact with. Usually Web Applications are consumers of Web Services or Web APIs.
Following your example, Google email is could be considered as both, a Web Service and a Web Application. It is a Web Service because it provides a set of HTTP endpoints that works independently of its Web UI Application (GMail). In fact, you can find third party Web Apps that interact with the Google email Web API.
This concept is very important when designing Web Solutions. Ideally you want to design and implement a good Web API, usually a RESTful Service (in JSON/XML). Then you or others will be able to implement different types of applications (Web, Mobile, etc.) because of this API.
I just started learning web services. In bottom up approach, I have found some examples without being deployed in any application server. I mean a standalone web service application.
Here is an example of such type.
I have also given a try and done a walk-through of deployable simple web service examples.
So far to my learning of web services, I got to know that firstly, bottom-up- approach is not recommended. Now, in bottom-up approach, this standalone web service. When is it applicable to follow standalone web service procedure?
Endpoint.publish();
I guess, this approach is provided just for beginners and not to follow as a real-time practice. Is my interpretation correct?
I would make my application as a standalone web service if it will have multiple clients like:
Web Client via a web browser
Mobile App Client
Desktop Client
Then I could build every one of them alone using whatever the technology I prefer, and make it consumes my standalone web service.
For example, You could imagine the guys behind Twitter started developing it by building their core system as web service, then they build an independent web interface application for it, then they built the Twitter Android and iPhone APP, and another one came and introduced a Twitter Desktop client like Tweetbot and TweetDeck ... etc
Assume there are 2 web services A and B setup in SOA infrastructure.
Web services A depends on information that is available from the locally installed Desktop application (its a legacy application based on C++ programming and provides C++ API to give the information needed by web service A).
The scenario is this: Human actor (which can be considered as Consumer of web service B)logs into a website and clicks a button which requests the service provided by web service B. As part of this request, his ID is sent. Web service B sends request to web service A with this ID. Web service A uses this ID to somehow determine a way to talk to locally installed desktop application of the human actor who originated the request.
The main problem how can web service A connect to desktop application and get the information in a reliable way using SOA infrastructure.
Assume that everything in this SOA is Java based except the desktop application.
The desktop application is basically like a CRM application with its own internal database and not traditional database like MySQL. It provides just basic textual information about the human actor and about the customer(s) of that human actor in his installed CRM desktop application.
I do want to use SOA related technologies even though it may be more complicated.
Given above details:
How can I use JMS to solve this problem?
If JMS is not the right solution, what about ESB and how can I use ESB to solve this problem?
The communication with the desktop application will greatly be determined by what different methods the application is capable of performing. If the application has a database backend, an ESB can facilitate communication with predefined adapters for the specific database being used. If the application has an api that can be tapped programmatically, that is a method as well. I am not sure JMS would be the appropriate solution since given your use case you would want a synchronous reply. Putting JMS in the middle (somehow) will break that reply and rather return an asynchronous response.
I would recommend looking more into the functionality available in the desktop application and with your findings start with evaluating ESB functionality. An ESB may be overkill for this use case but if you plan to do more operations like this it may become valuable.
I think the problem boils down to a Java Web Service A, having a requirement to talk to a C++ desktop application to get user details.
If the Desktop application is able to use JMS using Stomp etc, ActiveMQ or HornetQ maybe used. This also allows you to scale A into multiple instances across many machines, and use JMS to request user information from the Desktop application.
Another option is to expose a simple API (REST, TCP etc) on the Desktop application and make the Web Service A talk to the Desktop application using that. Again, you could distribute the A into multiple instances for scalability.
You can use an ESB to convert a REST call to TCP, or a SOAP to JMS etc. Basically any-to-any conversion. The Free and Open Source ESB UltraESB [http://adroitlogic.org] contains many examples, and is lightweight (~35MB) so the 'overkill' will be minimal compared to > 300MB+ resource hungry ESBs