Its so nice to see that I'm doing a lot of things the "right" way, but this still has a lot of "OH, that would make things so much easier" patterns. Looks like I'm going to be updating my API template ... again :) Thanks
I really respect Mat Ryer, and even use his moq code generator, but when I read his article I was disheartened to read him advocating for long parameter lists, at least without mentioning the cons for using them vs. structs. Simply put, when using long parameter lists you have to break the API of a function to add another dependency which has unfortunate ripple effects in terms of breaking code if 3rd parties are using it, and possibly worse, bloating pull requests often making it much harder and time consuming to review. Theo recently had a video about how larger PRs have been shown to significantly reduce velocity, and google says so too in their eng-practices blog (not posting a URL as TH-cam seems to hide my comments when I do.) With structs for optional parameters, nothing breaks if you add new properties and code in a backward compatible manner. I really wish Mat and other Gophers would consider the downsides of broken calls and bloated PRs more when they decide to just keep adding parameters to funcs .🤷♂️
Same. That was my biggest issue. Long parameter lists are so cumbersome and rigid. Otherwise it seemed like good advice to someone who has only dabbled in http handling.
Do you plan to launch a course or something similar with the code example you shown in the video? Saw the name "goschool" and hope you do something similar like you shown as example, liked very much your course on FrontEnd Masters. Thank you.
I stumbled into having encode and decode functions because in a project I used protobufs with an optional json fallback. Having all that logic in one place just made sense.
Hope you all enjoy the video - make sure to comment + like and subscribe if you havent already and check out the original article as well!
Its so nice to see that I'm doing a lot of things the "right" way, but this still has a lot of "OH, that would make things so much easier" patterns.
Looks like I'm going to be updating my API template ... again :) Thanks
Hey thank you :)
Really cool video, factory for middleware is one thing I have been doing since I learned go.
Like your channel (interested in learning Go). Found you from the Primeagen...
Your video cuts remind me of Max Headroom (from 80s MTV) 😂
shout out Primeagen+
@@MelkeyDev The Primeagen is the best but you're a close second Melkey!
nice video i coming from Javascript world , Thank you for helping keep going
:) no problem. Thank you for the comment
Best go content on yt ❤
A lot of great people out there make some great Go content but thank you ery much
Nice video man, good to have more content to rely on. Thanks and keep up
Thank you.
I will always do my best
Thanks for introducing awesome post
Nice edition, good job
Thank you - hope you enjoy
I really respect Mat Ryer, and even use his moq code generator, but when I read his article I was disheartened to read him advocating for long parameter lists, at least without mentioning the cons for using them vs. structs.
Simply put, when using long parameter lists you have to break the API of a function to add another dependency which has unfortunate ripple effects in terms of breaking code if 3rd parties are using it, and possibly worse, bloating pull requests often making it much harder and time consuming to review. Theo recently had a video about how larger PRs have been shown to significantly reduce velocity, and google says so too in their eng-practices blog (not posting a URL as TH-cam seems to hide my comments when I do.)
With structs for optional parameters, nothing breaks if you add new properties and code in a backward compatible manner. I really wish Mat and other Gophers would consider the downsides of broken calls and bloated PRs more when they decide to just keep adding parameters to funcs .🤷♂️
team structs baby
Same. That was my biggest issue. Long parameter lists are so cumbersome and rigid. Otherwise it seemed like good advice to someone who has only dabbled in http handling.
I suggest read Lets go further book it follows some useful patterns
😂😂😂😂😂
Shoutout to if err != nil had me rolling
BIG shout out
Another banger
ANOTHA ONE!!
Why not using the plug pattern for middleware like in Phoenix? Maybe because wirhout a reduce its impossible??
Im not sure I follow the comment
Why Chi? Aren't there Go native capabilities to make REST APIs?
Thank you 🙏
youre welcome
Best way not workung enything on steam
It reminds me of the Flask boilerplates in Python.
Do you plan to launch a course or something similar with the code example you shown in the video? Saw the name "goschool" and hope you do something similar like you shown as example, liked very much your course on FrontEnd Masters.
Thank you.
I stumbled into having encode and decode functions because in a project I used protobufs with an optional json fallback. Having all that logic in one place just made sense.
i love when things just make sense.
Just gets the BLOOD FLOWING
Excellent content as always. Hopefully the TH-cam gods start showing you the love your channel deserves.
Haha - pray to the algo Gods LOL
Fantastic article and video covering it!
Thanks for this
Youre very welcome
Encoding response with generics like "encode[T any](..." is stupid. No need to know type inside the func when passing "any" gives the same result.
team interface{} baby haha