Added multiplexing of gRPC and Gin servers on same port via new dependency soheilhy/cmux
Added gRPC server implementation in grpc.go
Added database log batch injection SQL for sqlite & postgres.
Moved all HTTP server stuff to http.go
Motivation
The SQL code is what mostly stands out in this PR IMO. What I wanted to do was:
In a single SQL query do batch insertion of multiple log lines.
Skip insertion of logs that targets non-existing builds to not cause foreign key violation.
Get a list back of the logs that were not skipped, so we can publish them via server-sent events (SSE) to any web clients.
In Sqlite this was simple, as you basically do INSERT OR IGNORE INTO instead of just INSERT INTO, while Postgres does not have such a feature, but I found a solution that instead made use of a JOIN statement inside the INSERT.
Please look at the test files for the best overview of what the SQL actually looks like.
The Sqlite function isn't really working as we do not have foreign key constraints enabled. However, this is planned in #145.
Protobuf versioning
I've added the major version to both the path in api/wharfapi/v5/builds.proto as well as the Protobuf package name wharf.api.v5.
My reasoning here is that it should be the same as the wharf-api version, for simplicity sake. But to be able to keep backwards compatiblity, when jumping to v6 the wharf-api needs to keep supporting v5. In other words, when bumping to v6, we will have the files:
api/wharfapi/v5/*.proto
api/wharfapi/v6/*.proto
For v7, we will have the files:
api/wharfapi/v6/*.proto
api/wharfapi/v7/*.proto
Up for discussion: Should the gRPC protobuf API have a separate versioning? It could, but I think that'd be adding excess confusion.
It does however make it so if we have a breaking change in the HTTP REST API then we also have to bump the gRPC API. Perhaps that's a good thing, but I'm not sure. Input on this is well appreciated.
CHANGELOG.mdfile, according to docs: https://iver-wharf.github.io/#/development/changelogs/writing-changelogsSummary
api/wharfapi/v1/builds.protoMakefilesoheilhy/cmuxgrpc.gohttp.goMotivation
The SQL code is what mostly stands out in this PR IMO. What I wanted to do was:
In Sqlite this was simple, as you basically do
INSERT OR IGNORE INTOinstead of justINSERT INTO, while Postgres does not have such a feature, but I found a solution that instead made use of aJOINstatement inside theINSERT.Please look at the test files for the best overview of what the SQL actually looks like.
The Sqlite function isn't really working as we do not have foreign key constraints enabled. However, this is planned in #145.
Protobuf versioning
I've added the major version to both the path in
api/wharfapi/v5/builds.protoas well as the Protobuf package namewharf.api.v5.My reasoning here is that it should be the same as the wharf-api version, for simplicity sake. But to be able to keep backwards compatiblity, when jumping to v6 the wharf-api needs to keep supporting v5. In other words, when bumping to v6, we will have the files:
api/wharfapi/v5/*.protoapi/wharfapi/v6/*.protoFor v7, we will have the files:
api/wharfapi/v6/*.protoapi/wharfapi/v7/*.protoUp for discussion: Should the gRPC protobuf API have a separate versioning? It could, but I think that'd be adding excess confusion.
It does however make it so if we have a breaking change in the HTTP REST API then we also have to bump the gRPC API. Perhaps that's a good thing, but I'm not sure. Input on this is well appreciated.
Closes #130