Open possibly opened 9 years ago
@possibly See, Rails is a REST framework. We will not use the whole REST capabilities while putting in more work than if we just make a simple Node server. One of the reasons I rejected Loopback was because it was heavily based on REST ideas.
@paulkass, Im p sure that implementing REST using http is just using POST/GET/etc for CRUD (create,read,update,delete) operations, which I think is what you want to do anyhow? If what you mean to say is you don't want to use a heavy handed framework when a few libraries will work just fine, I hear ya.
@possibly Last time I heard about REST it was a way of accessing the "model" by using subdirectories of the main domain, i.e. user with ID 9 would be accessed like "maindomain.com/person?id=9". Instead of having these kinds of ways of accessing the "database", I am just planning to have a "domain.com/getInfoForNewClient" routing for getting information about a new client, "domain.com/client?id=9,action=steal,space=4" for interacting with the client. I don't want anyone to access "domain.com/session?id=0" and know everything about that particular session. So to relieve everyone of the hassle of security and other weird things, I thought that would be the best option. Thoughts?
@possibly @paulkass
See Roy Fielding's dissertation for a proper explanation of REST. I agree that REST would be innapropriate for this project though, because state must be kept on the server for this game to function how we've imagined it so far, which goes against the core principles of its philosophy. If we'd like to use HTTP as the protocol for data transfer, we have to be creative with state. See Valve's Source Engine networking page for a good example of how state is transferred asynchronously to clients in most games.
Ruby (Rails) could be an interesting choice for this however. I've never worked with it, but given its maturity as a server-side language with great database support, I'm sure it could do everything we need. It seems to be hot thing these days as well.
For Java, I've looked briefly at the Play! framework, and it seems to be suited more to serving web-pages than data. I'd imagine this project would require a back-end that's somewhat disconnected from what you see (single-direction dependency). It would be better to use Java's http libraries for this.
As for javascript (node) and python, both of these would be more or less simple to use, and I've never worked much with node so maybe it would turn out to be interesting, if somewhat cumbersome without threading support.
Finally, C and its derivatives would be interesting in my opinion. C or C++ would probably involve using libcurl for requests, and I don't know what we would use for a server, because networking is very platform dependent at times.
C# deserves its own paragraph because it's as related to C and C++ as Java is. In fact it's almost exactly like Java, but with minor syntactic differences, and an amazing library called LINQ that's way more efficient than Java's stream classes for functional programming. It has ASP.NET, which I've seen used a lot in web apps, and of course, your standard request and socket libraries. Maybe you'd like to write the client library in C# to cut your teeth on it @possibly?
I agree that REST would be innapropriate for this project though, because state must be kept on the server for this game to function how we've imagined it so far, which goes against the core principles of its philosophy.
Ding ding ding!
The real question is how much can we salvage from these frameworks and libraries that focus heavily on a REST architecture which we will mostly completely ignore? Perhaps this conversation should be put on hold till we know what solution we want to come up with.
To be frank, I think using a framework would be more difficult than just writing a server with an HTTP implementation. The game model itself has nothing to do with websites besides the protocol used to communicate to the server. Someone could use curl
to play if they really wanted to. We won't be dealing with HTML or CSS at all unless we're talking about the visual representation, where something like Phaser or three.js would be better suited to the task anyway.
Its hard to understand whats more difficult or not until we know what our requirements are.
Guys, I think I found a good package for Node JS that will allow Comet-style interaction. Take a look at this post: http://stackoverflow.com/questions/6883540/http-server-to-client-push-technologies-standards-libraries
@paulkass Interesting post! Socket.io looks like exactly what we want. Its even better then pubnub
Proficient in: Python: Flask and Django Java (interested in using the Play! framework for web stuff)
Learning actively: JavaScript: Node and related libraries Ruby: Rails (this is the language and framework I would like to do this in!)
Would like to learn: C or any C derivatives, particularly C#