Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Architectural Proposals #2

Open
frenata opened this issue Mar 8, 2018 · 0 comments
Open

Architectural Proposals #2

frenata opened this issue Mar 8, 2018 · 0 comments

Comments

@frenata
Copy link
Owner

frenata commented Mar 8, 2018

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.

alt text

From frenata/compilebox-old#3 via @ConnorWalsh

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant