I'm using Backbone.js and Python Django Combo.
For checking user is authenticated or not, I'm using setTime out method and call a method which make ajax call to the server.
I heard SignalR from my friend who is interested in .Net Technologies. This can emiting signal from server to client. So he say there is no need to poll periodically with signalR.
Any help or idea will be appreciated.
Possible data flow diagram:
.
If you want to control the data that is pushed to your web clients from your Django app, you will need to use SignalR as a relay of sorts which can be hosted with an ASP.NET app.
The ASP.NET app can have REST endpoints accessible only to your Django app, and can then from there based on the REST parameters push messages to some or all of your clients. Example of doing this with ASP.NET MVC.
The SignalR Wiki can be a good resource for this. You will also need to EnableCrossDomain for this setup to work.
If you don't like the idea of setting up another server just to push data to your clients you might prefer a cloud-based offering like Pusher with a prebuilt wrapper around their REST API.
If you want to use Python to actually push to the clients you can use something like tornado.websocket, but that won't support browsers that don't support the final WebSocket spec.
Related
I want to implement websocket to send push notification to client.
I am using django-rest framework as backend and angular2 as frontend.
I know that django support HTTP protocol only. And I am unable to get
any such links,blogs or resource which helps me to achieve websocket
completely.
Currently I am using polling from frontend.
There are some third party apps which I found and may be useful for
implementing push message. They are...
pywebsocket
tornado
Django Channels
I don't think showing some code is significant here because i have no
code relevent to implementation of websocket.
So can you people suggest me the best way to implement this thing.Any
link,any blog or any code which may help.
One possible solution is to deploy a separate Tornado app which communicates with Front-end using WebSocket. Then, whenever the Django Back-end wants to send a push notification to the Front-end, it asks the Tornado app and Tornado app delivers the push notification to Front-end.
I have described the process in slightly more detail in this answer of mine. You might want to have a look.
I am new to stripe integration. I've looked at couple of examples but I'm unsure where I should integrate stripe in my application. My front-end is in Angular and the backend is in django. Should I integrate stripe in Angular code base or django code base?
Both. Front-end: either use Checkout (Embedded Form) or their Custom Form. This will spit out a token that you must process on the server side. If you are using routing or have a complex app, then you probably want a library to abstract away from Stripe's default behaviors, as it uses a simple form action. This will cause a reload or redirection from the page which could be a problem if you don't want to leave the app. I prefer this lightweight wrapper, though others exist: https://github.com/tobyn/angular-stripe-checkout
Server: You include their library for your language (Python if you want) in a script written to process the token. This is what actually sends the charge to Stripe. Just doing the front-end side only sends them a token which shows up in the logs but does nothing. This is where you create a new customer, charge, subscription, etc. according to the API for your language.
Once you've got that set up, then you'll probably want to listen for their webhooks, save the user that is created in your backend with its created from the initial payment, etc.
You can integrate it both in the front-end and back-end, but if it's a single page app and the backend is REST-ful it makes sense to do it in Angular
See this article for example: https://www.airpair.com/javascript/integrating-stripe-into-angular-app
I'm starting an application which will have an API server and a UI server. The API server will use django rest framework, while the UI server will use Sencha Touch. The API server will accept http requests and send JSONs, while the UI server should accept JSONs and send http requests. I'm just wondering if Sencha Touch has the functionality to accept JSONs, and to send http requests. If it doesn't, then I'm assuming I'll need to run it behind a http server. Please let me know if Sencha touch can do what I need it to do, and if not, what my best alternative is.
p.s. let me know if you need any more info
Thanks
Yes, you can do this with sencha touch, jquery-mobile or a custom configuration of HTML, JS and CSS (e.g. bootstrap, jquery and backbone.js). You could use Django for both the API server and UI server. For the API, please take django-tastypie in consideration as you'll get JSON api's for free. The UI server will be very simple, as you'll be doing most things in the browser. Therefore, you could pick any implementation....
Yes, you are on the right track. See the following help article http://docs.sencha.com/touch/2-0/#!/guide/stores
You basically use Django to serve JSON and sencha on the mobile platform to consume it.
Cheers,
_M
I've built a JSON API in Django. I'd like to send real-time updates from an external service to Django to upsert a model.
I am really looking for insight on the best way to design the system with current/upcoming/active frameworks and tools. My thoughts are using node.js/Django/Foreman described below:
Existing Django JSON API
A node.js app, running via Foreman, that's subscribed to some external channel.
That channel sends node a JSON message
Node consumes message and makes an HTTP POST of JSON to a URL within my Django API.
Django API uses the JSON message to upsert a model within the Django application.
Now, it seems that I should be able to eliminate node.js from this equation, and have a service that lives "a little closer to home", home being the Django app, rather than having to cross HTTP.
Question being: Is the solution I have now an efficient approach, and is there a better way of doing things?
How do you need to subscribe to the other service? If the other service calls one of your Urls directly, just make Django listen there.
If the other service requires your side to act as server (non webserver, eg connects to you on some non web port) you will need to let a server run there, but again I wouldn't use Node but rather write a simple Python server (probably using the asynccore module), which you could start via foreman+manage.py and which would have access to models directly, eg wouldn't need to marshal the data into json just to send it to Django.
If you connect to the other service via a simple tcp connection I still would take the non node approach like described above.
P.S.: Don't bother to much about efficiency -- keep your system as simple as possible before developing over engineered solutions.
I have a set of embedded devices that run software written in c++. The API to communicate the devices is simple: get/set/acquire parameters and signals.
I'd like to implement common web application to access all of the devices from a single point.
My idea was to add XML RPC interface to devices and then use ActiveResource to access devices from the web server. This combination doesn't seem to be used at all in practice.
I'm free to choose any protocol inside the devices. What are your recommendations?
If you're already considering XML RPC I'm assuming you have some sort of web server running on the device. I would probably choose a RESTful web service over XML RPC. If designed carefully you could have corresponding services on your Rails app.
For example:
http://somedevice/signals.json - gets all signals
http://yourrailsapp/somedevice/signals.json - gets somedevice's signals; you could use an id instead here if that makes more sense (http://yourrailsapp/devices/1/signals.json).
You probably won't find much XML RPC stuff in the Rails community. Rails itself really pushes you towards RESTful web services. Specifically a resource-oriented RESTful architecture. There are great books out there about it but it comes down to using http methods (get, put, post, delete) instead of passing parameters and then some intelligent URLS.