Started learning go a week ago as a experienced developer and boy oh boy do I already love it with all my heart. It's all so easyyy and simple and straight to the point
I find that context as a kv store tends to get messy when it's really common in a codebase. This has perf overhead (contexts are trees, and key lookups are traversals) but worse it can lead to hidden side effects if a function differs it behaviour based on contextual information. It can be a lifesaver if you need to have a globally accessible request scoped value, but use with caution.
bryan your videos are awesome too. i remember there was so little good go content a couple of years go and I stumbled on your videos. I was starting a new job and your videos helped me ramp up. thank you.
Prime, using middleware to put things into a context is a super cool pattern. Let’s say you have the following route `/foo/:fooID/bar/:barID`. You could have a middleware package maintain a cache of the `foo` resource by its `fooID`. The middleware can pull the `fooID` from the path, and put the `foo` resource into the request context. This means that `bar`s handler doesn’t need to know the specifics of how to fetch `foo`, it just pulls it out of the context. If we add another route like `/foo/:fooID/grug/:grugID`, the ‘grug’ handler will also have access to the `foo` resource. As routes continue to be added under `foo`, you save yourself the trouble of putting in the boilerplate code to go fetch it.
I initially liked the approach, but mapping all values to `interface{}` within the context package of Go posed challenges due to its generic nature. To address this, I now define a struct with fields that are consistently required across different middleware handlers. This struct is passed as a parameter to handler functions, which improves type safety and enables syntax highlighting, making the code more maintainable. I remain open to other solutions that may be more efficient though.
@ thanks for taking the time to share your thoughts. My example is trying to demonstrate how middleware and a context can be used to handle resource caching. I can see now that I’m making the assumption that the reader already knows something about resources on an HTTP server, and knows what resource caching is. To be fair to me, the comment was directed towards the creator of the video, who would be familiar with these concepts. In the example, `foo` and `bar` are generic names for resources, and the route structure suggests that each `foo` can own one or more `bar`. I can replace those words with something less generic though; let’s say we are working with multiple questions for a test, and that `foo` is a `question` and `bar` is a possible `answer` to that question. Let’s also say that our system also needs to support different types of questions (multiple choice, numeric input, etc), and that only multiple choice questions can have answers. This business rule means that if a user tries to add an answer to a question, we need server-side logic to reject the request. Let’s also say the operation to add a nee answer to a question involves a POST request to `/questions/:questionId/answers`, and that the body of the request would contain the answer. The request handler on the server would be able to use the request’s context to know the questionId, and the answer the user is trying to add to the question. In order to execute our business logic, the request handler needs to be able to use the questionId to determine if the question is of the multiple choice type. One way to solve this issue is to have a system that will return a question when given a questionId. Once implementation of this system could be a repository, which stores questions in a database and indexes them based on their the questionId. Another implementation would be to maintain a cache of questions indexed by their questionId in the server middleware. That middleware could then use the questionId in the request context to add the question to the context. That way, when the handler gets the request context it can now access the questionId, answer, as well as the question. From the handler’s point of view, this is all done without having to interface with any other system, and it doesn’t need to know how to fetch a question based on it’s questionId. This also means that other handlers that are under the `/questions` route do not need to have this knowledge as well! All of those handlers just get it from the context.
C# (sorry for the curse word), as said earlier, has it as 2 separate concepts: CancellationToken and HttpContext 1)CT just basically passed inside of any async method, and internal method should manually check, when running continuous operation, is token revoked, and stop in this case. 2)HC is basically storage for all request-scoped data, e.g. user identity, headers, request and response data, and it's shared between chains of async called method (because async in c# works as a state machine, so diff. threads, that work on 1 chain, should somehow now, how to have contrxt of request)
The cast can not blow up because it’s one with two assignments (There’s probably a proper name for this): the casted value and ok (bool indicating if the cast was successful). This is even mentioned in the comment above in the example code.
I do a DB lookup of a user by his token and then I put all the necessary info into context (key, value) and use it across the functions which have access to the request. It's just something you share data across functions within one request. No different from a React context, where you share data across components.
Children cannot cancel the parent but they can cancel their own children's context derived from them. I have seen open telemetry using context in a great way
![Felix "Unfair" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/Oswujxm2Ag0/mqdefault.jpg)
Started learning go a week ago as a experienced developer and boy oh boy do I already love it with all my heart. It's all so easyyy and simple and straight to the point
It's Python but with compiler and blazzzinglyy fast.
Hey Prime, we would love more of your takes on advanced Go topics.
Thank you for your hard work!
Loving this Go content lately, adding all of them to downloads to binge watch 💯
I find that context as a kv store tends to get messy when it's really common in a codebase.
This has perf overhead (contexts are trees, and key lookups are traversals) but worse it can lead to hidden side effects if a function differs it behaviour based on contextual information.
It can be a lifesaver if you need to have a globally accessible request scoped value, but use with caution.
Prime, ninja edition
Will he update the thumbnails when he returns to normal… hmmm
lol
It looks terrible 😂
Context is amazing. Watching you learn Go is super awesome, I’ve been with it for almost 10 years and it just now feels like Go is getting its due.
bryan your videos are awesome too. i remember there was so little good go content a couple of years go and I stumbled on your videos. I was starting a new job and your videos helped me ramp up. thank you.
Prime, using middleware to put things into a context is a super cool pattern.
Let’s say you have the following route `/foo/:fooID/bar/:barID`. You could have a middleware package maintain a cache of the `foo` resource by its `fooID`. The middleware can pull the `fooID` from the path, and put the `foo` resource into the request context. This means that `bar`s handler doesn’t need to know the specifics of how to fetch `foo`, it just pulls it out of the context.
If we add another route like `/foo/:fooID/grug/:grugID`, the ‘grug’ handler will also have access to the `foo` resource.
As routes continue to be added under `foo`, you save yourself the trouble of putting in the boilerplate code to go fetch it.
That's super interesting. Any code examples?
I initially liked the approach, but mapping all values to `interface{}` within the context package of Go posed challenges due to its generic nature. To address this, I now define a struct with fields that are consistently required across different middleware handlers. This struct is passed as a parameter to handler functions, which improves type safety and enables syntax highlighting, making the code more maintainable. I remain open to other solutions that may be more efficient though.
The foo bar crap is so useless, if you can’t express a use case in real world terms for your relative domain then you’re just yanking to syntax
@ thanks for taking the time to share your thoughts. My example is trying to demonstrate how middleware and a context can be used to handle resource caching. I can see now that I’m making the assumption that the reader already knows something about resources on an HTTP server, and knows what resource caching is. To be fair to me, the comment was directed towards the creator of the video, who would be familiar with these concepts.
In the example, `foo` and `bar` are generic names for resources, and the route structure suggests that each `foo` can own one or more `bar`. I can replace those words with something less generic though; let’s say we are working with multiple questions for a test, and that `foo` is a `question` and `bar` is a possible `answer` to that question.
Let’s also say that our system also needs to support different types of questions (multiple choice, numeric input, etc), and that only multiple choice questions can have answers. This business rule means that if a user tries to add an answer to a question, we need server-side logic to reject the request.
Let’s also say the operation to add a nee answer to a question involves a POST request to `/questions/:questionId/answers`, and that the body of the request would contain the answer. The request handler on the server would be able to use the request’s context to know the questionId, and the answer the user is trying to add to the question.
In order to execute our business logic, the request handler needs to be able to use the questionId to determine if the question is of the multiple choice type. One way to solve this issue is to have a system that will return a question when given a questionId.
Once implementation of this system could be a repository, which stores questions in a database and indexes them based on their the questionId.
Another implementation would be to maintain a cache of questions indexed by their questionId in the server middleware. That middleware could then use the questionId in the request context to add the question to the context. That way, when the handler gets the request context it can now access the questionId, answer, as well as the question. From the handler’s point of view, this is all done without having to interface with any other system, and it doesn’t need to know how to fetch a question based on it’s questionId.
This also means that other handlers that are under the `/questions` route do not need to have this knowledge as well! All of those handlers just get it from the context.
C# (sorry for the curse word), as said earlier, has it as 2 separate concepts: CancellationToken and HttpContext
1)CT just basically passed inside of any async method, and internal method should manually check, when running continuous operation, is token revoked, and stop in this case.
2)HC is basically storage for all request-scoped data, e.g. user identity, headers, request and response data, and it's shared between chains of async called method (because async in c# works as a state machine, so diff. threads, that work on 1 chain, should somehow now, how to have contrxt of request)
C# MENTIONED
IIRC there is no propagation of cancellations in C# (except manual)
The cast can not blow up because it’s one with two assignments (There’s probably a proper name for this): the casted value and ok (bool indicating if the cast was successful). This is even mentioned in the comment above in the example code.
Love the learing with the Primeagen , would love to see more of this
I do a DB lookup of a user by his token and then I put all the necessary info into context (key, value) and use it across the functions which have access to the request. It's just something you share data across functions within one request.
No different from a React context, where you share data across components.
17:28 real Dad moment showing through right there
Prime's brain is transparent now
His hair is the same colour as the text string highlights. lol
we can see through your brain .😂😂
Children cannot cancel the parent but they can cancel their own children's context derived from them. I have seen open telemetry using context in a great way
So they made dynamic variables. Isn't that what that is about, petty much, just dynamic variables implemented by hand?
Does anyone feel like Go is the spiritual successor to Perl? No? Just me . . . .okay.
Thanks for the video Prime!
Hell nah . Now there is a project called Go++ (compiles to Go) that would fit that description
Gen this is similar to C#' ish Cancellation tokens.
"vim is crap if you want it to be like vscode"
How did he make the page display in dark mode?!
DarkReader, probably
Good video
Nice hair
switchHairColorWithMustache()
if you wanted js to be a backend language it would be terrble - node.js: am i a joke to you ?
(yeah you are but anyway xD )
Probably can whip out a context like thing in Rust in an evening
(I use Rust btw)
Nice transparent hair.
This talk explains context incredibly well imo: ruclips.net/video/mfgBhGu5pco/видео.html
balding