I am building a trading back-end that provides live streaming prices (over Websockets) and trading functionality (REST endpoints) to the web client. The back-end was planned to be build with Django. However, the back-end also needs to receive live prices over TCP/IP connection from the 3rd party server and further distribute prices over Websockets to end-users.
Django is powerful and has lots of built-in features out-of-the-box including REST framework, admin panel, ORM, etc.
However, how I start a TCP connection and distribute price feed over Websockets? Can I use a management command to start a new thread?
Should I rather look into a different frameworks like Tornado? Tornado is apparently good for non-blocking network I/O and Websockets. However, it's a complex thing with a lot of state.
If I could, I'd rather stick with Django. What would you suggest?
Related
We have a website which uses HTML, angular in the front end and java in the back-end. We use RESTful webservices to perform read and write operations to the back-end, as we have IOS and Android apps too. We have messaging service in our website and apps, I am trying to make it as fast as possible. I am doing some research and came along XMPP servers for faster messaging. Can I develop RESTful web services for XMPP servers? and which language and environment is best to do it?.
Thanks,
Mani
I believe XMPP-FTW is the thing you are looking for.
This module takes away all of the XML and works by hooking to events which are passed between client and server using a transport in JSON.
I'm creating an application that consists of a web-based front-end and a c++ back-end and has the following requirements:
1) There should not be any installation of web server like Apache or similar software
2) The front-end UI should be able to trigger the back-end to perform specific measurements
3) The back-end after the computation of the measurements should return the value to the front-end in order to be depicted on the WEB UI.
I'm quite new in network programming so I made a research and I found that the absence of an installed web server can be replaced by an http server implemented in c++ with a relevant library like boost or poco.
However what confused me a lot is the way/ways that the front-end and the back-end can communicate with each other. I'm aware that C++ is able to create not only a simple but also a web socket.
What I'd like to ask is whether for the aforementioned functionality a simple socket will do the job or do I need to use web socket? If a simple socket is enough to transfer the data from the back to front-end in what way the html front-end can communicate with the c++ back-end? In your opinion which is the most stable and efficient way?
Communication with the web browser requires the use of whatever features the web browser happens to support. A "simple socket" is not something that exists in browsers.
The majority of all web applications use simple HTTP requests (so-called "AJAX") to a "REST" interface for most interactions, and WebSockets for those that require the ability to "subscribe" to live changes or where bandwidth-efficiency is more important than resilience against disconnections.
Remember that the browser only (generally) supports JavaScript, and that your communication between front-end and back-end is transactional by default (that is, request-response as opposed to message handling.)
I am developing an Emergency Response System. I have developed my server using the Django Framework in Python. I have an Android Client which needs to communicate with the Server. My question is :
1) Should I use REST API for communicating between the Android App and the Django Server?
2) Or is there any other RPC methods (like RMI in Java) which should be used for communication?
3) The Client developed as an Android App needs to send requests/messages to the server based on the user interaction. Would a REST API be a good option?
Thanks.
Use HTTP. This is the easiest protocol available to you.
REST is an architecture pattern (it describes how you would design your API service and client). It is designed to use HTTP (a protocol).
In order to implement RMI you would have to find an implementation for JRMP on Android and then make sure that all your users have access to this over the network; you would also have to use TCP/IP which would be near impossible to implement separately on your remote clients (unless you have deep level control over them) and even then, the network should allow such access which most mobile providers will not.
It is not practical, and it will not work reliably.
What technology is Google using (and many other people, e.g. Apple's iCloud webmail client) to automatically update the UI when a new email is received?
EDIT: I should say that I am asking this from the perspective of building an extremely high concurrency app, so it will need to scale well. Think online IM client/chatroom.
It's called HTTP Server Push. Instead of continuously polling the server to check for new mail, the server HTTP server pushes the data to the web browser. HTTP server push can be achieved through several mechanisms, including long ajax polling, Comet and Web Sockets.
They use AJAX or Comet or WebSockets.
they are using ajax for querying data from it's backend in some regular interval. and for realtime Notification they use COMET for realtime data retrieval from the backend.
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