suborbital / vektor Goto Github PK

vlog currently outputs to terminal, it should support logging to a file

Having the autocert cability with autocert with vk.UseDomain() is pretty awesome. However, in some situations, another TLS configuration would be required.

Use case

Requirements I have in this regards, are:

• Configuring minimum TLS version
• Configure allowed ciphersuites
• Setting up TLS listening with a provided cert and key (either paths to files or tls.Certificate)

Proposed solution

These could all be tackled by having the following configuration option:

vk.UseCustomTLS(config *tls.Config)

Most of our services are using vektor for routing.

Opentelemetry's http instrumentation works my wrapping the mux of whatever we want to instrument (in our case, vektor) into otel's mux.

Vektor does not expose the mux for other services to wrap, which means we have to configure vektor in such a way that it becomes wrapped, optionally, and configured as per whichever other project is using it.

Sibling issue of https://github.com/suborbital/scn/issues/221

There should be some E2E tests that make requests against a gapi server to ensure middleware, responses, errors etc all work as promised.

What it says on the tin

Whether or not a request can be handled with a trailing slash is up to the user, but Vektor should handle both.

For example, it's common to do something like:

build := vk.Group("/build")
build.GET("/", ...)

In this case, requests must be made to /build/ rather than /build. Vektor should accept both.

https://docs.rs/redis/0.15.1/redis/struct.PubSub.html

This is an ongoing issue to identify any minor issues with vektor's existing documentation.

Needs clarification:

• Getting started locally without TLS auto-config
• Add code samples for vk.Ctx section

Updates:

• Old references to Hive should be changed to Reactr
• Why Vektor instead of xyz? Who is it for?

using https://github.com/sethvargo/go-envconfig!!!

Currently, you need to create an empty vk.Group to have something to attach global {after, middle}ware to.

g := vk.Group("").After(...)
g.GET("/", indexHandler)

server.AddGroup(g)

It would be nice to be able to do this instead:

server.GET("/", indexHandler)
server.After(...)

For example, the ability to discover /api/vi/users/:uuid instead of /api/v1/users/aksjhdiunvriqbjru0jarfo20r in handler functions etc.

Currently middlewares and afterwares are handled in the vk/middleware.go file augmentHandler method. The way this works is that it calls the middlewares first, one by one, and finishes with them, then calls the actual core handler function, and then calls a bunch of other afterwares, one by one.

An architecture diagram would look like this:

Request -> (mw1) -> (mw2) -> (core handler) -> (aw1) -> (aw2) -> Response

Instead middlewares should be wrapping the other handlers. That way we can construct a layered structure that simplifies code and is easier to reason about, plus it would remove distinction between a middleware (used here to mean running code that should happen before the core handler does anything with it), and afterware (used here to mean running code that should happen after the core handler is done with the request).

The target structure should look like this:

Request ->                                                                                      -> Response
           ( mw1 ->                                                    -> mw1, but after code )
                    ( mw2 ->                  -> mw2, but after code )
                             ( core handler )

With the transition to SE2, we'll no longer maintain Vektor docs on the main docs site, and will instead move them to this repo.

It would be great to have a configuration option to have a logger always print the request ID as part of logging. The current interface for adding the request id to the logging scope happens after the first log for the request has been printed.

It would also be good to have an option either for vk.UseLogger(...) or in vk.Group(...) to indicate that all requests should have ctx.UseScope() called without having to write a vk.Middleware to do that.

determine how the gfn watchdog is going to launch/manage containers for gfn

What it says on the tin

I really the simplicity of the current built-in request logging functionality, but I would like to be able to configure the server logger to only log requests on some of the paths.

Suggestion for Implementation

One way to achieve this would be to allow disabling of the default request logging so that custom logging can be implemented via middleware and afterware.

It would be useful to have a clean way of serving local files in Vektor.

httprouter has a helper that we could probably just forward through to Vektor.

Or possibly just integrate the usual Go http.FileServer(http.Dir("./static")) handler.

There should be a framework to run automated tests on user-defined Vektor routes.

Tests should be able to run without a server by passing request and context objects directly to the router functions.

• vtest top level package
• should be able to test without binding to a port and actually running the HTTP server
• pass "fake" requests to the server object
• do we use ServeHTTP or go deeper into the routing structs?
• idiomatic Go testing style

We should trap sigkill, sigterm etc and do graceful shutdown, perhaps provide a callback that can be executed.

There should be unit tests for things like middleware, groups, response/error converters.

Afterware functions should be able to see the status code of the request.

The GitBook guide needs documentation for vk/vtest.

The type returned by the HandlerFunc should be detected to set the Content-Type header (if it wasn't set explicitly already)

It's helpful to have the option to defer port umber selection to the OS when writing tests to avoid bind conflicts. It would be great if this were an option in Vektor.

summary of changes:

1. Differentiate between HTTP Port not set and HTTP Port set to 0
2. Expose function to get allocated port

A place for us to add thoughts on which methods we might want to implement into response.go!

It would be neat if Vektor could generate a list of registered routes that could be compared against an existing OpenAPI spec to ensure that all of the routes are covered and match. Later it might also be possible to extract type metadata (perhaps via reflection?) into Vektor for autogenerating entire OpenAPI specs.

While Vektor is not directly comparable to every other Go web framework due to its different feature set, it would still be useful to add benchmarks.

See: https://github.com/smallnest/go-web-framework-benchmark

Sibling issue: https://github.com/suborbital/scn/issues/547

When instrumenting my API for with OpenTracing support and some request auditing I discovered that registered vk.Afterware will not be executed if any Middleware or the Request Handler itself return an error.

As a result it is not possible to close tracing spans or ensure that audit events on rejected requests are tracked.

It would be great if vk.Afterware always were executed, or if there was a try/catch/finallyWare for cases like tracing and auditing that should always be executed regardless of response code, but depend on being executed at the end

Ability to spawn a "scoped logger" that is designed to log for one request or one session etc.

When I'm using AssertBodyString, I can get this error: body length mismatch: got 19 runes, want 18 runes

In this case I would like to know what the expected and actual values were so that I don't need to go adding extra prints to see what went wrong (and this likely applies to other Assert* things as well.

New *_test.go file(s) should be added to the existing vk/test directory for automated testing.

Blocked by #54

vk currently uses a fileCache for LE cert caching, Redicrypt support should be added

There should be an /examples directory with a handful of directly runnable Vektor examples ranging from Hello World to something similar to the existing test code. These examples could also serve as test cases.

This issue provides visibility into Renovate updates and their statuses. Learn more

Rate Limited

These updates are currently rate limited. Click on a checkbox below to force their creation now.

• Update module github.com/sethvargo/go-envconfig to v0.6.0
• Update actions/cache action to v3

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update golang.org/x/crypto digest to 7b82a4e
• Update module github.com/stretchr/testify to v1.7.1

• Check this box to trigger a request for Renovate to run again on this repository

See suborbital/e2core#90

Mainly talking about this: https://github.com/suborbital/vektor/blob/main/vk/server.go#L42-L46

Given the following env var values:

NAME="hello"
FOO_VERSION="34"
FOO_TYPE="underscored"

The following does NOT work:

type Wrapper struct {
	Name        string      `env:"NAME"`
	Subordinate Subordinate `env:",prefix=FOO"`
}

type Subordinate struct {
	Version int    `env:"_VERSION"`
	Type    string `env:"_TYPE"`
}

But this one WILL work:

type Wrapper struct {
	Name        string      `env:"NAME"`
	Subordinate Subordinate `env:",prefix=FOO_"`
}

type Subordinate struct {
	Version int    `env:"VERSION"`
	Type    string `env:"TYPE"`
}

The reason is that the individual field names all need to adhere to the env var field name format (only letters (whatever case), numbers, underscore, starts with letter)*, but if we put the underscore in the suborbdinate's field's names at the beginning, that fails.

The prefix has no such limitation, so the easy fix is to move the leading underscore from the subordinate struct to be a trailing underscore of the prefix.

*the spec technically says it should be only uppercase letters, however the application can tolerate other chars and must distinguish between uppercase and lowercase letters:

Environment variable names used by the utilities in the Shell and Utilities volume of IEEE Std 1003.1-2001 consist solely of uppercase letters, digits, and the '_' (underscore) from the characters defined in Portable Character Set and do not begin with a digit. Other characters may be permitted by an implementation; applications shall tolerate the presence of such names. Uppercase and lowercase letters shall retain their unique identities and shall not be folded together. The name space of environment variable names containing lowercase letters is reserved for applications. Applications can define any environment variables with names from this name space without modifying the behavior of the standard utilities.

vlog currently supports text-based logging, it should also support JSON/structured logging.