Hacker News Reader

Comment by tenaciousDaniel | Hacker News Reader

Calling it "server-side canvas" really throws me off. Why would a drawing API be needed on a server? For headless rendering?

If the benefit is to use the drawing API in a Node context outside of a server environment, that makes more sense to me.

View on HN

I have definitely needed this exact functionality in the recent past.

We had an application where a canvas-based editor was used to create diagrams, and then these diagrams were saved to a library. We wanted to have each saved diagram to have a preview image to better visually distinguish between them while scrolling. The ability to render a png on the server from the canvas would have saved us a lot of trouble.

> Why would a drawing API be needed on a server? For headless rendering?

15 years ago I was driving GD and ImageMagick from PHP to render things like staff ID cards, barcode labels for things, etc.

It was trivial to write a script that would render something quickly and just output raw image data, so you could <img src="whatever.php?name=Joe&department=Meat" /> and the image would be dynamically created and sent with the right MIME type.

Plenty of great use cases for this.

I was thinking on creating a turn-based multiplayer game for group chat in an app like Telegram. Then, whenever a player gave a command the server would draw the board and send the updated image to the chat.

It could start with something simple like tic-tac-toe and only two players. A player would tell the app a number between 1 and 9 corresponding to the place he/she chose. Then the server/bot would send the updated image to the conversation.

What do you think? :)

Not sure why that would have to be done server side though, couldn’t the server only be used for coordination/maintain state and then submit the current state/positions to the client and the client would render the board?

In his example, there is no client browser. The users are just sending commands into a telegram chat, the app is presumably only able to send API calls based on chat events responses. Its unlikely the app would be sufficiently featured to do the board rendering itself, although I am not really familiar with this space so I'm making assumptions.

As such, the backend would do the heavy lifting of rendering the board, and send the rendered board back into the message group.

I think one’s constrained by the chat application’s functionalities. Telegram doesn’t allow a bot to perform such operations on the client, last time I built one at least.

Of course one might be able to use emoji or text as a representation of said state if the game allows for it.

Someone I know is doing exactly this (well for discord) and I thought it was genius.

That's awesome. Do you have anything more to share about it? Maybe a project link or that person's contact.

I once built a simple website for a Netflix show where you could enter some text and it'd be played in an animation, but you could also save/share a video of it.

It was so much easier to build the animation in canvas for the site and just replay it to get frames for a video on the server than to try to make the video in some other environment and then show it in the browser.

> Why would a drawing API be needed on a server?

There are plenty of reasons to want to generate an image dynamically on a server. Dynamic image resizing to fit client requirements is one that immediately comes to mind.

Or dynamic images for emails

Reminds me of how some games or other sites had an image you could put in your forum signatures. I think Steam had one or some third party built it. Would show like the games you were playing and if in game and not... I think Skype and MSN had icons too that was a image but used your profile id in it.

I once set up a large bank (you've probably heard of the bank, you've almost certainly not used this specific project though) with server-side Adobe Flex. We were using Flex to display charts on the client, and needed a way to render the same charts for use in reports.

This would be really useful for similar modern projects.

Server Side Rendering is a good use case. If you want to pre-render a data visualization that can be loaded with a web page, you can use something like this in place of the browser's canvas, but use the same code to generate the data visualization

I can totally see myself using it to render PDFs server side (invoices, reports, etc).

I previously worked on an in-browser Hearthstone card renderer that uses Canvas. The rendering needed to be client-side for dynamic use cases (where the card would receive various effects thus change its look).

However I also needed to implement a server-side version of it that prerendered all the cards to PNG so that they're browsable without having clients consume excessive cpu/battery. Doing it using a separate codebase would have been hell to reconcile. Hence node-canvas.

I have built quite a few rendering servers for various use using canvas.js and nodejs. I also built a prototype for a dynamic video rendering server once - also based upon nodejs and canvas.js. It was slow but worked out as a proof of concept that became a fairly successful startup.

You're wayyy off here. There are all sorts of reasons to generate draw images on a server. Just look up imagemagick. And canvas has a much better drawing API and libraries for drawing that would be compatible.

To render all sort of dynamic information:

* visitors counter

* request IP

* game stats in forum signature (implemented this with gd and ruby)

For outputting to static files, like JPEG or PDF.

Reply on news.ycombinator.com