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!!!! :v: :v: :v: :v:
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 http2.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.
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!!!! :v: :v: :v: :v:
Proposals
gbetc.) 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.go toolsrather thangb: 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.From https://github.com/frenata/compilebox-old/issues/3 via @connorwalsh