Building an API in 60 seconds, without any server setup

You may be interested in my Python-on-ZeroVM-On-Docker Dockerfile[1]. This adds the security and isolation of ZeroVM on top of the connivence of Docker.

Note that ZeroVM isn't an x86 VM, so you need a custom Python (which that Dockerfile downloads). There are also no network sockets, so some things are difficult to make work, but you can work around that by using network code in the Docker container, and riskier code in ZeroVM.

I'd be pretty confident in that security model.

However, it's six months old now, and likely to need some updating. ZeroVM was changing pretty quickly when I was working on it.

[1] https://github.com/nlothian/Acuitra/tree/master/infrastructu...

Prelude's support libraries plus at least the curl package: https://hackage.haskell.org/package/curl

I really don't understand what's happening here. I think we use the term "API" and "server" differently. When I think of an API, I think of a library or something that I can link to. For example the POSIX API, or the P-Threads API. These are available in one way or anther from any language.

This seems to think very differently about APIs. As if APIs are somehow tied to a specific language? When they use the term API, do they maybe mean library?

I think that under the hood, the idea is that, if you want to do something, in another language (rather than just writing it in the language) you somehow generate a stub in both languages and then proxy through a (network?) connection?

To make this more complex, it seems that the proxy connections are not just on the local machine, but over the internet to another machine. Presumably you have to pay for this?

Am I right? This seems like a lot of effort to go through just to avoid figuring out how to do something directly. With really sucky performance implications. I guess it depends on what you're doing. Most languages support a foreign interface to C, so maybe that is a more sensible way to do this rather than setting up "servers" and tunnelling commands and data back and forth.

EDIT: I just had another look at the website. So, when they use the term API - it would seem that they mean some sort of an HTTP based web interface? The idea is that you have some kind of script that does something for you and you can query it from you local script. I still don't understand why you'd want to do this over running it locally?

I think the idea is that if you have a useful script, you can set it up here just once and it's automatically wrapped with an HTTP-based interface so you can use it like an API. Now you can use that script from any Internet-connected device, with basically zero setup on each device. I'm not sure if I can think of something I'd want to use it for, but this is an interesting idea and a great proof-of-concept implementation.

I think perhaps the most interesting part of this is that they're apparently spinning up/down Python (and other languages) sandbox environments on the fly, nearly instantaneously.

Some random highly used libraries:

containers, bytestring, mtl, text, transformers, time, array, aeson, split, blaze-builder, blaze-html lens, safe, resourcet

I'm sure aeson examples would be very popular. mtl/transformers examples for those who are getting to them in the learning process.

Here is a complete list of the top reverse dependencies for libraries on hackage:

https://docs.google.com/spreadsheets/d/1o7K_tEDIULPHNv8RpP0E...