Original post

Yeah. We’re currently rewriting the entire CLI project to a v2, using pure Go and interface-based plugins to really drive us. We’re about 70% done, including some major pieces like generate some command, generate resource, and build, and test… And so far it’s holding up beautifully. We’ve got some very small interfaces, not a ton of them. They’re all standard libraries, there’s no Buffalo types. Everything is a plugin; even the subcommands are plugins… And it’s all managed with just a slice of plugins. It’s ridiculously simple in its concepts, but really powerful. You could build really amazing things with just a few interfaces if you line them up correctly, and think about what it is you’re doing. And you set yourself a space to work in.

[00:36:12.23] For me, it’s been understanding that everything is a plugin. If you take something like Buffalo generate, that generate command is just another plugin, and it implements the one interface you need to be a subcommand of Buffalo, which is a main function that takes a context, root, string for where you are, and the slice of arguments returns an error. That’s it. Now it’s a subcommand of Buffalo.

That generate plugin issues three or four interfaces maybe, that say “Hey, if you implement these, you’re gonna get these different lifestyle hooks when you run Buffalo generate”, one of them being, say, a subcommand of Buffalo generate, like resource. And that’s it.

So you can write your own implementation to generate. If you speak those couple interfaces, you can write your own drop-in replacement for it, or any of the other things. So it’s not about a lot of interfaces, it’s about targeted interfaces, it’s about defining the scope of where your interfaces are.