Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
chore(allsrv): add github.com/jsteenb2/allsrvc SDK module
We fixup our http client to make use of the [github.com/jsteenb2/allsrvc](https://github.com/jsteenb2/allsrvc) SDK. As you, we can clean up a good bit of duplication by utilizing the SDK as a source of truth for the API types. We've broken up the SDK from the service/server module. Effectively breaking one of the thorniest problems large organizations with a large go ecosystem face. When we leave the SDK inside the service module, its forces all the depdencies of the service onto any SDK consumer. This creates a series of problems. 1. The SDK creates a ton of bloat in the user's module. 2. The SDK undergoes a lot of version changes when coupled to the service module version. 3. Circular module dependencies are real, and can cause a LOT of pain. * Check out [perseus](https://github.com/CrowdStrike/perseus) to help visualize this! 4. If you do it this way, then other teams will also do it this way, putting tremendous pressure on your CI/build pipelines. Instead of exporting an SDK from your service, opt for a separate module for the SDK. This radically changes the game. You can use the SDK module in the `Service` module to remain *DRY*. However, **DO NOT** import the `Service` module into the SDK module! Now that we have the tiny SDK module, we're able to obtain some important data to help us track who is hitting our API. We now get access to the `Origin` and `User-Agent` of the callee. Here is an example of a log that adds the [version of the module](https://github.com/jsteenb2/allsrvc/blob/main/client.go#L21-L30) as part of `User-Agent` and `Origin` headers when communicating with the server: ```json { "time": "2024-07-06T20:46:58.614226-05:00", "level": "ERROR", "source": { "function": "github.com/jsteenb2/mess/allsrv.(*svcMWLogger).CreateFoo", "file": "github.com/jsteenb2/mess/allsrv/svc_mw_logging.go", "line": 32 }, "msg": "failed to create foo", "input_name": "name1", "input_note": "note1", "took_ms": "0s", "origin": "allsrvc", "user_agent": "allsrvc (github.com/jsteenb2/allsrvc) / v0.4.0", "trace_id": "b9106e52-907b-4bc4-af91-6596e98d3795", "err": "foo name1 exists", "err_fields": { "name": "name1", "existing_foo_id": "3a826632-ec30-4852-b4a6-e4a4497ddda8", "err_kind": "exists", "stack_trace": [ "github.com/jsteenb2/mess/allsrv/svc.go:97[(*Service).CreateFoo]", "github.com/jsteenb2/mess/allsrv/db_inmem.go:20[(*InmemDB).CreateFoo]" ] } } ``` With this information, we're in a good position to make proactive changes to remove our own blockers. Excellent stuff! Additionally, we've imported our SDK into the `Service` module to *DRY* up the HTTP API contract. No need to duplicate these things as the server is dependent on the http client's JSON API types. This is awesome, as we're still able to keep things DRY, without all the downside of the SDK depending on the Service (i.e. dependency bloat). Lastly, we update the CLI to include basic auth. Try exercising the new updates. Use the CLI to issue some CRUD commands against the server. Start the server first with: ```shell go run ./allsrv/cmd/allsrv | jq ``` Then you can install the CLI and make sure to add `$GOBIN` to your `$PATH`: ```shell go install ./allsrv/cmd/allsrvc ``` Now issue a request to create a foo: ```shell allsrvc create --name first --note "some note" ``` Now issue another create a foo with the same name: ```shell allsrvc create --name first --note "some other note" ``` The previous command should fail. Check out the output from the `allsrvc` CLI as well as the logs from the server. Enjoy those beautiful logs! This marks the end of our time with the `allsrv` package! Refs: [SDK module - github.com/jsteenb2/allsrvc](https://github.com/jsteenb2/allsrvc) Refs: [Setting version in SDK via debug.BuildInfo](https://github.com/jsteenb2/allsrvc/blob/main/client.go#L21-L30) Refs: [Perseus module tracker](https://github.com/CrowdStrike/perseus)
- Loading branch information