argo is a small project which consists of two Golang microservices that can communicate with each other.
In order to retrieve the repo, use
git clone http://github.com/floppyzedolfin/argo.git
This repo consists of two microservices, that share some common libraries (log
, for instance), that have some API dependencies (the client needs to know the API of the backend), and some internal dependencies (I split the code into modules for clarity).
The main structure - the definition of a Port - is generated by protoc.
This repo comes with a Makefile
that exposes several build targets, including
make docker-build
This will build the binaries, and wrap them inside docker images.
This repo comes with a Makefile
that exposes several build targets, including
make docker-run
This will run the docker images in a local network. Their IP addresses + ports are hardcoded (in the Makefile, and in the client of the backend):
- front: 172.18.0.22:8411
- portdomain: 172.18.0.23:8405
The docker-run target mounts the testdata
directory into the /tmp
directory of the front
container. You can place your json files in there.
To load a file in the database, run
curl -X POST -H "content-type:application/json" 172.18.0.22:8411/ports -d '{"input":"/tmp/ports.json"}'
To get the contents of the database, run
curl 172.18.0.22:8411/ports
I've decided to use fiber
for the front service. I've used it in a small test project on my spare time (http://github.com/floppyzedolfin/square) which provided some source for copy/paste.
The first version of my code loaded the whole input file, which didn't respect the requirement of memory limitation. But it allowed me to test the rest of the endpoints.
I've written unit tests over some sections of the code, but I'd need to use mockgen
to mock the backend.
This would mean rewriting the whole handlers
package, but I think it would bring some simplicity - it would, however, be a great opportunity to not spawn a client from front
to portdomain
on each endpoint call.
Further steps would be to have integration tests in the CI, and to use a staged build (see http://github.com/floppyzedolfin/square for an example of how I would have done it). And probably, having a real database, rather than something lying in the memory, would be extremely necessary very fast - at least for data consistency. I'd use mongo, because I've already used mongo.