Seperate out the REST interface from the core functionality.

[monksy]

This is to serperate out the core functionality from it's REST interface. This would give a chance to other REST frameworks to show how to integrate with the project.

This would make a new repo called: scala-pet-store-http4s

[pauljamescleary]

@monksy this requires some thinking. I do think it is valuable to have different versions of the application. At the initial outset, I thought that having alternative versions for scalaz, fs2, etc.

The value that having everything in a single project is that you can see everything in one place. If we start parsing out pieces, you lose "what does an entire application look like", which is one of the goals of the project.

There are a lot of permutations for the entire project (use slick or quill instead of doobie, use free-monad or mtl instead of tagless final, etc.). Tbh, unclear on how to manage all of those permutations.

If there was some kind of uber mono-repo that held possible permutations, that could hold this specific variation of the project.

I like keeping this minimal. The goal is to see an entire application built on the Typelevel "stack", using the latest advancements and current thinking in that stack. Still waiting for someone to tell me that mtl is the current best practice so I can make that update :)

Thanks for all your ideas on this

[zakpatterson]

On a related note, I've been trying to figure out a way to organize code so that the response and serialization types are separated a little better from the "business logic". For example,

The entire service is a Kleisli[OptionT[F, ?], Request[F], Response[F]]. It comprises turning a Request[F] into an A (deserialization), and an A into a B (business logic), then a B into a Response[F] (serialization).

Being able to compose from:

1. Kleisli[OptionT[F, ?], Request[F], A]
2. Kleisli[F, A, B]
3. Kleisli[F, B, Response[F]]

Would make more sense, and probably make it easier to introduce pre and post actions like cache and logging. It would also mean that the Http4s parts are left in parts 1 and 3 and part 2 would have no dependence on http4s.

The _Service classes basically do this already though.