eed51978ca
As mentioned in https://github.com/ooni/probe/issues/1951, one of the main issues I did see with httpx.APIClient is that in some cases it's used in a very fragile way by probeservices.Client. This happens in psiphon.go and tor.go, where we create a copy of the APIClient and then modify it's Authorization field. If we ever refactor probeservices.Client to take a pointer to httpx.Client, we are now mutating the httpx.Client. Of course, we don't want that to happen. This diff attempts to address such a problem as follows: 1. we create a new APIClientTemplate type that holds the same fields of an APIClient and allows to build an APIClient 2. we modify every user of APIClient to use APIClientTemplate 3. when we need an APIClient, we build it from the corresponding template and, when we need to use a specific Authorization, we use a build factory that sets APIClient.Authorization 4. we hide APIClient by renaming it apiClient and by defining an interface called APIClient that allows to use it So, now the codebase always uses the opaque APIClient interface to issue API calls and always uses the APIClientTemplate to build an opaque APIClient. Boom! We have separated construction from usage and we are not mutating in weird ways the APIClient anymore. |
||
|---|---|---|
| .. | ||
| testorchestra | ||
| benchselect.go | ||
| bouncer_test.go | ||
| bouncer.go | ||
| checkin_test.go | ||
| checkin.go | ||
| checkreportid_test.go | ||
| checkreportid.go | ||
| collector_test.go | ||
| collector.go | ||
| login_test.go | ||
| login.go | ||
| measurementmeta_test.go | ||
| measurementmeta.go | ||
| metadata_test.go | ||
| metadata.go | ||
| probeservices_test.go | ||
| probeservices.go | ||
| psiphon_test.go | ||
| psiphon.go | ||
| README.md | ||
| register_test.go | ||
| register.go | ||
| statefile_test.go | ||
| statefile.go | ||
| tor_test.go | ||
| tor.go | ||
| urls_test.go | ||
| urls.go | ||
Package github.com/ooni/probe-engine/probeservices
This package contains code to contact OONI probe services.
The probe services are HTTPS endpoints distributed across a bunch of data centres implementing a bunch of OONI APIs. When started, OONI will benchmark the available probe services and select the fastest one. Eventually all the possible OONI APIs will run as probe services.