I'm starting a new Facebook canvas application so I can pick the technology I'm going to use. I've always been a fan of the .NET platform so I'm strongly considering it for this app. I think the work done in:
facebooksdk.codeplex.com
looks very promising. But my question is the following:
It's my understanding that when using an app framework like this (or PHP for that matter) with Facebook, whenever we have a call into the API to do some action (say post to the stream), the flow would be the following:
-User initiates request which is direceted to ASP.NET server
-ASP.NET server makes Facebook API call
so a total of three machines are involved.
Why wouldn't one use the Javascript SDK instead?
http://developers.facebook.com/docs/reference/javascript/FB.api
"Server-side calls are available via the JavaScript SDK that allow you to build rich applications that can make API calls against the Facebook servers directly from the user's browser. This can improve performance in many scenarios, as compared to making all calls from your server. It can also help reduce, or eliminate the need to proxy the requests thru your own servers, freeing them to do other things."
So as I see it, I'd be taking my ASP.NET server out of the equation, reducing the number of machines involved from three to two. My server is under less load and the user (likely) gets fatter performance.
Am I correct that using the Facebook C# SDK, we have this three machine scenario instead of the two machine scenario of the JS API?
Now I do understand that a web server framework like ASP.NET offers great benefits like great development tools, infrastructure for postbacks, etc, but do I have an incomplete picture here? Would it make sense to use the C# framework but still rely on the javascript sdk for most of the FB api calls? When should one use each?
Best,
-Ben
You should absolutely use the Javascript SDK when you can. You are going to get a lot better performance and your app will be more scalable. However, performance isn't always the only consideration. Some things are just easier on the server. Also, a lot of apps do offline (or delayed processing) of user data that doesn't involve direct interaction.
I don't think that there is a right or wrong place to use each SDK, but they definitely both have their place in a well built Facebook app. My advice would just be to use whichever is easier for each task. As your app grows you are going to learn where the bottlenecks are and where you need to really squeeze that extra bit of performance is needed by either moving stuff to the client (Javascript SDK) or moving stuff to be processed in the background (Facebook C# SDK).
Generally, we use the Javascript SDK for some authentication stuff and for most of the stuff with the user interface. The one exception to the UI stuff is when we are really concerned about handling errors. It is a lot easier to handler errors on the server than with the Javascript SDK. Errors I am talking about are things like errors from facebook or just general facebook downtime.
Like I said, in the beginning just use both and do whatever is easier for each task.
Related
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've done some research and I've noticed that in a lot of examples Symfony2/AngularJS apps the frontend and backend are combined; for example, views use Twig.
I'd always thought that it's possible (and common practice) to create the frontend and backend separately and just join them by API. In that case if I want to change a PHP framework I will can do it without any problems and it will be enough to keep API.
So what are the best practices for doing it? It would be great if you could explain it to me and even greater if you just give me a link to good example on github or something.
We have been developing some projects using the same approach. Not only I think it doesn't have any "side effect", but the solution is very elegant too.
We usually create the backend in Node.js, and it is just an API server (not necessarily entirely REST-compliant). We then create another, separate web application for the frontend, written entirely in HTML5/JavaScript (with or without Angular.js). The API server never returns any HTML, just JSON! Not even an index structure.
There are lots of benefits:
The code is very clean and elegant. Communication between the frontend and the backend follow standardized methods. The server exposes some API's, and the client can use them freely.
It makes it easier to have different teams for the frontend and the backend, and they can work quite freely without interfering with each other. Designers, which usually have limited coding skills, appreciate this too.
The frontend is just a static HTML5 app, so it can (and we often did) easily be hosted on a CDN. This means that your servers will never have to worry about static contents at all, and their load is reduced, saving you money. Users are happier too, as CDNs are usually very fast for them.
Some hints that I can give you based on our experience:
The biggest issue is with authentication of users. It's not particularly complicated, but you may want to implement authentication using for example protocols like OAuth 2.0 for your internal use. So, the frontend app will act as a OAuth client, and obtains an auth token from the backend. You may also want to consider moving the authentication server (with OAuth) on another separate resource from the API server.
If you host the webapp on a different hostname (e.g. a CDN) you may need to deal with CORS, and maybe JSONP.
The language you write the backend in is not really important. We have done that in PHP (including Laravel), even though we got the best results with using Node.js. For Node.js, we published our boilerplate on GitHub, based on RestifyJS
I asked some questions in the past you may be interested in:
Web service and API: "chicken or egg"
Security of an API server: login with password and sessions
I asked this (voted to be too broad) Question while working my way through a starter book on node. Reading this book, I'm sure I'll learn the answer to this later, but I'd be more comfortable if I knew this up front:
My Question: Can I (efficiently) continue using a usual webhost such as iPage or GoDaddy to host my web application, building and hosting the front end in a simple, traditional manner through an Apache web server, and communicate with a separate Node.js server (my application back-end) via AJAX for queries and other things that I can more efficiently process via Node?
More specifically, would this be a bad programming practice in terms of efficiency and organization? In other words, would it be likely that a large scale commercial application would ever be handled via this method?
Yes, you can separate the front-end of your web application and the APIs that power it. In fact, this is a very common configuration, especially for "large scale commercial applications".
Where you draw the separation line between the two specifically depends on what you are doing, how you're doing it, and what your needs are. Also, in terms of hosting, remember that if you're accessing something server-side across the internet, you're adding extra latency to everything. Consider getting off Go Daddy and using another host that gives you more flexibility, such as a VPS provider.
It's ok. Actually, this is how things shoud be done. You have a backend API on a separate server and lots of apps which are using the API. Just go with Nginx server, check this Apache vs Nginx.
Yes you can use node js as a part of some big application. It depends on wich type of interaction you would like to get. Is it comfortable to you to mix technologies? Then node is pretty good thing to work over web. I've finished a part of big nodejs-ruby-php-c-flash application (my part was nodejs) for very large data mounts. This application have different levels of interaction. Sometimes I use 2 languages at one time to create each part of my application the best for task I'm working on. There is applications that initiate, run and destroy mutiple OS instances. So using of multi environmental application not so hard.
Trying to understand using node.js for a web applications.
Are there basically 2 major uses cases, i.e.:
The entire system is written in node, so you have functions for login, logout, password recover, and whatever else the web app does. All of this is written in javascript?
You use node.js only for sending the client updates, to have a real-time effect on the app. But the rest of the application is written in e.g. rails or django
Please tell me if I understand this correctly:
In terms of other technologies used with node.js, you tend to see people using node.js as the backend server, socket.io on the client side to establish a cross-browser long running ajax call library, and then you might use backbone.js for your client mvc pattern.
Is this right?
Basically speaking, it is just a tool to run javascript code server side. What you do with it is up to you. Many are using it as a complementary system since it's relatively new, but it's perfectly possible to run an standalone app with node.js.
It's said to be particularly good at handling concurrent connections, which is why it is often recommended to handle real-time jobs within an app, but there is no "obligation" so to speak to use it for this specific use case, it's just one thing you can do.
As with everything, the best way to understand it is to use it, so don't be afraid to play around with it.
Use case for Node js as we are using in our Application
Skype like voice & video chat on chrome browser using node js
This is more of a curiosity really, to see if some one has done anything similar, or if at all it is possible.
I'm working on a project that will get notification through external notifications. Now I could go about doing this by having notifications coming to my server and have a comet setup between my client and server.
BUT
I was wondering if I could write server logic into my client and listen out for notifications from external sources. Immediately one issue I see is, external sources would need callback URL etc, which I dont know if you could do from client side (unless one could use the IP address in that way).
As you can see it is more ideas and discussions if such a thing was possible, this is somewhat inspired by P2P models whereby you wouldn't be mediating things through your central server.
Thanks in advance!
GWT compiles (nearly) Java source into JavaScript, so compiled GWT apps can't do anything that traditional JavaScript running in the browser cannot do. The major advantage of bringing Java into the picture isn't automatic access to any/all JVM classes, but the ability to not only maintain Java sources, which tend to be easier to refactor and test as well as keep consistent with the server, and to compile that statically defined code into JavaScript, performing all kinds of optimizations at compile time that aren't possible for normal JavaScript.
So no, while you can have some code shared by the client (in a browser) and the server (running in a JVM), you can't run Tomcat/Jetty/etc in the browser just by using GWT to compile the java code into JS.
As you point out, even if this was possible, it would be difficult to get different clients to talk back and forth, without also requiring that the browsers can see and connect at will to one another. BitTorrent and Skype have different ways for facilitating this, and currently browsers do not allow anything like this - they are designed to make connections to other servers, not to allow connections to be made to them.
Push notifications from the web server to the browser are probably the best way forward, either through wrapping comet or the like, or through an existing GWT library like Atmosphere (see https://github.com/Atmosphere/atmosphere/tree/master/samples/gwt-demo for a demo).