For now we have declared one Meteor 'Collection' to store all selected points as coordinates, we use this information to draw the path in the map web as soon as our page is loaded.

Then we add some code to add a point from the map into this collection whenever we detect a click event on it.

Hey, this is not reactive!

But wait, there's a problem: We have ready a little demo which can store paths and display them in your browser, but it's not reactive yet so the other clients can't get the updates!

The main reason for it is this information is stored in the database but it must be sent to other clients to be drawn in their browsers. But we are almost there: It's now when Meteor Tracker comes to help:

Tracker allows us to put some code into the autorun callback. This code is executed whenever a change happens, and it's in there where we have to call our function to redraw the path using the new dataset we just were notified about.

Now we have a reactive interface to share paths with Google Maps in real time using only a few lines of code. Great stuff! Thank you Meteor!

Documentation

Community

Comparing to Quintus, Phaser is more active project, as currently there are 489 watchers, 5600 stars, 1726 forks, 64 opes issues, and 556 closed one on the Github.

Adding juice

No matter which framework you use, to make game that is fun to play, you have to make them juicy. But what is juiciness and how you can accomplish it? Martin Jonasson & Petri Purho describe a juicy game in the talk as follows:

Real-time drawing demo

Try to open this link it two different windows, or in mobile and in the desktop, and try to write something. You will notice that every change is propagated immediately on the every screen, desktop or mobile.

Hint: double-click erases the board.

How it works: Meteor Reactivity

Real-time updates are implemented using the core feature of Meteor: reactivity, and is explained in depth in Chris Mather Reactivity with Contexts lesson.

In short, Meteor makes realtime the default - when data changes in your database, everybody's web UI updates automatically without you having to write additional code. How the real-time stack works internally in Meteor, and how MongoDB supports this feature, is well explained in David Glasser Next steps in scaling Meteor talk:

Drawing - SVG

Drawing mechanism is implemented using SVG, which as a vector image format, is well suited to draw graphics that can scale infinitely and plays very well with the responsive design approach. You can find more information about SVG on Learn SVG resourse.

Summary

That was a demo of a Meteor application, written in Javascript, which runs on Node.JS and stores data in MongoDB.

]]>http://blog.avrora.io/2014/07/31/real-time-drawing-app-with-meteorjs-and-svg/55891eb4-0f88-4956-b642-42d77e17d0d0Thu, 31 Jul 2014 10:35:07 GMTIf you have to log useful data in Meteor, you have different options: starting from collecting standard/error output, using winston or logging to the cloud service, like Loggly.

Logging from Meteor's infrastructure

The fastest way to deploy Meteor app is to use meteor deploy <site>. In this case, command meteor logs <site> retrieves the server logs for the requested site. However, if you want more control, or you need to deploy on your own server, there are different options.

Logging from your own server

If you bundle your Meteor application and run it directly from Node (this process is well explained in one of the screencast from Chris Mather @EventedMind, you might use forever to keep the process run forever. In this case, forever logs command will list log files for all forever processes, and forever logs <script|index> will tail the logs for