Background
My background is high scale object oriented middleware and Applications development for embedded devices and desktops with C++. Now we need to create a high scale web-app for our startup.
Question
Request-response based and continuous polling based current web-development frameworks looks very primitive, inefficient.
I am looking for completely server-side object oriented and event based programming.
Here is an example it,
There is a persistent object named employeeManager on server,
methods of this object,
empList getAllEmployeeList();
empList getEmployeeOfDepartment(string strDept);
/*Some more */
events of this object
employeeAdded(empID);
employeeEdited(empID);
employeeRemoved(empID);
/*Some more */
Now, client side javascript should be able to call the methods of this (server-side) object and should be able to receive events of this object. We can have results of the method call in asynchronous mode. Framework should also provide a way so that view ( or html-js page ) can register for required server side events.
Is there any frameworks which works on this methodology. Anything like this on top of socketIO? Any framework which provides a good two way RPC between client javascript and sever side objects?
Try the following combo:
Node + socket.io + Backbone.Model + a bit of imagination.
I think the missing piece is a model like structure that can be used on both server side and client side. The model needs to synchronize state between server and client.
Here is an article that I find very interesting, and maybe you can use the technique described?
The article:
http://blog.andyet.com/2011/feb/15/re-using-backbonejs-models-on-the-server-with-node/
NodeJS and sockets.io. These can help achieve the desired effect.
Meteor is a Node.js based framework that uses sock.js for websocket communication and MongoDB for a database which is oriented for horizontally scalable apps. Meteor will pretty much do all the heavy lifting for you when it comes to client-server synchronization - you will not have to write any code for database syncing. The result is a minimal codebase with mainly your application's logic instead of the req/resp overhead. You can have a look at the examples here: http://meteor.com/examples/leaderboard
If you want cross-language RPC you might find Apache Thrift useful. I believe there's a Javascript client (but have never used it). You could build an RPC framework on top of Socket.IO as many others have pointed out, but it feels like painting a cat to look like a cow... i.e. fun, but not particular productive
I'm sure you have already, or have some legacy constraint, but in case you haven't I'd take a second to think about whether RPC is really the model you want to use. RPC leakily abstracts the existence of network latency, and as such bakes a few shaky assumptions into the foundations of your app. There's a fairly short and readable critique of RPC in general (by AST no less) that might be worth a read.
If you're familiar with C++, you may want to check out G-WAN. They have a great example using Comet (what you're looking for), and there are also Node.JS wrappers too.
G-WAN also allows for client-side applets written in whatever language you need too. So, for you, C++, might be just what you're looking for.
This is a very scalable web application server. From all the benchmarks I've seen, Node.JS doesn't scale well with high-concurrency (I may be wrong on this, if I am, please let me know, and provide me with the information). That being said, I've done things very similarly to what you're talking about doing. All I had to do was write a very simple wrapper to translate from JS to whatever language it was that I was using at the time (for me I've done it with PHP, MivaScript, SMT and C).
But the key (for me) was using Comet, to cut down on unnecessary polling of the server.
Related
Currently, I am developing a 2-player tetris game. Originally, I was planning to implement a client-server model in a mobile environment.
However, now I change into web game, which is accessible by a browser. Since I am not used to a web development, I want to know if client-server model is necessary in a web game.
To be honest, I am a little bit skeptical writing both client and server code since a browser does a job to connect to the server.
Is it possible to build a network-based game by using only one server without a client part?
Is it possible to build a network-based game by using only one server without a client part?
Nope. You need a client.
It doesn't matter if you're in the browser or writing a native application. Yes, the browser solves a lot of client problems for you - it implements HTTP for you, and it has display (CSS), content (HTML), and evented logic (JavaScript) that you can use. But you still need to write your client using those technologies.
Even if the browser exposed a call in javascript like this:
window.startPeterHwangsTetrisGame();
You still have a client. The client is 1 line of code, and it is exactly the above script*.
Realistically, you should look for a game-oriented web development tutorial and start there.
*(aside from the necessary HTML within which that javascript exists)
Well, in one sorta correct way, no, because you're not redesigning the browser, but nobody would say it like that. Web design includes a lot of code / markup used on the client (browser), and while your server is sending the browser the data, and that data is a mix of CSS, HTML, and JavaScript (as well as media like graphics and perhaps music), the browser is the piece of software doing the lifting on those pieces once it receives them. That data is selected by the server, so the logic for that is on the server, but this is what people would think of as "client design" in the context of a web application.
There are also a number of models (ways of arranging your programming designs) which would lead to cleaner code, and a lot of these would send a grouping of information (called a model) to the client (the browser) and then the browser would do some interpretation of how to use that data (called a view). This is a simplification since I don't think you're ready for a big dive into specific theories, but you could start with a JavaScript and HTML tutorial and then learn a server language:
Python is my favorite, but PHP is big as is Java (NOT to be confused with JavaScript), and I make my living doing C#. Really there are plenty of great choices.
One commentator recommended Node.js because you'd use JavaScript on the server with Node--just like for the client part (the response data you're sending to the browser). That's double duty, but I am partial to Python (as I said). Just pick something, and as you learn, you'll get to know what you like. If you change languages, it'll be easier to learn your second one.
First off, I am not asking for any code or anything like that.
all I need is some advise.
I'm creating a roulette game and everything in my roulette game is based on jQuery.
however, as we all know, jQuery is client side so I was thinking about using AJAX to send some details back to server and from the server to the users browser so I can make this roulette game work in "multiplayer" fashion... But the issue is that I don't think its possible to send the roulette's wheel animation to the server and back to users browser so I am a bit confused about this!
In my research I came across some information (old ones) about using node.js and jquery together! I don't know if this is possible or how easy it would be to use my jquery code in node.js as I have never used node.js before..
so the question that i have is:
based on the information i provided above and my requirements, what are my options?
can I use AJAX to achieve what i am trying to do and if so, a bit
information would be great.
if AJAX is out of question, is it possible to use my jquery code in
node.js to achieve what I am trying to do?
ANY ADVISE WOULD BE APPRECIATED.
P.S. I don't want to use HTML5 as 1st I don't know much about HTML5 and also, some devices, browsers do not support it.
Thanks
The best way is to use websockets to ensure real time communication. One of the best alternatives for implementing that could be using a server under node.js. Have a look to this video from Code School node.js tutorials: https://www.youtube.com/watch?v=mtDK4jf4RS0 where is ilustrated how to implement a real time chat. Your problem is based on the same.
There are three parts to a multiplayer game displayed in a browser:
client-side display,
server-side data management,
client-server communication.
If you're already set on your display technology (jQuery), then you're probably going to use $.ajax() for client-server communication. However, technologies used for server-side data management are completely up to you and they don't necessarily have any connection to the technologies used for display and communication (meaning the traditional communication initiated by client).
Basically, use any kind of server technology stack you like. Node.js might do just fine but there are many other viable alternatives. They just need to support communication with the client.
So, to be absolutely clear, your question doesn't really make sense. You might use jQuery in the client and Node.js on the server, but they will never really "work together". They will manage completely separate parts of your application and connect through protocols not specific to either of them.
As for the animation, the animation itself is solely a client-side problem. If you want to "synchronize the animation" across multiple clients, you can let the clients communicate with the server, but they only ever need to send/receive plain data. Then you adjust the client-side animation based on the received data.
As another poster points out, websockets are a better fit for this than regular client-initiated HTTP requests. Not because of "the animation", but because you want all the clients to receive the information about the start of betting at the same time.
I am also developing a MMO game using javascript only. Firstly, there are two different types of javascript here. Usual client side javascript (the one you already know) and the server side javascript (i.e. Node.js).
You will need to develop both client and server before connecting them with jQuery's Ajax. So you need to study Node.js before designing overall architecture of your game.
I read many Node.js tutorials and watched many youtube tutorial videos but I was still confused, before I really sat down and read a good textbook that explained from basics, one like below. Try to get hold of it from your local library.
Express web application development learn how to develop web applications with the Express framework from scratch by Hage Yaapa
Express is the popular framework that runs on Node.js now. So it's worth getting familiar with Express Framework. Once you understand how express app works (not so difficult), you will see how you can frame your game structure like I did :)
In order for many clients to share same animation, there must a server that synchronizes the game state. Ajax can only link between server-client communication in my understanding. There is no mechanism that connects between clients. The clients ask server what number was the result of roulette roll and show the corresponding animations.
Yes, you can use NodeJS and jQuery together.
NodeJS is server-side, meaning that you set up a server (a lot of people use the Express module, which is easy to use), which serves content to clients asking for it. Your server-side code can be in any language supporting sockets, not just NodeJS. But NodeJS is easy to use if you know JS already.
jQuery is client-side, meaning that it's executed by the user's browser, and may or may not have a server-side component (if it doesn't need it), or it might have one where it sends requests to the server-side code. When it requests a page from the server, it can be static content (like when you request index.html) or dynamic via an AJAX request. Client-side browser code must be HTML/CSS/JS (you can't make Firefox or Chrome interpret C, for example).
I would like to write a 3D application using Golang, my favorite programming language. However, I would prefer not to use native OpenGL directly as the graphical frontend as this would entail a larger learning curve than I'm willing to tolerate. Additionally, I don't really want to use a Golang game engine like go:ngine.
After doing some research I found out about the amazing WebGL Javascript library three.js and I was so intrigued that I completed an introductory Javascript course in a few hours. I'm not really a web developer at all, so I'm wondering how practical it would be for me to write my application primarily in Go but with a three.js frontend.
Some specific questions:
Is it worthwhile / practical to use Javascript/three.js as a frontend to a Golang server like this?
If it is worthwhile, where can I look to learn how to integrate the two cleanly?
If it isn't really worthwhile, which alternatives do I have?
Thanks, any response appreciated.
Edit:
Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets?
Yes, this is what I'm thinking now. I'm intending my (Golang) program to generate streams of vertices and triangles based on a few parameters from the user. Each "structure" is generated all at once after the users supply their parameters (which I see as slider bars + input boxes on a Javascript frontend).
Here's an example of something the Go program might generate, plotted in GNUPlot:
(source: alexozer.com)
If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I'd be fine with doing that, except for these reasons:
The core generating process fundamentally depends on Goroutines and channels
I know close to nothing about web development, including frontend and backend
So I suppose I'm asking about the implementation details of one of these three possibilities:
Writing most of the program, including the generator, in JS, and a minimal backend in Go
Writing most of the program in Go and using JS just as a graphical frontend
Something else?
I recommend leaving out the whole Websocket aspect because it's only a possible optimization (and maybe not even that).
If you need to depend on Go's concurrency model then go for it, write your component in Go, then a Webserver in Go that takes parameters coming from an HTML request, uses them to compute the result and sends back the data in a JSON format.
On the frontend you will then only focus on sending this request when the user changed a parameter and for displaying of the JSON data you can use ThreeJS right away.
You'll still have to learn a bit of web development and Javascript though. But hey, they say the web is the future ;-)
I think it's the way to go for your case because your application operates in a quite strict request-result way.
The answer to your question depends a lot on where exactly you plan to draw the line between your Go component and the Javascript component. From the way you describe the problem I get the feeling that you want to write most of your application in Go and use JS only as a display layer? I wouldn't recommend doing that.
To rephrase my question: Do you plan to make operations on geometry in Go, possibly in realtime and communicate with your Javascript layer using Websockets? If this is the case you underestimate Javascript a bit. You should write most of your application in Javascript and use Go as a classical backend service layer like user accounts, persisting state, etc.
I might be able to give a more specific answer if I know what exactly you plan to do.
If I only want to use JavaScript on the client AND server side for my future web projects, how would this Javascript embracing tech stack look like? Are there any data stores/formats that are more idiomatic/JS friendly than the rest?
The idea is to use JavaScript for single page web apps where most of the rendering is done on the client.
The closest thing to a standard setup for this kind of app AFAIK is something close to this:
Node.js server app (often using the Express framework)
Backbone client app (typically with jQuery to control the interface)
Socket.io for communication between the two
Your choice of NoSQL database for persistence (there are Node.js adapters for all the common ones)
Fog Creek did a write-up of the stack they used to make Trello, which is essentially this.
(Incidentally, for clients that read a lot more than they write, I'd recommend taking a look at Server-Sent Events in lieu of Socket.io. They're a less heavy way to do one-way stream-based communication.)
There are lots of questions here, but you probably already have the answer to most of them. Not addressed is a good data layer -- look into MongoDB and Mongoose.js (a nice Node interface to MongoDB). Essentially, MongoDB is a persistent store for JSON objects, which works perfectly when you're programming with javascript. It uses javascript as its internal query language as well.
For an interesting take on this kind of setup in the real world, check out this article (I am affiliated with that company/product, but it's still a good read).
It would look like
node.js + any of the multitudes of client side javascript frameworks, jquery, sencha, yui, backbone, ember, sproutcore, etc....
Node.js on the server side is probably what you are looking for.
I looking at using Javascript server side and took a look at persevere/pintura but for a novice like me, I need more documentation and tutorials and CouchDB seems to have a lot of that but is it used as a server side js tool?
Kind Regards
Yes (seconding what #Pointy said above). The JavaScript in CouchDB does run server-side. :)
Beyond that, though, JavaScript in CouchDB can do far more than just map/reduce queries. It's also used for document validation, update handling (for processing XML POSTed to CouchDB for example), as well as HTML or other markup output from either a single JSON document (using _show) or from the results of a map/reduce query (using _list).
CouchDB does not, however, offer filesystem access or TCP/IP listeners as Node.js does. Right now, the JavaScript is focused on the "shipping and handling" for the database contents (things like validation, formatting, and querying).
If you're interested in looking into options for handling things that CouchDB doesn't do "internally" (image processing, sending e-mails, etc), you might checkout my reply about CouchApp architecture options.
CouchApp's are definitely a viable option for web apps. Coupling those with replication, it's hard to beat.
http://nodejs.org/ is a great example for server-side javascript. If you don't want to write your complete webapp on NodeJS you can trigger it via the node command.
CouchDB is a database with an interresting feature, it allows you to interact via a RestFull api making it ideally suited to access over the web, either in javascript or other client environments. If you are looking for a server-side javascript development environment, try Servoy. It allows full featured server-side application development in javascript including easy database access to all major databases.
Short Answer: Yes.
Longer Answer:
There is a Javascript Engine shipped with CouchDB, which is SpiderMonkey
(the very first engine, open source, written by Brendan Eich, creator of javascript)
CouchDB's View function is JavaScript function running server side that acts as the Map half of a map/reduce operation to construct view.
Then there is client side javascript API, which can be used to communicate with the REST layer to fetch/update documents, which is also where jQuery is used by CouchDB.
More on CouchDB's both server-side & client side javascript capability:
The default engine is capable of doing many features, while package availability is limited compared to Node.js. Kan.so can be considered "NPM for CouchDB, where some packages are server side.
For example, there are frameworks like duality that try to make use of both server side & client side javascript capability to reuse code for rendering with couchDB.
More on the engine:
(The selection of spider Monkey over v8 is because for couchDB's use case the map reduce is not v8 designed for. Also include packaging, multi-threading and also historical reason v8 did not exist that time when spiderMoney is chosen) see [the mailing list] and tweet2
There is even project to port the whole CouchDB to Node.js (i.e. instead of Erlang), Chesterfield
I am glad if someone can add how Erlang talk with the javscript engine.
Thanks for everyone's answer, this is an important thing to make clear for people like me messing up couchDB with some Node.js packages
No, CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution.
http://couchdb.apache.org/
CommonJS can be used for server side JavaScript, see here: http://www.commonjs.org/
NodeJS is another: http://nodejs.org/