We're excited to announce our latest feature: RunKit Endpoint. One thing we've always wanted is a great way to use RunKit to experiment with HTTP servers. Node is for servers, and now with Endpoint, RunKit is too.
Endpoint turns any RunKit Notebook into a server by exporting a single function,
endpoint. This function takes a request and response, just like a typical
http.listen handler. That's it: no deploying, no ports to worry about. Your function will be called anytime someone visits the corresponding url on the runkit.sh domain. Here's an example:
exports.endpoint = function (request, response)
When you combine this with built in access to every package on npm, it's easy to make quick "micro-apis" to test out a new idea, connect two services together, respond to a webhook, or anything else you can imagine.
Much like literate programming, the idea here is to make APIs that can be read to understand, and be easily shared. Take a look at this oil paint filter example. It takes an image and makes it look like an oil painting:
But what's really interesting is that, in addition to working as a RunKit notebook, it can also accept input as an HTTP request. Here's a live example that posts to the oil painting endpoint.
Whenever you come across an Endpoint API, you can just change runkit.sh to runkit.com and see how things were written. That means that if it doesn't do exactly what you want, you can easily fork it and modify it. Think of it like Github, but for living services.
We've built some helpers that we think will make common tasks simpler: a simple JSON API helper, and a wrapper for using Express. You can read more about how to use Endpoint in the full documentation.
Endpoint is an early experiment right now, and we still have much work to do, especially in the UI department. But we are really excited about the possibilities and wanted to start getting feedback. So please, let us know what you think!