tylermmorton/torque

`torque` is a web framework for building hypermedia driven applications in Go

torque's Issues

Pocketbase: demo

You can use htmx with pocketnbase, but why ?

PB gives you the data layer that is reactive.
PB can code gen typed golang code from the a running PB, so then its easy to then use torque on top to build you GUI.
PB uses SSE to emit events to the GUI.

https://pocketbase.io/docs/use-as-framework/

https://pocketbase.io/docs/go-database/

---

The Golang code gen off PB aspects are here:
https://github.com/alexisvisco/pocketpase-gen
and
pocketbase/pocketbase#2697 (comment)

Documentation: `EventSource`, htmx and `hx-ext="sse"`

With the addition of the EventSource route module type, there is also basic support for the htmx sse extension in the torque/pkg/htmx sub-package as of 94a167a.

TODO:

• Add documentation to https://lbft.dev/server-sent-events
• Add dogfooding examples of how to use the new EventSource route module type in conjunction with htmx
  • Idea: Create a real-time viewer count component somewhere on lbft.dev
  • Idea: Poll GitHub API and create a real-time toast notification when changes are pushed to the docsite source.

Any todo examples

Very cool system @tylermmorton

i am also into htmx.

any examples so I can see the whole stack ?

Feature: Generic typed Loader/Renderer interface

In the current version of the torque API, Loader and Renderer simply use the any type to describe the loader data.

type Loader interface {
	Load(req *http.Request) (any, error)
}

type Renderer interface {
	Render(wr http.ResponseWriter, req *http.Request, loaderData any) error
}

It would be great for API ergonomics to be able to declare them using a generic combination interface:

Illustration:

type GenericRenderer[T any] interface {
	Load(req *http.Request) (T, error)
	Render(wr http.ResponseWriter, req *http.Request, loaderData T) error
}

Rough outline of solution:

• Implement new generic interface type from above in module.go.
• Update handleLoader and handleRenderer in server.go to support the new interface type. This may or may not be possible with the generic type.
• Add documentation to the docsite and provide guidance on API usage.

Refactor: Use the htmx-go package

The torque framework has its own htmx package, mostly containing logic to wire up WebSockets and SSE into torque.

Recently a new package was released called htmx-go that is a much more comprehensive implementation of htmx related features.

We should determine which logic in the torque htmx package can be deprecated and replaced.

Tasks:

• Investigate the htmx-go package and update the docsite implementation to use it.
• Deprecate all exported functions and constants in pkg/htmx/headers.go

Feature: Rate Limiting for Route Modules

Problem:

I often find myself configuring a rate-limiter guard for every route I register with a torque app. I think this is a good use case for the Guard API but if users end up registering the same guard on all of their endpoints, perhaps that is a sign that the guard logic should be implemented internally to torque.

torque.WithRouteModule("/login",
	&login.RouteModule{
		AuthService: authService,
	},
	torque.WithGuard(guards.ThrottleGuard(
		throttled.PerHour(25),
	)),
),

Rough outline of solution

• Implement rate limiting with sensible defaults using standard library (https://pkg.go.dev/golang.org/x/time/rate) as a part of the router in router.go.
• Provide an API to consumers for configuring rate limiting. For a route module this could be an additional interface in module.go?
• Document the new feature and push it to the docsite.

Feature: Uncaught Panic View

Problem

Whenever a panic is left uncaught in server.go a log is printed to the console and nothing is written to the response body. This results in a blank screen in the browser.

In development environments it might be useful to render some HTML to the browser containing details about the error such as message & stack trace.

Rough outline of solution

• Create a Go html template for the error page. Keep it simple for now and include styles in <style> tags.
  • Include error string
  • Include stack trace
• In handlePanic of server.go, write the new error page to the response body

Demo: chat app

Saw that SSE is getting turned on.

Is there a chat app example or in fact any examples yet ?

Feature: Honeypot Form Fields

The torque framework has some APIs for decoding form data. It might be useful to include support for honeypot fields, as described by Kent Dodds on his blog:

https://forms.epicweb.dev/06

Another useful thing you can do along with the honeypot field is to add a field that will allow you to determine when the form was generated. So if the form is submitted too quickly, you can be pretty confident that it's a bot.

The time stamp based field sounds particularly useful and very possible for SSR based applications.

The form API is located here:

https://github.com/tylermmorton/torque/blob/master/form.go

Rough outline of solution:

• Add ErrFormHoneypot
• Add API for declaring honeypot form fields on structs.
• Add check for honeypot fields in form decoder methods. Return ErrFormHoneypot
• Add documentation and provide guidance on API usage