I would like to start with a disclaimer that I have no previous coding experience at all, and I have just learned HTML, CSS, JS, node.js, phaser.io, understanding all the jargon such as API, asynchronize, I/O driven, cookies & session, etc.. all that in the past 1.5 months on the web by myself, so if my question doesn't make sense please let me know.
I would ultimately like to make a cross-platform online multiplayer "webgame" (No realtime interaction between clients), I know it is ambitious but I don't mind take one step at a time, finishing the game in the period of 2-3 years on my spare time as a hobbyist, so let's move on to the actual question.
After doing all my research I decided to use phaser as client framework, PhoneGap to compile for crossplatform, and node.js + passport + mongodb for server, user authentication and storage. Since there are no realtime element between clients, and there are more tutorial on using express along with the stack of backend packages mentioned above. I am more keen on using http protocol with express then using websocket or socket.io.
Now I have created a simple login screen with input field using phaser-input plugin, and a button to send the data out. I am surprised when I cannot find any Phaser API on http request.
Q:Are there any Phaser API to do a http POST or GET request? if not is it possible to implement jQuery Ajax (does phaser include the jQuery library already or do I need to include the script as well?)? And if I should use socket.io anyway?
I am working on a phonegap project that use html as login screen too.
First. Yes and no, Phaser itself is just a framework. Phaser 's not a library. But if you want to make http request, i suggest create a Network.js that abstract all of your network call on different platform .I think you can use:
IOS: use Cordova http request.
Android: use Ajax is fine. Yes and it is possible to use jquery. Cordova, Phongap, IONic is nothing more than a web view. So you can use whatever js library you like.
Web: use Ajax too.
Related
Currently, I have figured out how to make API calls to YouTube Data Api and getting the number of likes of any video. And I'm making the call every minute. I do not know, however, how to update the corresponding element in html with the updated value.
Previously, I had made API calls in app.get and then updated using response.send() but that meant that my number would only update everytime I reload the page. Then I took the code block out of app.get but realised I had no way of update the UI with updated numbers from the API call.
I would like to ask how I can go about doing this. Thank you.
for that, you can use WebSocket module
Websocket is just a protocol like HTTP and it provides a persistent connection between a client and server that both parties can use to start sending data at any time.
Websocket is also provided by many front-end frameworks such as flutter, native android, react native etc.
I'm building a web application using node.js, this is my first time working with node. I'm using express framework and I have a question about client side rendering.
All the tutorials that I have found online talk about express and server side rendering. They talk about how you can use jade the express templating engine, to serve rendered templates as reponse to your web application.
My application is going to be client heavy and most of the rendering will be done client side. I want to call server to just get plain JSON response and then render it client side, so server side rendering is not of much use.
In this case, is express a right choice? I really like the way I can write APIS in express but I'm concerned about how to serve my application. If I don't want to use the server side rendering it would mean that I would have to serve static HTML at the first call which seems weird to me.
You might want to try Emberjs if you want most of the work done on the client side. But still, you need to send the data to the client so one way is to build your app totally on the client side just by sending a plain html and working your way up there. You can also precompile jade
What you are describing sounds like you are searching for an javascript MVC(or other) solution.
There are a lot of possibilities. Take the right tools for the right job.
Try the following link to get an nice overview of what is possible.
Helping you select an MV* framework
I am trying to allow users to upload images to a site I have built with Meteor, which requires a server-side route I can POST data to. Is there a way to set up a route server side such that I can call Meteor code from it (for example, a route that I can call this.userId or Meteor.userId() from)?
Server side routing is on the roadmap, but not yet available the way you need it. (At that link, Server-side rendering is set for version 1.0).
In the interim, you can do some server side rendering with Tom Coleman's excellent meteor-router mrt package. It's unclear to me how much of this will make it into Meteor core.
More likely, however, for the file upload problem, this issue describes the problem, and it looks like people have had luck implementing imgur's xhr api or perhaps even better is this smart idea.
Hope this helps.
I'm looking into solutions for integrating Ember.js with Node.js+Express+Tower.js.
I just started looking into Tower.js (the last couple of hours), and it looks like that the framework provides a nice structure for placing both server-side and client-side code (similar to the assets folder in Rails).
Since everything is in Javascript, I could either place Ember application code:
Entirely on the client, i.e., send everything on first request.
Serve only what is initially needed, and serve the rest only upon request.
In the 2nd solution, one could render the views on the server and send pure HTML.
Also what about the application logic of Ember (controllers, models, states, ...). How can it better be integrated with server-side Javascript (e.g., node.js+Express+Tower.js), so that
repeated code is minimized. In an ideal scenario, you define each model/controller/etc once and its used both on the server and on the client.
We are integrating Ember.js into the core of Tower.js, this has been planned from the beginning.
https://github.com/viatropos/tower/blob/development/test/cases/support/emberTest.coffee
Not quite there yet. But it's happening next.
Ember currently works in Node.js and the Browser, as does Tower. Controllers on the server will work like Rails' with web socket additions. Controllers on the client will work like they do on the server and like with Ember, with web socket support - still fleshing this out.
I already asked a similar question but this one is a bit different/specific:
I'm about to start development of a social community site (for a local user group) with features like timeline, IM/chat, forums, ...
Node.js and socket.io (or now.js) on the backend. jQuery (and maybe backbone.js or similar) on the front end. Content is loaded via socket.io or ajax and navigation via url hash.
There are 2 things where I just can't decide which way to go. I hope here are some people who can provide some good or bad experience.
Templating on server or in browser? I'm not sure if it's better to load a complete html site + live updates (also in html) for timeline, forum posts, IM/chat, ... or use something like a REST api via ajax or socket.io and do the templating on the client site. I've never done that before. You need to download the templates, etc, etc. Has anyone experience in this? There are also 2 ways to implement a rest-like api: E.g. request a forum post, then request the user associated to that post and so on (just like server side MVC) - or - request a forum post and the server answers with all needed information.
Load content via ajax or socket.io? I'm definitively using socket.io or now.js for real-time communication (IM, chat) and pubsub (on mainpage -> subscribe to new timeline updates, on a forum topic -> subscribe to new posts). But should I also load HTML (or provide a REST-like API, see question 1) through the socket? When people open forum posts in tabs (which I usually do a lot) that would mean a lot of socket connections. And I'm not sure how long it takes for a websocket to establish connection.
So there a 4 ways to do this:
HTML via AJAX - probably the most stable way that doesn't need a lot javascript to do the templating - Browser can use open HTTP connections to request stuff.
HTML via socket.io - The websocket must be established to load content (may be slower)
API via AJAX - as it probably needs more requests as HTML via AJAX there might be some HTTP header overhead + you need to authentication in each request- I'm not a friend of too many ajax requests.
API via socket.io - Socket must only be authenticated only once and you can request API objects on the fly. However I would still load templates and js via HTTP for browser caching.
I know this is a huge post but I'm debating for many days now and just can't decide as it would be a lot of work to switch the system once started developing. This is not a public project, it's limited to ~10k-15k local people and thus must not be that perfect, a good opportunity to learn new things in my opinion (I'm completely new to node, classic PHP MVC + jquery dev here).
I think you should use a RESTful api on the backend, let the templating occur just on the frontend (maybe with Backbone) and only use Socket.IO for real realtime stuff (such as chat). It doesn't make any sense to use websockets for something like loading HTML, because it most likely never changes.
So my vote is:
1) HTML via AJAX
2) API via AJAX
3) Realtime communication, such as chat messaging (or other stuff that constantly changes) via Socket.IO
Though there really isn't a definitive answer, as it depends.
If you need to be search engine crawlable, you can NOT rely only on client-side processing. If your individual views are light, and/or you need to support mobile, you should have initial rendering server-side.
Currently, I would suggest using an API that both your client application and server-side can use. If you use node for the server-side rendering you can re-use a lot of the same logic, including the API client.
Going a few steps farther, if you look starting with the Yahoo flux examples project on github, you can use the same logic both client and server-side including rendering with React views. This is not an easy solution, and will take some work.
For interactive elements, server-side rendering can be minimal with your stores pushing an event wiring up via sockjs/socket.io when the client starts for your chat/im bits.
You will have scalability issues when it comes to running across multiple processes and will likely need a pub/sub chain backed by a db for longer re-connect cycles or missed IM messages. There isn't a magic bullet.
Right now, I like flux+react... When Angular2 comes out, it may have a better story for server-side rendering.