VividCortex / siesta

Composable framework for writing HTTP handlers in Go.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Difficulty using siesta with certain use cases.

JnBrymn opened this issue · comments

Consider a service that has several related endpoints and there is a ton of shared setup for these endpoints (authenticate user, grab appropriate databases, etc.). Then it's good to put these into the "pre" middleware. But what if you've got like 1 or 2 endpoints that don't need to do all of this? Is there any way that you can omit the preware? Otherwise we're doing a lot of work for no reason.

One idea:

//normal invocation
service.Route("POST", "/envs", "Creates an env", createEnv)

//replace preware
service.WithPreware(nil).Route("POST", "/envs", "Creates an env", createEnv)

I agree. Do you think it might be possible with nested services?

That would be another possible route, but for the small services that we typically write, that might be overkill.

I think I mentioned this before, but I think the WithPreware approach means we need to push the handler matching loop before we run through the chain. Does that make sense?

Right now we run through the preware and then figure out which handler to choose:

siesta/service.go

Lines 58 to 66 in 653617e

for _, m := range s.pre {
if quit {
return
}
m(c, w, r, func() {
quit = true
})
}

That shouldn't be so bad though. Right? In some way it might make it
simpler; "route" is a mapping from a path to a handler and it doesn't
matter if the handler is simple or compound.

Yep. Although I'm not sure how we can use your syntax :).

Yeah. I was thinking about that. I can see through to how I would implement
my syntax... but I think it would be unnecessarily complicated.

Devil's advocate here 😈 :

I started thinking that it might be nice to just explicitly call out the pre/actual/post handlers:

func (s *Service) service.Route(verb, route, description string, preHandler, handler, postHandler Handler)

But then it occurred to me that we could achieve this functionality and simplify the current interface significantly by just 1) removing AddPre() and AddPost() and 2) using Compose. So a routing call would look like

service.Route("GET", "/fruit", "Gets a fruit", siesta.Compose(fruitParser,fruitDbRetriever,fruitShiner))

So 😈 asks: Is the cool part really just the fact that we can now compose handlers together and keep track of a context between them?

Yeah, you're right. I don't think you have to use those chains.