v5 Roadmap

[jochumdev]

Hey,

We/I have been working on the V5 Roadmap lately @asim may wanna have a look?

Can someone please Publish it, if it's ok?

Thanks,

René

[asim]

It probably makes sense to first define the high level goals for v5 here before introducing a roadmap. I don't personally know what that is from the board. Every version should come with a stated plan and ultimately goal for why a new version is being defined and what it changes or improves.

[jochumdev]

René's v5 plan

Reasons for v5

• Lots of Backward incompatible changes

Goals

• Allow backward incompatible Lint fixes
• Remove Globals
• Make go-micro/go-micro an interface library only, if possible move code into go-miro.dev/plugins/v5/
• Intodruce wire
• more to come.

[Davincible]

@mivinci The current example code is not yet representative of the final architecture, we're still in the POC phase. But once we have a good working POC we'd love to hear if you still think the same :)

[jochumdev]

@mivinci Thanks for participating on this discussion!

We are working on simplyfing microwire a lot. Have you seen the examples in go-micro/microwire-examples they are still easy to use, aren't they?

[mivinci]

@jochumdev @Davincible Yea they are. I just feel we can do the same thing using the current but simpler implementation. A config store doesn't look like reduced much work than optional functions which look more intuitive and concise in Go. Anyways it is too early to say that. You're doing a great job. Looking forward to what's coming 😊

[jochumdev]

@mivinci thanks to a suggestion of @Davincible yesterday ConfigStore is gone now with the latest commit. Together we came up with a new Design and made it a lot simpler.

package main

import (
	"go-micro.dev/v4/logger"

	"github.com/go-micro/microwire"
	_ "github.com/go-micro/microwire/plugins/cli/urfave"
	_ "github.com/go-micro/plugins/v4/broker/nats"
	_ "github.com/go-micro/plugins/v4/registry/nats"
	_ "github.com/go-micro/plugins/v4/transport/nats"
)

func main() {
	service, err := microwire.NewService(
		microwire.Name("nastconfigfile"),
		microwire.Usage("A POC for go-micro.dev/v5"),
		microwire.Version("v0.0.1"),
		microwire.NoFlags(),
		microwire.Config("config"),
	)
	if err != nil {
		logger.Fatal(err)
	}

	if err := service.Run(); err != nil {
		logger.Fatal(err)
	}
}

This gives you a configureable Service with a config file and NO flags. :)

You can replace later microwire with micro.

[jochumdev]

I've updated microwire and added nocli to microwire-examples.

nocli is on of the main reasons for doing this, with wire generated code it's possible to compile out ANY component when we are done.

[asim]

One thing I'd be inclined to think is now that Go has generics, the entire options model could be rewritten to use it and potentially provide dynamic CLI initialisation without the need to code generation.

[jochumdev]

I can't see a way to do the same with generics as with wire. With wire the compiler is able to optimize out any unused code, how would it do that with generics?

[asim]

It's not about removing unneeded packages, I think if the implementations in go-micro are only based on the standard library then it poses no issue as the Go compiler is smart enough to know what to exclude. What it does is enable a much simpler way to accept options to any package, that does not depend on defining concrete code for each implementation.

e.g https://golang.design/research/generic-option/

or a simpler example https://amirsoleimani.medium.com/functional-options-in-go-with-generic-863dbd68cc6f

[mivinci]

I have once tried optional functions with generics in my projects but found out that it is no different than simply using a builder map for each plugin respectively, and it made my code ugly, what do you guys think?

// Plugin is a generic Go Micro plugin.
type Plugin[O any] interface {
	// Init initializes the provider using some options.
	Init(...Option[O])
	// String returns the implementation name.
	String() string
}

// Option is functional wrapper for an option.
type Option[O any] func(*O)

// Builder is a plugin builder.
type Buidler[P, O any] func(...Option[O]) P

var (
	pool     sync.Map
	builders = map[string]any{}
)

// Register registers a plugin builder.
func Register[P Plugin[O], O any](name string, builder Buidler[P, O]) {
	builders[name] = builder
}

// Get gets a plugin and initializes it using the given functional options. If the plugin 
// does not exist, its builder, if registered, will be used with the options to instantiate
// the plugin. If the builder is not registered, an error will be returned.
func Get[P Plugin[O], O any](name string, opts ...Option[O]) (P, error) {
	if v, ok := pool.Load(name); ok {
		p := v.(P)
		if opts != nil {
			p.Init(opts...)
		}
		return p, nil
	}

	b, ok := builders[name]
	if !ok {
		var null P
		return null, fmt.Errorf("no builder for %s", name)
	}

	p := b.(Buidler[P, O])(opts...)
	pool.Store(name, p)
	return p, nil
}

[jochumdev]

I have once tried optional functions with generics in my projects but found out that it is no different than simply using a builder map for each plugin respectively, and it made my code ugly, what do you guys think?

I'm using this as a container for Plugins Factories. Every component has this variable which holds plugins. And here we fetch a plugin from container.

[jochumdev]

@asim so you'r against using wire as you think generics can solve the same problems and we can reach the same goals as we are doing it now with wire?

[Davincible]

We should also look to improve how options are implemented and how packages are initialized. It can provide a simpler default starting point for a lot of people

Yes that will definitely be simplified in v5

[jochumdev]

Basically I think options should potentially be its own package and everything makes use of that. It would solve a lot of issues.

@asim can you give an example please? Cause I don't see yet how generic Options would allow us to have more specific Options without blowing up?

[asim]

Generics aside. Every package defined its own options struct and option type with functions to do the setup. The majority of that looks like.

type Options struct {
  Address string
  // Other values
}

type Option func(*Options)

func WithAddress(a string) Option {
  return func(o *Options) {
    o.Address = a
  }
}

Each package then has a NewX initialiser for setup that only accepts the options defined within that package. I think the majority of this can be largely squashed into a single options package that has a simpler getter/setter approach so that we can actually operator on a single option constructor.

Even the pattern func WithAddress(a) Option now feels pretty inefficient. While explicit, it's also just a bit verbose to do this for every option. If each package needs options then it better define them as a single Options struct that can be set an operated on by the options package.

E.g getter/setter in an options package sets "address" and an option parser fills in a struct field Address to match. Tbh with the config package i tend to repeat that purely through JSON marshaling/unmarshaling so I don't know whether you just collapse options/config into one thing.

[jochumdev]

di.go and config.go is everything needed for Flags and Config parsing now, both files are generated over .component_generator

Thanks to a suggestion of @Davincible we scan the config in each "component", this allows us to decouple them.

I'm not sure this is what you want @asim ?

[Davincible]

Yeah I'm sure we'll figure something nice out. Basics first, sugar later