Support for custom routes and handlers

[vito]

I'm converting an app that handles GitHub webhooks, which requires access to some lower-level things:

• Access to the X-GitHub-Event, X-GitHub-Delivery, and X-Hub-Signature-256 headers
• Access to the raw request body []byte or io.Reader so I can validate the request signature

The most convenient thing for me would be to have direct access to the *http.Request so that I can use common interfaces like github.ValidatePayload.

Would this be considered in scope of this project? If so I'd be happy to submit a PR if you have an idea for how it should work.

Here's a strawman proposal: if an action matches http.HandlerFunc, just call it directly.

type Controller struct {
}

func (c *Controller) Create(w http.ResponseWriter, r *http.Request) {
  // gets called like a regular http.Handler
}

This would also provide a path forward for SSE/WebSocket endpoints, though maybe you've got your own plans for that.

This is definitely a bit of an "escape hatch" so I'd understand if you want to think on it for a while.

Sub-topic: custom routes

I see custom routes are mentioned here: #112 (comment) - so I'll add this use case as a data point.

edit: eh, this is turned out to kind of a moot point and I had a lot of wrong/mistaken info so I just removed it to keep the conversation more focused. The tl;dr is I currently handle webhooks at /api/github/hook which isn't a CRUD route at all. I can change this to /integrations/github/events using bud new integrations-events (did I miss docs for this?) which seems better anyway. It'd be nice to separate API routes from web UI routes under /api though, and I'm curious whether custom routes will ever be supported in general. It'd be nice for maintaining backwards compatibility for apps migrating to Bud, but it's not a huge deal to me personally. I understand it may not be worth butting heads with the framework too much.

[matthewmueller]

Would this be considered in scope of this project? If so I'd be happy to submit a PR if you have an idea for how it should work.

Hey, yes! This is definitely something I plan to support. Escape hatches like this will be very important for complex routes like the one you provided. It was originally on the todo list for v0.1 but got bumped.

Here's a strawman proposal: if an action matches http.HandlerFunc, just call it directly.

This is exactly what I had in mind 😄 One of the beautiful thing about generating code is you get a lot more flexibility in what kinds of APIs you can provide.

One thing I'd like to keep just for consistency is the order. While it would be possible to also support func(r, w), I don't think it's worth the internal bikeshedding and we should just keep it func(w, r) or error out during generation.

edit: eh, this is turned out to kind of a moot point and I had a lot of wrong/mistaken info so I just removed it to keep the conversation more focused.

I'm assuming this was a moot point about custom routes? Either way, this one is still on the list. I'm not planning to make it quite as powerful as the routing you'd find in Rails/Laravel, it'll probably be more like Netlify's _redirects file. This way you can statically analyze it.

I can change this to /integrations/github/events using bud new integrations-events (did I miss docs for this?)

You should be able to do bud new controller integrations/github/events index, though I don't think I've tested this yet. You'll probably want to delete the generated views since it's just a webhook and then you'll need to manually add a func (c *Controller) Create() { ... } method I presume.

Sidenote: I'd like to rename bud new controller ... to something else. I copied Rails on this one, but I find it strange that bud new controller also creates views. bud new resource is reserved for when there's models, so I'm still looking for a decent name for scaffolding a controller + views. Thought about bud new page or bud new route, but not sure yet.

[vito]

This is exactly what I had in mind 😄 One of the beautiful thing about generating code is you get a lot more flexibility in what kinds of APIs you can provide.

Awesome - I have a local branch with this implemented, so I'll put together a PR. And yeah, agreed that this should strictly fit a http.HandlerFunc shape - (w, r) and no context.Context arg (use r.Context() intead), and no error return value. I think if the method doesn't fit this exact shape it should just fall back on the existing behavior.

You should be able to do bud new controller integrations/github/events index, though I don't think I've tested this yet.

Weird, I end up getting this in the generated web.go:

	router.Get(`/integrations/:integration_id/githubevents`, controller.Integrations.Github.Events.Index)

But if I manually create a controller/integrations/events/controller.go like this:

package events

import "net/http"

type Controller struct {
	// Dependencies...
}

// Event struct
type Event struct {
	// Fields...
}

func (c *Controller) Create(w http.ResponseWriter, r *http.Request) {
	// Create event
}

Then I get this route:

	router.Post(`/integrations/:integration_id/events`, controller.Integrations.Events.Create)

Which seems good. I can even get the :integration_id value from r.URL.Query().Get("integration_id") and verify that it's github or whatever other integrations I support in the future. 👍

But yeah, seems like there's some sort of issue with routes once you hit a certain controller depth.

Sidenote: I'd like to rename bud new controller ... to something else. I copied Rails on this one, but I find it strange that bud new controller also creates views. bud new resource is reserved for when there's models, so I'm still looking for a decent name for scaffolding a controller + views. Thought about bud new page or bud new route, but not sure yet.

Does Rails not also create views? Agree that it's a little odd for new controller to create both - at least not knowing how folks might use Bud yet, anyway. It'd be weird if it ends up being used for APIs a lot and folks end up just deleting views all the time. Maybe it could be behind a --views flag?

Side-side-note: I found bud create and bud new a bit confusing at first. One suggestion there: bud init instead of bud create? Also create doesn't show up in bud --help.

[donovanrost]

@matthewmueller > Sidenote: I'd like to rename bud new controller ... to something else. I copied Rails on this one, but I find it strange that bud new controller also creates views. bud new resource is reserved for when there's models, so I'm still looking for a decent name for scaffolding a controller + views. Thought about bud new page or bud new route, but not sure yet.

Just throwing this idea out there. What about:
bud new mvc -> creates a model view and controller
bud new m -> creates just a model
bud new vc -> creates a view and a controller
... and so on

[matthewmueller]

That's a very interesting idea!

[vito]

I dig it!