I am currently working with Django but I am stuck as I don't know if I am pursuing the right model given the nature of my application.
Problem Statement:
I have to make a REST API for a client such that whenever I get a trigger for a new entry/entries in my Database I have to send those to the client which is supposed to listen to a URL and has asked for data only once and now is open to receive data whenever available to him.
It is not sending a GET request now and then.
There will be different endpoints of the APIs. One is where I provide him all the new data available to me and in other where it asks for specific data (ex: '/myAPI/givemethis')
I can easily implement the second requirement as it is a simple request-response case.
I am not sure how to send him data that too on availability without him making a repeated request as client.
It appears a Publisher-Subscriber model is better suited for my use case but I don't know how to implement it on Django.
I bumped into several concepts like StreamingServices and MQTT but I am not sure what should be the right choice to go with.
Kindly provide some suggestions.
Related
I have a channels app that is using databinding. When changes are made with django admin they are being pushed to the web as expected. I have loop set up on a socket connection to do some long polling on a gpio unit and update the db, these changes are not being pushed to the web. Channels documentation says:
Signals are used to power outbound binding, so if you change the values of a model outside of Django (or use the .update() method on a QuerySet), the signals are not triggered and the change will not be sent out. You can trigger changes yourself, but you’ll need to source the events from the right place for your system.
How do I go about triggering these changes, as it happens with admin?
Thanks and please let me know if this is to vague.
The relevant low-level code is in lines 121-187 of channels/binding/base.py (at least in version 1.1.6). That's where the signals are received and processed. It involves a few different things, such as keeping track of which groups to send the messages to. So it's a little involved, but you can probably tease out how to do it, looking at that code.
The steps involved are basically:
Find the right groups for the client
Format your message in the same way that the databinding code would (see this section of the docs)
Send the message to all the relevant groups you found in step 1.
Alternatively, you might consider using a REST API such that the socket code submits a POST to the API (which would create a database record via the ORM in the normal way) rather than directly creating database records. Your signals will happen automatically in that case. djangorestframework (server-side) and requests (client-side, if you're using python for the long-polling code) are your friends if you want to go that way, for sure. If you're using another language for the long-polling client, there are many equivalent packages for REST API client work.
Good luck!
I want people to controll my arduino robot via the internet. It's important that the controlling reacts very fast. The user may send many requests per second.
Let me explain my architecture:
The user connects to a web-frontend. He can use a virtual joystick and buttons. The frontend will then send orders (like "motor1:255" "motor2:0"....) to an application server (Wildfly).
When a frontend-session starts, Wildfly will establish a connection to my computer or smartphone using a socket. The orders will be passed to the arduino using bluetooth. When a frontend-session is not longer active, the socket will be closed.
One Wildfly should be able to controll up to 10 robots. One robot can be controlled by exactly one user. Some developers use a mysql table and add a row for each incoming order. I don't think this would work in my case.
Is it okay to use REST to send the orders from the frontend to the application server? Is there any other fast and secure way to transport the user input from the frontend to the business logic?
Goot
REST, when properly understood and applied, is a solution for problems of long-term evolution and maintenance of your application. It doesn't seem to be your case.
What you mean is probably if an HTTP API is a good solution if you have lots of requests, and the answer is, it depends. I'd probably look into something like ZeroMQ for doing what you want.
I've been assigned a small project and directed to use Mirth Connect as part of the solution. We currently do not use Mirth but because we have an upcoming project that will require an interface engine, I was asked to use it for this project so I can gain experience with it. However, I think it's a poor suggestion for this project; I also know my boss would not want me to implement something that adds unnecessary complexity just for the sake of learning.
With that said, I want to make sure I have valid reasons for suggesting that Mirth Connect should not be used for this project. Neither of us know much about it, but I think he's been convinced it is the end all solution for all things interface/webservice related. I appreciate any input I can get from those of you who have more experience with the product than I have.
This is a very simple project in that we have a client needing to make a handful of requests into our system from there's in order to retrieve and update data. For example, they will make a request to get patient demographics, to add an admission for a patient, a request to get a list of possible care settings from our application, etc. For this project we will not use HL7 but a set of predefined XML messages.
Both the client's application and our application reside on the client's network.
They do not want to build any services of their own, so the services we build need to handle all of the work. The results returned in response to their calls to the services will be returned as XML.
There are no plans to integrate any other applications with theirs or ours in the foreseeable future.
It seems to me the best option would be for us to build a standalone web service that would take their request and send back an XML response. I just don't see any reason to include Mirth Connect in the picture (other than for learning but that can be gained in other ways).
What are your thoughts? Is it true that the interface engine is not a good choice if the client wants to receive data from our system without having a receiving mechanism on their end? In other words, they want to make a web service call such as GetCareSettings and to get a response back with an XML representation of all the possible care settings in our system. It seems to me they would need a web service on their end for Mirth to use as a destination to send the results. All Mirth is going to send back is an ACK message, correct? (Unless of course it wrote the data to another webservice on the client end, which they have said they do not want to do.)
Thanks for taking the time to read this. I hope my lack of knowledge and understanding of Mirth Connect and the use of interface engines hasn't made this question difficult to answer.
From what I understand, Your client appears to be either a Lab or a third party service vendor, who will take inputs from your application like patient demographic charts, appointments, provider details etc. Basically he wants to query your application.
A) HL7: It has the capacity to handle query request and response with demographics. I am assuming that you have done you might be knowing about QRY messages.
B) XML/webservices/SOAP:still provides a viable solution, a little more concrete and can be expanded to Handle custom request like GetCallSettings, or may be any other. The vendor is not just interested in fetching patient related data but also other inputs for which HL7 might not be enough.
If we talk about approach, then its a professional advice to use an interface engine. It is not limited to just using mirth connect, you can also use Iguana if you want. A good reason which comes instantly to my mind is that an engine gives you an advantage while troubleshooting, support and maintenance activity.
Your Webservice responses can be handled easily by HTTP sender connector type and through RESTful webservices.
The engine is also capable of handling large volumes of request and responses at the same time, which in case is not required right now, but I think will be the condition later on. Your source in the channel shall change to an Webservice Listener.
Another good approach is to do away with XML and use JSON for handling request and responses, a much more light weighted than XML, to save your overhead with the network. We are doing some similar work, but we are sending request to a webservice through JSON.
Overall, Mirth is there to make your life more easier.
Good Luck!
I'm starting with WebSockets, I already built a chat web-application as an exercise and it went something like this:
Every user has an opened websocket connection at their arrival to the chat-room, and when new messages are available, they're simply pushed to each user. The different messages are then displayed using javaScript.
Now, I'm trying to push the exercise a bit further by creating a one-on-one chat. Basically, there will no longer be a unique chat-room but private chat conversations. A user should be able to talk to different people from the same page. (Something like Google chat or Facebook chat).
After thinking about ways to do so, I came down to two solutions:
Open multiple websocket connections. (if possible)
Use the same connection to handle all opened conversations. Basically, each message that is pushed to the client will carry a field saying to which conversation it belongs, a javaScript will then handle the display of each message under the right conversation.
To me, the second solution seems better than the first. So, my questions are:
1- Will this solution have any performance problems? (Lost messages...)
2- Is there any other-better way of doing this?
The way to go depends (IMHO) on what framework you are using to do this communication.
I (as you) would go for multiplexing (second option) where you use one connection to handle all communication.
I assume that your framework of choice supports publish/subscribe and multiplexing?
I can provide you with a simple example if you like.
Regards
Uffe, Team XSockets
I'm currently using Jetty as my websocket server and I'm trying to make a real-time game. I'm really new to this. So far I've managed to work on the easiest one (which is the chat). Now, I have a couple of issues:
I'm trying to make a list of the current users connected in the server; how do I make such feature? I don't really know if this is practical but my idea is that there's a time interval that lets the server know that "Hey, I'm still alive." I want my user list to be dynamic in such a way that if a user logs out, the list will refresh.
I'm also trying to make "rooms" for my app. Basically, the people in "Room 1" can't see what people in "Room 2" are doing; the other room functionalities are already self-explanatory. I still don't have an idea for this; can someone recommend a way to implement this?
So far I've been having fun in learning this technology, and I would be very glad if there would be incoming help. These two are my issues so far. I'm also open for any suggestions for my app.
Thank you all in advance. :-)
(Uhm, can #1 and #2 be solvable solely by Javascript?)
Your question isn't really jetty or websocket specific.
Websockets simply provide a transport mechanism for your web browser to communicate with the server - what gets set over that transport, and how the server manages information are completely separate to the websocket.
Firstly, if you haven't read it already, read this article: http://cometdaily.com/2010/03/02/is-websocket-chat-simple/
Secondly, consider using cometd to make this easier - version 2 (currently in Beta) supports websockets.
As for your questions - there are 2 things you'll need to do (cometd can help with this)
1. Define a protocol
Define a messaging protocol to sit on top of websockets. Websockets just provide a way to send chunks of data around, they don't define what that data means. You'll need to build something that does that, so you have messages that go from the client to the server like.
CONNECT "user"
STILL_ALIVE
JOIN_ROOM "room1"
LEAVE_ROOM
GET_USER_LIST
SEND_MESSAGE "message"
And then you need messages form the server to the client
RECEIVE_MESSAGE "user" "message"
RECEIVE_USER_LIST "room1"
You need to come up with some reliable way to send that data over a websocket. You can invent your own simple protocol (like the Jetty chat example does), you could use JSON, or XML, or CometD channels.
2. Server-Side State
If you've got simple chat working, then you must have made a start on this, but the other bit you need is a way to keep track of
how many users are connected
what their names are
which socket they're connected to
which room they're in
Depending on how complex your system is going to become, you might be able to just store that in 1 big singleton on the server.