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

feat: API routes that return only the data specified #757

Closed
benwis opened this issue Mar 27, 2023 · 5 comments
Closed

feat: API routes that return only the data specified #757

benwis opened this issue Mar 27, 2023 · 5 comments
Labels
enhancement New feature or request Router

Comments

@benwis
Copy link
Contributor

benwis commented Mar 27, 2023

Routes that return only the content returned from the route. Could be an RSS feed or JSON or maybe even something else.

@gbj gbj added enhancement New feature or request Router labels Mar 28, 2023
@gbj
Copy link
Collaborator

gbj commented Mar 28, 2023

Thinking about this: I think it's a great idea, and I'm wondering what a good API for it would be.

<ApiRoute
  path="/rss.xml"
  response=|cx| {
    // so far, so good, right?
  }
/>

What's the type of response though, I wonder? Because we can definitely let it be something like

pub fn ApiRoute<P, R, Fut>(
  cx: Scope,
  path: P,
  response: R
) -> impl IntoView
where
  P: std::fmt::Display,
  R: Fn(Scope) -> Fut,
  Fut: Future<Output = ???>
{}

So that API route response functions can be async. And then ??? here could be, presumably, Response<Body> for Axum or HttpResponse for Actix or whatever for another framework. So basically an API route response would be an async function that takes a Scope and returns a Response. Taking Scope lets it have access to the Request. I'm not sure how we type the response in the router though.

Ooh or maybe the <ApiRoute/> component is provided by the integrations? Hm. Have to think a little more, but does that outline sound right?

@benwis
Copy link
Contributor Author

benwis commented Mar 28, 2023

I like it! I agree taking scope is a good thing. I'm not sure which things impl IntoView, but I think that's workable. Actually maybe the return type of response would best be derived from either Axum or Actix? For axum, that might be impl IntoResponse, which should cover a wide variety of things.

@gbj
Copy link
Collaborator

gbj commented May 4, 2023

So I finally got around to doing some work on this. Initially my idea was to be able to basically use any handler. I've built most of the infrastructure but the problem is that basically the server-only types can't compile to WASM, at least for Actix, so the <Api/> component I was envisioning going in the router can't really work. On the other hand, API routes can just be added as ordinary route handlers in your main.rs.

Another possibility would be to restrict things here such that an "API route" basically means a route that returns data instead of a view: it's some async function, which doesn't necessarily have access to the server types (but which could call a server function in its body, as it will only run on the server anyway) that renders something to a type that implements Serialize and we return some JSON.

Is the latter useful enough that you'd want it for an RSS feed or something, as opposed to just adding an API route in main.rs? (Or, for example, I'm working on DOCX export)

EDIT: Wait lol "return a type that implements Serialize and we export JSON" doesn't work for RSS or DOCX hahahaha. I think that I think that just using regular routes on a server is the way to go here, unless we use a proc macro or something to totally gate these API routes from the WASM compilation.

@benwis
Copy link
Contributor Author

benwis commented May 18, 2023

It's a tricky thing, for the blog example the idea of Posts, a Post list, and DB fetching are all occurring in Leptos, not in Axum. That's the kind of stuff you might want to return in an RSS feed. So I could either duplicate all that logic above Leptos.

Now that I consider it, since we have GET requests for server functions now, perhaps the answer is to open up the response types for them a bit.

For RSS feeds, we'd need XML response types. For binary data that we don't want to encode(image payloads and such), perhaps a Bytes one?

@gbj
Copy link
Collaborator

gbj commented Jan 20, 2024

Now that I consider it, since we have GET requests for server functions now, perhaps the answer is to open up the response types for them a bit.

For RSS feeds, we'd need XML response types. For binary data that we don't want to encode(image payloads and such), perhaps a Bytes one?

I'm going to declare “mission accomplished” on this one as of #2158: it is possible, for example, to create an RSS feed using a server function with

  1. a specified endpoint = , and
  2. a custom encoding

@gbj gbj closed this as completed Jan 20, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request Router
Projects
None yet
Development

No branches or pull requests

2 participants