I would like to draw 100-200k features/icons/markers to be used with openlayers v3.
Based on readings, the approach would be either to dp clustering, or let the server handle the drawings, in other words, use layer for that. This applies for google maps api.
So, i plan to use node.js (or php) for this task, but did not manage to find a proper module for node.js to do this.
Please recommend a module for this.
Or at least, how can i draw a png on node.
Specifically, I would like to create a layer where a request to my server, e.g: map.my.com/x/y/z.png would draw the markers on server (or predrawn), and not draw them on client side.
Related
I want to implement magnetic effects in my web application, I am fabric js canvas to add items on the canvas.
I have gone through the documentation but didn't find anything relevant.
I currently have a running D3 data visualization that uses data from a JSON file with 500 objects to build a force layout graph. The application is built using node and express. Is it best practice to keep the data on the server side, even if it is a relatively small amount? If moved to the server side, should it be stored in a mongo db, or just as JSON file?
If it is a static visualization, I would say a JSON file would be just fine since it integrates easily with d3.js. If it is data that changes dynamically, a database could be a better choice since it could be easier to update in other parts of your application. That would just require more complexity in your d3 javascript code.
Supposed I have a web application that is built using Backbone.js and Handlebars. As server I am using Node.js. Now I want to do rendering on both ends, i.e. on the server and the client.
When a route is requested for the first time, the server shall do the rendering (mainly due to performance reasons). After that, all following actions shall result in client-side rendering.
This means that I must be able to render any page on the client and on the server, both times in the perfectly same way. Both ends have to support the same kind of routes.
How could I accomplish this task?
At the moment, I have taken a look at AirBnb's rendr project, but this definitely ties me to Backbone.js (I'm not sure if I want to stick with Backbone.js for all times), and seems to be not perfectly finished yet. At least, AirBnb does not recommend it for production use yet.
Any other ideas on how to do this?
As a sub-question I might also ask: What is the preferred way to share JavaScript code between the server and the client? For this, I also know piler, but I could imagine that there may be better solutions available.
Any hints?
Well, I am building an application that does this. If you don't want to use rendr, you will have to code your own versions of some of the things they take care of. AFAIK at the moment your choices are rendr or home-grown. Here's some misc tips.
We use cheerio for server-side DOM operations, so when views render on the server, this.$el is a cheerio element instance. In the browser, it's jQuery.
You don't need event delegation and binding on the server side. Our code technically does this at the moment, but it's pointless and a cleaner solution would avoid it on the server
Once you have server-rendered HTML in the browser, you need a way to wire up a big nested tree of view instances to their corresponding elements in the big nested DOM tree. We have a home-grown solution for this, but Backbone.View.setElement is the core and you'll need to write some code to make this happen
We are re-rendering on the browser at the moment although there's probably a slicker way to take a view instance, give it some options in the constructor including a pre-rendered DOM node, and get things properly wired up without re-rendering. That's an exercise for the reader though. :-)
We also send down the raw data we need as JSON within a <script> tag so we have both server-rendered HTML (for perceived performance) and the raw data available as JSON so we can get our backbone models and views instantiated and operational. Again, you'll have to come up with some code to manage this situation.
We use browserify to bundle and share code between server and browser. All of our JavaScript is coded as CommonJS modules.
We have a basic isBrowser() function in our view parent class so we know when browser-only code should run for event bindings, etc.
Anyway, for what it's worth, after working this way for many months, I don't think backbone works well with this paradigm. Many of the core concepts from backbone are fine, but it doesn't lend itself to mapping view instances to pre-rendered DOM nodes. Bootstrapping models and collections from JSON is easier, but the view layer probably needs a significant fork to operate cleanly in this style.
I communicate with the server through jsons, which both in Nodejs and in Actionscript are objects (serialized through string).
Those objects I use in my client, by reading / modifying them and also creating secondary objects (from Classes) relative to what came from the server.
I have one of two options to design my client and I am stuck at deciding which of them is more flexible/futureproof.
Keep data as it comes, create many methods to modify the objects, keep secondary objects somewhere separate.
Convert the data into instances of classes where each class has its own group of methods instead of piling the methods in the same place.
Usually I go with 2 because OOP is delicious but going with 1 seems much simpler in terms of quantity.
I guess my problem is that I can't figure out if my client is basically a View (from MVC) where the server is the Control (also from MVC), or if my client and server are two independent / separate projects that communicate, and I should consider the client as a MVC project in itself.
I would appreciate your 2 cents.
From your question it's not clear what 1. and 2. differ but looks like 1. is tightly coupled while 2. has better separation of concerns.
It depends on your application. Do you need to create client heavy app with rich UI/UX elements, or maybe a mobile app where bandwidth is limited? If the answer is yes, then go with a second approach (2.): build your MVC like structure or use existing MV* libraries, like Ember, Angular, Backbone, Knockout, etc.
If you need SEO support and don't have much of fron-end code, then rendering on the server-side is still an option. Even with this approach ORM like Mongoose can come in handy.
PS: JavaScript doesn't really have classes, because objects inherit from other objects. You can use prorotypal inheritance patterns for that.
we are developing an application similar to google maps. We are able to sucessfully transfer images from server to clent. we want to provide zooming capability to the images transferred to the clients. we are using Ubuntu for our application.
Thanks
-Roy
You might look at OpenStreetMap's Slippery Map where they did basically what you want for the OSM project.