I'm developing a web based backend to an embedded system to which we have implemented the code for the servers get requests (all built in c). I need a lightweight solution to stream an array of data values to populate a graph built using the canvas tag. Im looking at the comet pattern and potentially the iframe solution.
However Im not sure how to implement this with out a full web server running? Im fairly new to web technologies and any help or pointing me in a direction would be much appreciated!
Thanks
Matt
As #Joe suggested in a comment, have a look at web sockets. Here's a few useful links to get you started.
Websockets 101
socket.io, client and server implementation
libwebsockets – HTML5 Websocket server library in C
Websocket test suite
Related
Hi I am thinking of developing a chat application preferably using angularjs2 just for fun (My intention is to learn a little bit of angularjs & mobile app building)
If I want to write a simplest chat application what technologies I should use and any resources?
much appreciate your help.
thanks
Gopi
Your will need use comet server for delivered message from server to other clients.
For example you can use this tutorial about using CppComet with php.
CppComet will install persistent connections via websockets with javascript. And you can send requests to CppComet using api from the php or other backend languages when you need to send any message to other users.
Technologies used to develop a mobile chat application:
Server : Ejabberd
Language : Erlang
Protocol : XMPP
Database management : Mnesia & Mysql
Multimedia files storage : YAWS
Operating system : FreeBSD
I think Firebase ( https://firebase.google.com/ ) is a best option to make chat application.
It's google powered so you have full support. They also provides notifications, live databases service maps and so much more.
If you are willing to learn core architecture see how actually Chat works you can try Socket.io ( https://socket.io/ ). It is used as core library for many chat applications.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.
I would like to build a mobile application with the following requirements:
The mobile client applications should request and recieve data from a database on a server.
In the future I will probably want to build a web application for the same database.
For communication between the clients and the server I would like to use Google Protocol Buffers.
So I have the following questions:
How does one set up a server to take request and respond with anything other than html. I think that using RPC sounds nice, but I have no clue how to set it up on a server.
I need to find a good web hosting service which will allow me to set up a database and a server that can serve both Google Protocol Buffers and regular web pages with data.
Before I get to making the web app, is there any more lightweight solution that might be better just for communicating with the clients (maybe even a home made tiny server), and how hard would it be to do it with a full scale web server from the start?
Please point me in the right direction so I know what to read up on.
I'm not necessarily looking for specific names of web hosting services but rather an idea what kind of services are available that might meet my needs. I've worked a little bit with django, Spring and Java EE so if there's any solution involving those that would be great, however I'm not afraid of learning something new.
Thanks in advance
Simon
if you still mean http, that is pretty trivial - you simply set an appropriate content-type, and write your data to the response stream. The exact how depends on your web framework and tools, but this is no different to (say) serving generated images on the fly. HTTP requests function fine for messaging scenarios - as simple as making an http request (typically POST) with a protobuf (etc) body, and processing the response in the same way.
can't comment
a web app can be lightweight; certainly more-so than having to configure a non-http service/daemon. The "lightweight" option would be raw sockets, but that is harder to deploy, and you'll have to be more picky choosing a host. Unless you absolutely need this level of terseness (i.e. dropping the http headers and writing your own transport to get close to the wire), just stick with http - it'll be a lot easier to get going and maintain
For info, I have a blog post on doing this with ASP.NET MVC; this isn't intended to mean "do this" (heck, use whatever tools help you) - simply, it is meant to show the kind of thing necessary.
I would like to write a client application for Android that uses the Google App Engine as a database backend. My Android client would connect to the App Engine to save information, then it would connect later for reports. Is it possible to use the App Engine as a backend like this?
If you're looking for something like the remote api that the App Engine has in python, then you'll be disappointed to find it missing in Java.
That said, absolutely nothing stops your from hitting your app and posting data either through POST / JSON / XML / any other format you can think of. The same thing goes for getting your reports back.
If security is a concern, the OAuth protocol allows you to authenticate to app engine from your android device.
This is an aside, but as far as reporting is concerned, you might not find the app engine a very suitable platform for reporting type apps. Just make sure you understand its limitations - the lack of joins, 1000 object limit, no sum / average, necessary indexes, etc. It's certainly not impossible, but do think carefully about how you're going to model your data.
Yes, it is possible.
Without more details in your question, any more details in the answer would be speculation.
Yes, its very much possible. It's something I am also currently working on.
My code uses HTTP GET and HTTP POST and I am using a RESTful service on the GAE.
I'm sorry I can't provide any code because I am still learning however the library I'm using is called RESTLET. They have libraries for both GAE and Android however I'm only using RESTLET on the GAE and I'm just using the HTTP library in the Android SDK for the client.
http://www.restlet.org/
The version you require is 2.0 M6 and not the stable release.
No.
In your response to Laurence, you said you want a direct DB connetion. A client cannot connect directly to the GAE datastore. You must write web handlers to interface between the client and your data. It doesn't have to be much, but it must be something.
Yes, it is very possible. You would not connect directly to the GAE database though. A better architecture would be to make your app hit a URL that writes to the DB. For example, you could set up a Struts 2 action that takes the values of your query parameters and then mutates and validates them as necessary before persisting them.
I want to implement a web-based IM service on the lines Meebo. Might sound ambitious but that adds to the fun of it.
My research suggests XMPP would be a good protocol for the IM since it can talk to proprietary protocols as well. Am I right? What else would I need to complete this?
Could Google App Engine(GAE) fit in to this project? Can GAE be used to create and host the whole service? That would simplify matters significantly.Also,GAE does support XMPP.
I know what I want to make, need to know the best way to make it.
Thanks!
Suvir
GAE has an XMPP API that lets your app send and receive XMPP messages. The real sticking point with making a real time chat app using only GAE is that you can't push updates to the client. So your client would have to continually poll the server to see if there were any new messages. One way around this is to operate a comet server outside of GAE to forward the pushes to the client.
wikipedia page on comet techniques
Google App Engine allows you to use stateless HTTP requests and XMPP, but not TCP sockets. Thus you're limited to any IM services which use the former.
For an example of using the XMPP service, see Using the XMPP service:
For our example app, we're going to
write the Amazing Crowd Guru. The
Amazing Crowd Guru is a veritable
oracle, who can answer any question
you might pose it over XMPP. Writing
an omniscient computer program is no
small task, but thanks to a little
behind-the-scenes trickery, we're
going to get our users to do all the
work of answering questions for us.