Another Amazing Use Case For The FOP Pattern In Go

Рет қаралды 9,556

4 ай бұрын

► Join my Discord community for free education 👉 / discord
► Exclusive Lessons, Mentorship, And Videos 👉 / anthonygg_
► Enjoy a 60% Black Friday Discount on My Golang Course 👉 fulltimegodev.com
► Learn how I became a self-taught software engineer 👉fulltimegodev.com/#mystory
► Follow me on Twitter 👉 / anthdm
► Follow me on GitHub 👉 github.com/anthdm
Functional options pattern: • The Most Efficient Str...
SUBSCRIBE OR NO MARGARITAS
╔═╦╗╔╦╗╔═╦═╦╦╦╦╗╔═╗
║╚╣║║║╚╣╚╣╔╣╔╣║╚╣═╣
╠╗║╚╝║║╠╗║╚╣║║║║║═╣
╚═╩══╩═╩═╩═╩╝╚╩═╩═╝

Пікірлер: 39

@anthonygg_ 4 ай бұрын

► Join my Discord community for free education 👉 discord.com/invite/Ac7CWREe58 ► Exclusive Lessons, Mentorship, And Videos 👉 www.patreon.com/anthonygg_ ► 60% OFF on my Golang course 👉 fulltimegodev.com Thanks for watching

@frankieboyseje 3 ай бұрын

the example curriculum at "fulltimegodev" is that all the curriculum on the site or is there more content? would really appreciate if you answer :) thx been reading/coding along through "lets go" and "lets go further" so looking for more advanced stuff and techniques.

@massy-3961 4 ай бұрын

This is hilarious, I’m currently making my own validation library that is inspired by zod. I guess we both hate the current state of go validation libraries where our struct tags are longer than the struct itself.

@anthonygg_ 4 ай бұрын

Yup we all hate it. 😂

@dyto2287 4 ай бұрын

I don't think we can get similar valdiation to zod in Go. What makes zod great is that it gives some input data type-safety in typescript. But with Go, we can't build validation schema that is type-safe for input data. And using reflect api for validating data input "any" is kind of lame in Go. I usually avoid those validators.

@massy-3961 4 ай бұрын

@@dyto2287 well the good thing about compiled languages is that when you parse or create objects, it’s already halfway validated. Unmarshalling json into a struct guarantees that calling any of the fields on that struct won’t be unresolved. So in the sense of making an “any” or “unknown” validated, you don’t really need that feature, you already know what you are passing into a validator you don’t need to verify that your payload.username is a string you already know it will be.

@massy-3961 4 ай бұрын

@@dyto2287 a validator in Golang won’t be making sure input data or “unknown”s don’t follow the struct types, but more or less verifying that the string for email is actually an email, or that the password is atleast 8 characters long. We don’t actually need to check if it’s a string like you would in zod.

@MarcusSanchez-fi4uf 4 ай бұрын

@@dyto2287 Well in golang input data is already type safe, when you unmarshall JSON into a struct, you are already getting validation because if a data type can't be parsed into the type of the struct field, it will error. In typescript however, when you parse data, its considered "unknown" which is not validation requiring the use of Zod. The only difference is when it comes to validating specific requirements of fields, like min(), max(), eq(), lte(), gte(), positive(), email(), IPV4(), ISBN(), and so on. Doing these specific requirements are what would make a golang zod library useful, not necessarily validating that a string is actually a string, because in compiled languages, you already know it is.

@jackn 4 ай бұрын

i have a video request for you - golang refresher (for people who haven't touched the language in a while) specifically looking for a quick refresher on common patterns, and maybe some of the newer important features in the past 3-5 years

@rochakgupta6116 4 ай бұрын

Had been thinking about building something like this for my own use case and this pattern seems like a great fit. Thanks for sharing!

@amitkumdixit 4 ай бұрын

I had created a similar basic one inspired from C# FluentValidation. I will wait for yours. Thanks a lot

@thegittubaba 4 ай бұрын

It looks very cool! Almost like symfony validator component, Its awesome.

@manfrombritain6816 4 ай бұрын

could have done with seeing the implementations of 'required' and 'max(100)' just to add some context to the rulefuncs. love your channel!

@z01d 4 ай бұрын

Hey Anthony, loving your Vscode setup (among other things). Do you have it public somewhere by any chance?

@jaans3712 3 ай бұрын

I have to ask… Where is this thick accent coming from? I love it 😄

@marinmiletic9386 Ай бұрын

I just built something like this a month ago for myself since there is not library that did stuff like this

@manaspaul 4 ай бұрын

Is it going to have multiple messages based on the failure? Like we can do it in builder patterns? For each validation I can pass the message as a second argument

@dyto2287 4 ай бұрын

Immediately see a problem in this design. This will get very tricky when one field value validation depends on the values of other fields.

@codestalk9183 3 ай бұрын

i already like it ! git link please, would be great to make a declarative validation framework for structs or forms etc with. absolutely loved the idea

@cibokim5758 4 ай бұрын

감사합니다.

@OldKing11100 4 ай бұрын

I like this idea and potentially a great replacement for playground Validator and Mold. I do prefer each validation to produce its own error and then newline join them all at the end errors.Join(err_arr...). It is a nicer pattern then adding more junk to struct tags.

@salehmir9205 3 ай бұрын

I also hated the current validation libraries. Could you please open source this?

@Yu-qv3qc 4 ай бұрын

i have a question, why did you change back to vscode from neovim?

@anthonygg_ 4 ай бұрын

Its just a better UI. Im still using the vim mechanics. So there is no difference besides a better UI

@thoriqadillah7780 4 ай бұрын

I think FOP would be more make sense compared to builder pattern because we don't have to call validate at the end of the function. It's simple, but in my opinion is cleaner

@anthonygg_ 4 ай бұрын

The Validate at the end is to marshal the errors into a custom struct. Could maybe add that in just 1 function Validate(in, out, fields)