The Most Efficient Struct Configuration Pattern For Golang

แชร์
ฝัง
  • เผยแพร่เมื่อ 22 ธ.ค. 2024

ความคิดเห็น • 176

  • @anthonygg_
    @anthonygg_  ปีที่แล้ว +4

    ► Join my Discord community for free education 👉 discord.com/invite/bDy8t4b3Rz
    ► Pre order (get 30% off) my Golang course 👉 fulltimegodev.com
    Thanks for watching

  • @kafran
    @kafran ปีที่แล้ว +189

    This pattern is commonly known as the "Functional Options" pattern. The Functional Options pattern is a design pattern in Go where you pass in functions that alter the state of a type. These functions are often called "option functions". They provide a way to cleanly design APIs and offer a more flexible and readable way to interact with a function or type. Nice demonstration on how to implement them. Thanks.

  • @abiiranathan
    @abiiranathan ปีที่แล้ว +160

    Functional Options Pattern... popularized by Dave Cheney

    • @wuilliam321
      @wuilliam321 ปีที่แล้ว +1

      Any book/reference? Thanks

    • @jamesprendergast7158
      @jamesprendergast7158 ปีที่แล้ว +4

      Surprised gg didn't know the name TBH

    • @Cruzylife
      @Cruzylife ปีที่แล้ว +2

      @@jamesprendergast7158 because Ant creates his own meta

    • @TehKarmalizer
      @TehKarmalizer ปีที่แล้ว +5

      Looks like functional riff on the builder pattern.

  • @necroowl3953
    @necroowl3953 ปีที่แล้ว +34

    1. Make the config elements private
    2. Make the options type a public interface, with a single private method (apply(config) config)
    3. Expose public functions returning this interface
    4. Add a function type that complies with the option interface, make that type implement the apply method by calling itself.
    5. Add a no-op type for validation when needed.
    6. Validate input before returning a config type.
    Boom, functional options with a restrictive builder pattern, for your constructors. You can make it generic too.

    • @macot79
      @macot79 10 หลายเดือนก่อน +2

      Hey! Those suggestions are really great, I'm new at Golang and have tried to adapt Anthonygg's example with your suggestions, but I'm a bit stuck at step 5. Could you clarify what you mean? Thanks

    • @hugorojasmonzon1487
      @hugorojasmonzon1487 8 หลายเดือนก่อน +2

      Could you create a github example of these ideas ?

  • @jeezusjr
    @jeezusjr ปีที่แล้ว +7

    Perfect timing! I am doing something right now that can use this pattern. Thanks!

  • @vitiok78
    @vitiok78 ปีที่แล้ว +13

    Reinventing the wheel of named function parameters with default values))

    • @susiebaka3388
      @susiebaka3388 9 หลายเดือนก่อน

      you're free to use a map or whatever my guy

  • @banatibor83
    @banatibor83 8 หลายเดือนก่อน +19

    It looks fancy but a bit of a hassle. A simple builder pattern is much more readable I think. The default values are nice. Then just put methods onto the ServerOpts type which return *ServerOpts.
    type ServerOpts struct {...},
    func NewServerOpts() *ServerOpts {...set defaults...} ,
    func (s *ServerOpts) Id(id string) *ServerOpts {... set id ..},
    func (s *ServerOpts) MaxConn(maxconn int) *ServerOpts {...set maxcon..}
    Then you can use it like this:
    s := NewServer(NewServerOpts().Id("my-server").MaxConn(100))

    • @Ascentyon
      @Ascentyon 6 หลายเดือนก่อน +1

      Exactly. This is much better for discoverability, instead of having a bunch of standalone functions.

    • @matthewwagner5396
      @matthewwagner5396 12 วันที่ผ่านมา +1

      Feels like you don’t even need the opts struct here. Just use the server struct itself

  • @jex8885
    @jex8885 ปีที่แล้ว +3

    This channel is amazing, you're making my Go code better and better for every video!

  • @yogeshdharya3857
    @yogeshdharya3857 ปีที่แล้ว +1

    3:50 to 3:53 Witch Craft and Woo Doo ! . My man's a part-time wizard

  • @arieheinrich3457
    @arieheinrich3457 ปีที่แล้ว +11

    Thanks for diving into design patterns Anthony ! This is what separate starting devs to more advanced ones, that we all aspire to be, and that is understanding design patterns. Looks more like the Builder pattern than the Visitor one.

    • @anthonygg_
      @anthonygg_  ปีที่แล้ว +5

      Apperantly is the “functional options” pattern 🤷‍♀️

    • @arieheinrich3457
      @arieheinrich3457 ปีที่แล้ว

      @@anthonygg_ yes Functional Options Builder pattern !

    • @dejanranisavljevic
      @dejanranisavljevic ปีที่แล้ว

      I also know this as a builder pattern, it's very common and good use for building test fixtures

  • @quantenlicht
    @quantenlicht ปีที่แล้ว +3

    Start: 1:03

  • @lokthar6314
    @lokthar6314 ปีที่แล้ว +6

    Quality Content

  • @JT-mr3db
    @JT-mr3db 8 หลายเดือนก่อน +1

    Does feel like a take on the builder pattern.
    Incredibly handy pattern a lot of Elm libs use as well.

  • @Programscape
    @Programscape ปีที่แล้ว +1

    Watch this video for some time ago, remember. And return now to implement this in my project))
    Antony is gigachad, thx for the video

  • @lotfikamel5947
    @lotfikamel5947 ปีที่แล้ว +3

    As always very advanced content

  • @bigtymer4862
    @bigtymer4862 ปีที่แล้ว +3

    Love these pattern videos man!!

  • @kylestubblefield3404
    @kylestubblefield3404 ปีที่แล้ว +1

    This is a great video. I stumbled onto using this pattern by accident, it was very useful for a previous project I was working on

  • @skyline7349
    @skyline7349 11 หลายเดือนก่อน +1

    Thank you for posting this Anthony, very nice pattern and will be trying to incorporate it with my starter projects

  • @howesteve
    @howesteve 6 หลายเดือนก่อน +8

    Congrats, you just converted your one liner function into a 50 lines api, introducing lot of nested function calls and even loop overhead, by using the old builder pattern.

    • @anthonygg_
      @anthonygg_  6 หลายเดือนก่อน +1

      Well, you are not wrong.

  • @whatwhat2573
    @whatwhat2573 ปีที่แล้ว +1

    Nice clean pattern to understand too

  • @bjugdbjk
    @bjugdbjk ปีที่แล้ว +1

    Just love this man !! More like this brother, these r the stuff which really play with the Dopamine !!

  • @adriancmiranda
    @adriancmiranda หลายเดือนก่อน

    It's a very good pattern, thx for sharing. Your didatic is very good!

  • @rajdama205
    @rajdama205 ปีที่แล้ว

    The way you make any concept understand is just amazing !!

  • @matthewbridges3147
    @matthewbridges3147 8 หลายเดือนก่อน

    Thanks for the explainer, I'd have been searching docs for a standard way to do this without realising it requires a pattern. In JS I'd just use a default arg param and a spread operator to override

  • @kajfehlhaber
    @kajfehlhaber ปีที่แล้ว +2

    Awesome video as always! ❤

  • @grim.reaper
    @grim.reaper ปีที่แล้ว +2

    This is amazing and used in a lot of places tbh. This is very true that it's used in gRPC, also ssh package if I am not wrong because ssh connection has a lot of options. While putting this in a library the "withXYZ" functions can also be a method where it can have the server receiver methods.
    This is so so so amazing!!!

  • @CaffeineForCode
    @CaffeineForCode ปีที่แล้ว +5

    The only problem with this pattern is that you lose info from the LSP. Working with the AWS SDK, I often have no idea what is possible or what the opt functions do without reading the documentation. It’s a trade off, especially when you have a lot of config options

    • @tigranrostomyan9231
      @tigranrostomyan9231 ปีที่แล้ว

      I think it is possible to solve by putting all 'OptFunc's into another (child) package, e.g. "server/opts". Maybe it's a bit of overkill but if you then type 'opts.' and call autocompletion it will list all 'OptFunc's

    • @jub0bs
      @jub0bs ปีที่แล้ว

      You write: "I often have no idea what is possible or what the opt functions do without reading the documentation." But is a classic config struct any better, in this respect?

    • @jurijskobecs2803
      @jurijskobecs2803 11 หลายเดือนก่อน

      @@jub0bs of course its better, you got one place/struct to check all the possible options

    • @jub0bs
      @jub0bs 11 หลายเดือนก่อน

      @@jurijskobecs2803 The fields of a struct type tell you close to nothing about how they're going to be used by the rest of the program. Their names give you clues at best, and their documentation is meant to give you accurate information. But you'll need to dig into the implementation to definitely find out. In this respect, a struct isn't superior or inferior to functional options.

  • @reikooters
    @reikooters ปีที่แล้ว +6

    Isn't this kind of a limitation on the language? If you could specify default values when you declare structs, then this would go from 50 lines down to 10? You mentioned doing this function approach if you were building a library. How would you do this in a way that's easy for consumers of the library to use and know which functions are available to be used for configuration? Would you put them together into a "configuration" package? (I'm not a Go user, just interested)

    • @sunofabeach9424
      @sunofabeach9424 ปีที่แล้ว +2

      this language is limited is so many ways that eventually you give up on it and probably on life as well. GO, while being a higher level than C, looks and feels as clunky as C. but what in C is honestly called a hack, in GO called a pattern. C was designed to be as easy to parse and compile as possible and that's why it lacks so much. GO has no such excuse

    • @klamberext
      @klamberext ปีที่แล้ว

      The example here is for overriding defaults.
      Imagine instead a environment specific factory configuration or just a variety of options:
      Lets say your server/thingy supports different storage services - S3, ftp, local.
      Now you want to say: withStorageDriverFromEnv, or withFtpStorage or withS3 storage.
      All of them require different kinds of paths, credentials etc..
      Now do that with default values on struct.
      The limit is in the example given.

    • @klamberext
      @klamberext ปีที่แล้ว

      For consumers you provide docs. Or you instead implement the OptFunc as an interface . Then it would be possible to view the list of implementations for given interface(if you have good IDE) .

  • @burionyt
    @burionyt ปีที่แล้ว +3

    only real world shit in the channel 💪🏼 love your content as always ❤

  • @vitaliik8315
    @vitaliik8315 10 หลายเดือนก่อน

    Thanks for yours lessons. One of the best video lessons for go.

  • @MesheeKnight
    @MesheeKnight ปีที่แล้ว +3

    We use to call this the Option pattern. Would you have a nice one for Mandatory config where you cannot provide a reasonable default, like a sql.Conn?

    • @anthonygg_
      @anthonygg_  ปีที่แล้ว

      Thats an amazing question! You could force an interface as option and implement a noop for that interface as default to prevent nil pointers. What do you think?

    • @MesheeKnight
      @MesheeKnight ปีที่แล้ว

      @@anthonygg_ i see the Idea, but i am looking for a way for large amount of mandatories, noop wont do the trick i think

    • @sfsdeniso5941
      @sfsdeniso5941 ปีที่แล้ว +2

      It is called 'Functional options pattern' should look like this:
      func NewServer(addr string, opts ...Option) error () {.....}
      so here addr is mandatory.
      Usage example:
      server, err := NewServer("localhost",
      withPort(8080),
      withTimeout(time.Second))

  • @miguelborges7913
    @miguelborges7913 ปีที่แล้ว +2

    This is great!

  • @grise123
    @grise123 ปีที่แล้ว +3

    nice pattern, seems very helful

  • @kanfit
    @kanfit ปีที่แล้ว

    Thanks, I think you also talked about a bit of functional programming in Golang in this video, which is very nice.

  • @FareAlert
    @FareAlert ปีที่แล้ว

    Opts
    (Opts, opts), opts
    Opts
    Opts opts😅
    Thank you Op for the video ; I appreciate your talent and time

  • @hugorojasmonzon1487
    @hugorojasmonzon1487 8 หลายเดือนก่อน

    Amazing video, thanks for sharing your knowledge!

  • @codewithluke
    @codewithluke ปีที่แล้ว +2

    Nice one. Really enjoy this pattern.

  • @sibonelongobese8639
    @sibonelongobese8639 ปีที่แล้ว +1

    Top notch stuff 👌🏽

  • @Crazyfulization
    @Crazyfulization ปีที่แล้ว

    Really helpful, you can see the benefit right away! Awesome stuff

  • @botyironcastle
    @botyironcastle 25 วันที่ผ่านมา

    with golang you always have to reinvent the wheel, this is called required and optional params with default values, and a good language has it out of the box without defining 200 functions and polluting the code space and destroying readability.

  • @jf3518
    @jf3518 10 หลายเดือนก่อน

    Great work around. Though I would not use it, as I cannot use an existing config to initialize the state. Instead I would just use merge function to join default config with provided config.

  • @pyronb
    @pyronb ปีที่แล้ว

    Can somone please rephrase what's happening at 6:15 with fn(&o) ? It's not clear to me how everything works together

    • @ja31ya
      @ja31ya ปีที่แล้ว +2

      He's using the spread operator to allow as many OptFunc's as you want. He then uses the range operator to loop through each OptFunc and executes them with a reference to the options struct (that's the **fn(&o)**), so that the OptFunc can modify the options directly, overwriting the default options.

  • @pserra94
    @pserra94 ปีที่แล้ว +3

    Hi Antonio, how are you? I'm migrating from nodejs to Golang thanks to you and your videos, always amazing! I don't know if it's asking too much, but could you make a video/tutorial for developing web crawlers with golang, please? I was googling about it but I didn't find any good content about it. Thank you so much my friend, you are amazing!

  • @fringefringe7282
    @fringefringe7282 ปีที่แล้ว +1

    This is pretty cool.

  • @victorkochkarev2576
    @victorkochkarev2576 7 หลายเดือนก่อน

    This is a beautiful pattern!

  • @fluctura
    @fluctura ปีที่แล้ว +2

    Meanwhile in TypeScript:
    mergedOpts = {
    ...defaultOpts,
    ...opts
    } as Opts
    But its a cool pattern. Go doesn't have "map spread operator" and thats a good thing probably. But sometimes it would be so handy to have more syntactic sugar

    • @fluctura
      @fluctura ปีที่แล้ว

      btw it is a mix of Higher order Functions you write and you use them to compose a struct using Inversion of Control.
      So basically Higher order compositional Inversion of Control based state management (as your config acts as a state) 😂😅

  • @PouriyaJamshidi
    @PouriyaJamshidi ปีที่แล้ว +3

    This was really informative.
    A side question. Any particular reason for using int instead of uint in maxConn?
    I noticed most people use int where a uint makes more sense. In this case, we cannot have negative maxConn.

    • @anthonygg_
      @anthonygg_  ปีที่แล้ว +3

      Just for demonstration purposes. Uint is better.

    • @PouriyaJamshidi
      @PouriyaJamshidi ปีที่แล้ว

      @@anthonygg_ Thanks.
      I think somewhere I heard something along the lines of integer underflow and was wondering if this has something to do with that

    • @helmchen1239
      @helmchen1239 ปีที่แล้ว +2

      -1 meaning unlimited could be an option in that case though :)

  • @matiasbpg
    @matiasbpg ปีที่แล้ว +3

    What is the advantage of this pattern over a builder pattern?

    • @sfsdeniso5941
      @sfsdeniso5941 ปีที่แล้ว +1

      Error handling
      In go you cannot chain builder calls as each must return error (and not this)

    • @matiasbpg
      @matiasbpg ปีที่แล้ว

      @@sfsdeniso5941 thanks for the answer! However I think a builder for the opts struct shouldnt have this problem, but now I can see the inconvenience. Maybe a walk around could be that the builder struct could itself carry through the error as a property and the build method could return the value error tuple

  • @startengine8838
    @startengine8838 ปีที่แล้ว

    how inner function (the one that you retuen in options functions) gets the pointer which it has as input when higher lexical scope doesnt provide it

  • @vanshajdhar9223
    @vanshajdhar9223 ปีที่แล้ว +1

    Beautiful ❤️

  • @Rohinthas
    @Rohinthas 7 หลายเดือนก่อน

    Aah functional stuff is just so pleasing to think about

  • @ShadwTrooper
    @ShadwTrooper 8 หลายเดือนก่อน +1

    Clever. I like it.

  • @michael_loc009
    @michael_loc009 ปีที่แล้ว

    I wish you would upload this amazing tutorial when I first learnt Go.

  • @johnb7657
    @johnb7657 10 หลายเดือนก่อน

    Thank you, perfect

  • @fauzi5848
    @fauzi5848 ปีที่แล้ว

    This is so useful, thank you so much!

  • @Epistemer
    @Epistemer ปีที่แล้ว +4

    This is honestly really cool, I always hated how there is no way to do kwargs in go

  • @orterves
    @orterves 8 หลายเดือนก่อน

    That's a beautiful pattern

  • @mihaiii6720
    @mihaiii6720 ปีที่แล้ว

    This pattern is so good !!! I guess you can use it in TS/JS too

  • @maninalift
    @maninalift ปีที่แล้ว

    Is there an advantage over the builder pattern? It seems to be equivalent in usage but I'd guess harder to optimise.

  • @yawneed
    @yawneed 9 หลายเดือนก่อน

    Hello. Where does download your vscode config?

  • @x0z59
    @x0z59 ปีที่แล้ว

    will this thing not make established Go features convoluted? aren't you not reinventing the wheel here?

  • @ChristopheHa
    @ChristopheHa ปีที่แล้ว

    I guess this could also be combined with builder pattern, and then you can just can chain those withX on the builder and build will return the instance

  • @henrisetiawan7547
    @henrisetiawan7547 7 หลายเดือนก่อน

    Gem....amazing explanation..and going sub ..

  • @inaccessiblecardinal9352
    @inaccessiblecardinal9352 ปีที่แล้ว

    Good stuff. Aws' sdk has this pattern in every client (that I've used).

  • @ivanrachev9409
    @ivanrachev9409 ปีที่แล้ว

    Cool approach! Just wondering, why did you go back to VS Code?

  • @TheSurvivor1963
    @TheSurvivor1963 8 หลายเดือนก่อน

    This is a good pattern, I've been using it for years, but why not make an option function that returns the same option function with the previous value? That way you can change and reset options on the fly. An example could be to elevate debug logging temporarily for some very complex code segment. Rob Pike wrote an article about this for some years ago.
    type Option func(*Some) Option
    type Some struct{
    ...
    dLevel int
    }
    func Debug(d int) Option {
    return func(s *Some) Option {
    t := s.dLevel
    s.dLevel = d
    return SetOption(t)
    }
    }

  • @seanknowles9985
    @seanknowles9985 ปีที่แล้ว +1

    Hey big boss, two questions:
    1. How to make an efficient cron job scheduler from scratch?
    2. How to make realtime subscriptions to database values - for example we have key value store but then we build realtime subs that can subscribe to changes of a key and its data?
    Another quality video for the fans homie, love this channel.
    Bests,
    Super fan.

  • @mozhago8280
    @mozhago8280 ปีที่แล้ว

    Is this pattern used in go starndard lib?

  • @folium5725
    @folium5725 ปีที่แล้ว +1

    Hi Anthony, what theme do you use?

  • @GustavoFSx
    @GustavoFSx 5 หลายเดือนก่อน

    Beautiful

  • @suikast420
    @suikast420 10 หลายเดือนก่อน

    Cool fancy< stuff. What about toi make a fluent api with that style?

  • @chaitany.a
    @chaitany.a ปีที่แล้ว

    This is like a functional builder pattern...?

  • @Md.MitunRahman
    @Md.MitunRahman ปีที่แล้ว

    this is unbelievable

  • @1_PieceOfCode
    @1_PieceOfCode 4 หลายเดือนก่อน

    why not just set default conf at first and then use factory pattern so user can just change config as he wants?

  • @MrXperx
    @MrXperx ปีที่แล้ว +2

    Looks to be a variation of the builder pattern. (I come from OOPS)

  • @plashless3406
    @plashless3406 ปีที่แล้ว +1

    amazing.

  • @heartly4u
    @heartly4u ปีที่แล้ว +8

    why not create a builder pattern, which will do the same as what you are doing, with more readability.

    • @JohnDoe-ji1zv
      @JohnDoe-ji1zv ปีที่แล้ว +1

      Can you share example how your pattern is more clear than the one shown in a video ?

    • @heartly4u
      @heartly4u ปีที่แล้ว +6

      @@JohnDoe-ji1zv wouldnt it be more readable this way newServer().withTls().withId().withMaxConnections().build()

    • @tgraupne
      @tgraupne ปีที่แล้ว

      I was thinking about the same thing. 🤔 Maybe the authors or some other people would like to chime in.

  • @kevinkkirimii
    @kevinkkirimii ปีที่แล้ว

    I have misused this pattern. Quite useful

  • @MENTOKz
    @MENTOKz ปีที่แล้ว +1

    oh snap cool man

  • @robinlioret7998
    @robinlioret7998 ปีที่แล้ว

    I think it's a Go version of the Builder pattern, but not sure.

  • @jmouraa
    @jmouraa ปีที่แล้ว +2

    Great video Anthony, however, I believe we lose the the info from LSP, and this is kind of annoying specially dealing with new libraries, is there any difference by doing in this way?
    func newServer() *Server {
    return &Server{}
    }
    func (s *Server) withTLS() *Server {
    s.tls = true
    return s
    }
    func main() {
    server := newServer().withTLS()
    }

    • @anthonygg_
      @anthonygg_  ปีที่แล้ว

      You got a very good point here. Didnt thought about it that way.

  • @TimurSevimli
    @TimurSevimli 11 หลายเดือนก่อน

    Why not just take configuration data from a JSON file, like config.json?

  • @myrachoantonio8832
    @myrachoantonio8832 ปีที่แล้ว +1

    that was really cool trick i like it

  • @sfsdeniso5941
    @sfsdeniso5941 ปีที่แล้ว +3

    It is called 'Functional options pattern'

  • @luizfernandopereira5120
    @luizfernandopereira5120 ปีที่แล้ว

    This pattern is just an adptation from the Fluent Interface Pattern existing in OOP languages, is nice to see it in go though.

  • @faiz_0000
    @faiz_0000 2 หลายเดือนก่อน

    damn, so much work for just an optional config parameters
    can't you just make every args optional and assign default value to it if its nil?

  • @polnio
    @polnio 7 หลายเดือนก่อน

    This pattern looks a lot like the builder pattern. Am I wrong?

  • @timurgirfanov531
    @timurgirfanov531 ปีที่แล้ว +2

    It's like Visitor pattern, but in a functional way

  • @metaltyphoon
    @metaltyphoon ปีที่แล้ว +3

    AWS SDK uses this pattern too.

  • @HiperCode10100
    @HiperCode10100 ปีที่แล้ว

    very good thx bro

  • @Edd211
    @Edd211 ปีที่แล้ว +1

    How to code??

  • @dmitriyobidin6049
    @dmitriyobidin6049 10 หลายเดือนก่อน +1

    The only problem i have with this pattern is that it is not obvious which methods/func you can use as options.

  • @jungervin8765
    @jungervin8765 2 หลายเดือนก่อน

    Why not just create a default struct every time you want to use this. Create a default func, and the user can change the options. How is all that "with" functions not polluting the function names?

  • @rooariimanuel204
    @rooariimanuel204 4 หลายเดือนก่อน

    variadic functions for newServer

  • @ЏонМастерман
    @ЏонМастерман 11 หลายเดือนก่อน

    This is essentially a builder pattern written in Go.

  • @codewithtee
    @codewithtee ปีที่แล้ว

    I did something with this .... But my approach was quite different,

  • @AmedMoore
    @AmedMoore 7 หลายเดือนก่อน +2

    This pattern is called “over engineering”

  • @vasiliyaristov7148
    @vasiliyaristov7148 10 หลายเดือนก่อน

    Interesting

  • @ПавелСироткин-м5е
    @ПавелСироткин-м5е ปีที่แล้ว

    docker compose v2 uses this pattern

  • @JasonJA88
    @JasonJA88 ปีที่แล้ว +1

    👍