-
Notifications
You must be signed in to change notification settings - Fork 181
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Course Feedback #76
Comments
It took me a while to figure out that best way to get into the repl was
|
Alrighty, I've interleaved my answers with your points. Hopefully this helps!
I think more of this comes through in the classroom discussions regarding 'type The intent is to use the types to define the API such that you narrow your focus Thus the internals of your application need only care about something that is a It's a change in perspective... The 'goal' of Following on from that, the 'goal' of Consequently the implementations of Does that make sense? Thinking hard upfront and finding/designing types that represent your If I have a chance I'll check that book out and see if it has more formal
Keep going!! Ask for help here or irc/discord/email. :)
There isn't always a consistent step in effort between the levels, and this
I think it's important to note that the solutions that exist in later levels The types and abstractions are tools to be used to achieve a goal, this is not
The struggle is worth it, and remember that a lot of other people have the
Yes, this is a key thing to notice.
Ahh naming things, the eternal struggle continues. There is nothing in the
WOO! That is the primary goal, learning happens as a consequence. :) |
A couple of points I found more challenging then I think they aught to be... This of course varies very much from person to person. And who they have around to answer questions.
A this was self study here are some points I think were harder to grasp.
It feels like the code is moving towards a pattern where the business logic is clean sperated from HTTP and DB layers. E.g. what is described well in: https://pragprog.com/book/swdddf/domain-modeling-made-functional
I think having some overview in the top level README of what the final process would with some tips:
Wai Request -(a)-> RqType -(b)-> Business Logic -> Event -> DB Dto -> DB -> Business Logic -> JSON Dto -> Response
Tips:
a. The goal of Core.hs
mkRequest
b. The goal of Core.hs
handleRequest
The rest of the chain is still not clear to me at the moment as I'm still progressing through that :)
After working through this and then looking at what is in the repository for Level04 I landed here:
NOTE: I had changed the handleRequest to include the IO monad (so the above is slightly different than what you would do if you just did level 02 without doing that).
I think
resp <- hResponseErr <$> hRqTypeErr rqt
is hard to come up with as a begineer from scratch. My first solution wasn't that nice...However if the helpers
hRqTypeErr
andhResponseErr
had been defined or at least stubbed as methods, I might have got there sooner. Maybe the struggle was worth it ;)I think what took me time to understand is that the handling of Error happens at two different levels.
handleRequest
should be in the IO Monad in Level02Because you know this is going to be required at some point, I reworked the code in Level02 to include it there.
E.g.
handleRequest :: RqType -> IO (Either Error Response)
Request
vsRqType
.It might have been more easily understood if
RqType
had constructorsAddCommand
,ListQuery
,ViewTopicQuery
. Or some other names to make the distinction clearer.BUT OVERALL I HAVE FOUND THIS FUN AND INTERESTING!
The text was updated successfully, but these errors were encountered: