question: Why Resource in Server.scala? about scala-pet-store HOT 2 CLOSED

@edio good question. What is best practice escapes me at the moment, need to do a little more research on that end.

As to why things are the way they are, I can give a little color on that.

Originally, I believe everything in the for comprehension was loaded in IO. The motivation being that if anything failed when the app started up, the app wouldn't start up.

Now, the Server itself has gone through revisions as dependent libraries have been updated. Most likely (without looking at the commit history), Resource was introduced as part of the update to http4s 0.20. You can see the example on starting an Http4s service uses Resource similar to what we have - https://http4s.org/v0.20/service/

Also, doobie also leverages Resource. Both of those make sense, because not only do you want to acquire a resource, you also want to control the finalizer (which seems reasonable for an HTTP Server and a database).

For the things that "aren't really Resource" in that for comprehension, the release does nothing. From what I have gathered Resource is just an ADT with a finalizer, and for many circumstances (using liftF) you have no finalizer.

For example, the line Resource.liftF(parser.decodePathF[F, PetStoreConfig]("petstore")) is doing nothing more than eventually running the expression inside the Resource, just like IO, and when it is complete essentially it will not do anything.

When building a for comprehension, we have to lift all the things into a common Monad, so here the "unwavering" Monad is Resource

I will ping some folks around here to see if this is considered idiomatic, and if there are any downsides

from scala-pet-store.

I think Paul covered this pretty well. Resource.liftF and Resource.pure just put values into the Resource context with no extra machinery. The final call in Server kicks the server off and never returns. So there should not be a difference between using the underlying values directly, or using the values within the Resource context. Neither will fall out of scope.

And yeah to echo Paul's point, circe-config just hands off to typelevel's config for opening and closing the file, and returning the case class instances inside of some F. So that part is interesting, if the F is IO, then I would expect within that IO, the file is opened, parsed, and closed, before the next line in the for expression is executed.

This question helped us think about these issues a bunch, so thanks. I'm going to go ahead and close this and feel free to reopen the discussion in the gitter channel.

from scala-pet-store.