See #3. I'm hopeful this will actually be a relatively minimal change, mostly involving reviewing what is and isn't exported.

From #3:

dockerize compilebox API server: right now, the compilebox API server doesn't run in docker, but it should be really easy to get that up and running. In my opinion this would dramatically increase the ease of use since,

1. it would simplify the setup (just docker build and run the container; no build dependencies like gb etc.)
2. it would simplify integration with other backend services using docker-compose
   But, you may ask-- "wait, doesn't compilebox spin up a docker container tho? Wouldn't that mean....a docker container....in a.... docker container????". While docker in docker is a thing (not recommended), luckily we can allow docker containers to spin up sibling containers by making compilebox use the docker daemon of the host. See this blog post for more details. I've actually already started working on this in a fork so I'll probably be submitting a PR at some point.

Overview

These are some architectural re-design ideas which I believe would increase ease of use out of the box. Some of these might be too high effort to be reasonable, but I figured I'd write them down anyway.
P.S. love what y'all have done so far!!!! ✌️ ✌️ ✌️ ✌️

Proposals

• compilebox API as importable library as well as standalone server: right now, compilebox can only be started as a standalone API server which interacts with other services through http. While this architecture is great because it can work with services in any language, it also introduces latency and introduces complexity for deployment/maintenance etc. It would be great if services written in Go could just import compilebox as a package natively instead of having to spin up an entire new service. This would,
  1. decrease latency introduced by using http
  2. simplify the overall application architecture by reducing the number of moving parts.
  Since the benefits are only Go-specific, I'd label this as a nice to have.
• dockerize compilebox API server: right now, the compilebox API server doesn't run in docker, but it should be really easy to get that up and running. In my opinion this would dramatically increase the ease of use since,
  1. it would simplify the setup (just docker build and run the container; no build dependencies like gb etc.)
  2. it would simplify integration with other backend services using docker-compose
  But, you may ask-- "wait, doesn't compilebox spin up a docker container tho? Wouldn't that mean....a docker container....in a.... docker container????". While docker in docker is a thing (not recommended), luckily we can allow docker containers to spin up sibling containers by making compilebox use the docker daemon of the host. See this blog post for more details. I've actually already started working on this in a fork so I'll probably be submitting a PR at some point.
• use vanilla go tools rather than gb: gb looks like it isn't actively maintained and the build statuses are all failing on the github. It also doesn't seem to be overwhelmingly popular of an alternative golang build toolchain. I feel like using the standard go tools would be much simpler.

This involves changing project structure to the standard pattern, rather than depending on gb.

See #3 .

As it stands, the code is a pretty ugly hack translated near directly from the old node implementation:

	dockerCommand := s.options.path + "/DockerTimeout.sh"
	args := []string{fmt.Sprintf("%s", s.options.timeout), "-u", "mysql", "-i", "-t", "--volume=" + s.options.folder + ":/usercode", s.options.vm_name, "/usercode/script.sh", compiler, filename, optionalExecutable, flags}

(and later)

func spawnDocker(dockerCommand string, args []string, done chan error) {
	cmd := exec.Command(dockerCommand, args...)
	bytes, err := cmd.CombinedOutput()
	_ = bytes
	//log.Printf("Docker stdout: %v", string(bytes))
	done <- err
}

It seems strange to fall back to the OS and a bash script to communicate to another process written in the same language, which seems to provide a healthy API.

On the other hand, interacting directly with the docker API might constrain the environments in which compilebox can run, requiring some amount of coupling between the host's version of docker and the API target of compilebox.

https://docs.docker.com/develop/sdk/examples/ may be useful reading as well.

What just looking at the flags package and thinking we could really use better debugging options for compilebox and that cli flags a probably the easiest way to implement. Sometimes I need to see the code submitted, sometimes the output, sometimes something else.

CLI flags seem like the standard way to do it but would be trivial to just dispatch a goroutine to listen for keyboard input to change what debug output we're handling. This seems like less standard approach, but I like not having to restart compilebox just to look at different vars...

I guess this is a bigger question of how we would want to structure admin/monitor tools for the service.