Posted by minoroffense on January 24, 2014 at 2:21pm
We're investigating using epic editor for a client site with Markdown. One of the options with epic is to override the markdown processing callback with your own.
To ensure that the live preview of the editor reflects what drupal would generate we were thinking of linking the javascript callback in epic to node and subsequently to Drupal's text formatters.
Has anyone tried something similar before? I'm curious what kind of performance we'll get or issues by calling back to drupal so often while folks are typing.
Comments
Hi, I've done something
Hi,
I've done something similar about a year ago, and actually wrote a long blog post about what we did -- and lost it all with a browser crash before I hit save :-(
Not a keystroke thing, but rather an integration with an external app. I have node.js running, listening for event updates the external system posts into it. Depending on the event received, node.js fires off a drush command that either inserts data into a Drupal instance, or more often, the Drush command connects to the external system's database to copy over data.
The nature of our operation is that this sits idle, but then certain activities trigger sometimes up to 100+ events all at once. Obviously, 100 drush processes is not something do-able on a small server!
So I implemented a relatively simple queue inside node.js, and so now the events get added to the end of an array, and a processing function processes them one at a time.
So this allows Node to handle huge numbers of simultaneous events, and Node turns them into serial events for Drupal.
In my case, these are asynchronous events -- nothing is waiting for a result. And it works extremely well, aside from the occasional exception thrown when we get an unexpected response.
In your case, I'm not so sure it would scale -- you're actually waiting for Drupal to process text before updating the UI -- I would think you could use Node to prevent a Drupal site from getting overwhelmed by traffic using a queue pattern, but I don't know if it would be that good a user experience... You could try, and if it sucks, move the markdown filtering to Node (and if you're doing it there, might as well move it to the browser?)
Cheers,
John
The problem will lie with how you hit Drupal.
I've used the nodejs module for some integrations similar to this. My experience is that you will take the biggest performance hit waiting on Drupal to respond. As an example see this small demo I wrote a while back. Register a couple users (There no restrictions on registration) and log-in each in seperate browsers. Create a game and challenge your other user. Then watch the lovely lag as you make moves. You can also see this briefly demoed on my Drupalcamp Austin talk from a while back.
The crux of the problem on the chess app, is that each time a player makes a move, Nodejs is telling Drupal to update a node, which takes time. When Drupal finally finishes the update it fires a callback function on the node side and the move is broadcast to connected users. Granted the above example is actually asking Drupal to do a write to the database, which is a much larger process than formatting text. Overall, be really picky as to how node hits Drupal. If you can avoid functions that are kicking off a full bootstrap or really heavy processes on the Drupal side (keep it to just processing text), then I'd say you'd be okayish.
Edit:
After reading John's response I agree with his sentiments. This really feels like it should be JS processing the text and leave Drupal out of it. It's really simple and fast to process markdown in the browser.