Skip to content
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

Difficulty using siesta with certain use cases. #11

Closed
JnBrymn opened this issue Oct 11, 2014 · 8 comments
Closed

Difficulty using siesta with certain use cases. #11

JnBrymn opened this issue Oct 11, 2014 · 8 comments

Comments

@JnBrymn
Copy link
Contributor

JnBrymn commented Oct 11, 2014

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)
@Preetam
Copy link
Contributor

Preetam commented Oct 12, 2014

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

@JnBrymn
Copy link
Contributor Author

JnBrymn commented Oct 12, 2014

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

@Preetam
Copy link
Contributor

Preetam commented Oct 12, 2014

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
})
}

@JnBrymn
Copy link
Contributor Author

JnBrymn commented Oct 13, 2014

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.

@Preetam
Copy link
Contributor

Preetam commented Oct 13, 2014

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

@JnBrymn
Copy link
Contributor Author

JnBrymn commented Oct 13, 2014

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.

@JnBrymn
Copy link
Contributor Author

JnBrymn commented Oct 13, 2014

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?

@Preetam
Copy link
Contributor

Preetam commented Oct 31, 2014

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

@Preetam Preetam closed this as completed Feb 26, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants