New Server

[josephjclark]

This PR creates a bun-based webserver which will host our AI and data-generation services.

Although I've refactored a lot of the python code (stripping out the HTTP layer), the aim of this project is to wrap a new web server around the existing code and not actually change anything. So the actual python services do need work and this is entrirely expeted!

Isma's original work is all committed under https://github.com/OpenFn/gen/releases/tag/last-isma-commit

Issues

Closes #42 and also #41 #34 #32

Features

• A simple bun.js/Elysia webserver which automatically routes to python services
• A poetry "monorepo" of scripts, easily invokeable
• Long-running python engine with C bindings from node - so should be efficient
• Hot reloading (in Typescript and Python)
• Call python directly with bun py inference tmp/path.json (useful for debug)
• Services to generate an adaptor template
• Load keys from .env (designed for dev mode only)
• Docker image

Index page

If you go to the the server root, you'll be given a simple index page showing the available services. We show the first paragraph of the readme on the index, and link to the full readme.

Example Usage

All services are hosted at /services/<service-name> and accept a POST with JSON:

curl -X POST localhost:3000/services/adaptor_gen --json @tmp/payload.json

With a payload:

{
  "endpoint": "/facts",
  "model": "gpt3_turbo",
  "open_api_spec": "{ .. }"
}

This will call into the adaptor_gen service and return an adaptor file to you:

{
  "Adaptor.js": "..."
}

For very easy testing, use the echo service!

curl -X POST localhost:3000/services/echo --json @tmp/payload.json

With a payload:

{
  "x": 22
}

This will pass your payload into python and return it right back to you.

Tasks

• Hook up a basic bun server with Elysia
• Bridge from JS to Python
• Create a docker image
• Automatically generate routes to python modules in services
• Import python modules on-demand (not on startup)
• Always re-import when running in dev mode (this now works in python AND js for seamless hot loading)
• Setup the poetry venv properly and bind node-calls-python to it
• Poetry monorepo setup (is there anything to do here?)
• Fix python module imports (thanks Elias!)
• Setup a very basic dir-style listing at root
• Port Isma's Inference engine
• Add poetry and python to docker image
• Port Isma's Signature generator
• Port Isma's Code generator
• Add new adaptor generator service
• Think a bit more about error handling - how are errors caught and reported (test with syntax errors, bad imports, python execptions)
• Maybe support a .env file - I guess up in the root?
• Work out whether or how I want to control versions (maybe each service has a version, like services/template-gen/v1/ ? Or maybe the version is in a query param?
• Each service/endpoint will expect json in a certain format. How do we define that, and how do we version it? Does each service need to provide a json schema? Or d.ts? Should we have standard wrappers on the response and request, or can we be super loose? JSON in, JSON out. That's it my friend.
• Basic documentation in readme and key parts of source
• Ensure docs / process / examples for runing python directly? How do we pass data in? What about a built-in CLI that runs a python script but feeds a json object into it? Maybe that's unneccessary
• How-to guide for contributors
• Ensure good unit test conventions and tooling are setup (I don't think unit testing will be a big deal in this repo)

Future Work

• Create a metadata service
• Create an adaptor docs service
• Track usage by demanding some kind of API key or unique id from the client

Issues

Closes #42 (others to follow)

[josephjclark]

So I've said "JSON in JSON out" for the endpoints.

But inside the services I'm also saying "what is the point in wrapping everything up in a { sngature: } or { code: } object?

It's actually annoying internally to have to wrap everything.

I wonder if there's a common format like:

{
   error: { }  // error object of some kind
   result: {}  // the result of whatever process you ran
   files: {} // the result expressed as a number of files, which the CLI will duly create
}

That means that each service has a common JSON response format, but has a lot of flexibility within it to do their own thing.

[josephjclark]

Cannot begin to tell you how much trouble I've had getting the right versions of bun and python into the docker image 😬

In the end I've gone with python:3.11-bullseye. If anyone feels the need to optimise this later, they can be my guest...

[josephjclark]

Outstanding right now is:

python unit tests - but I don't really have anything to test 🤔 Maybe this can be introduced as needed?

versioning - I think I'll spin this out as an issue, I'm not really sure on the requirements yet. I think service versions are probably tied to server Versions?

[josephjclark]

So it looks like the docker image doesn't seem to log python output either!