get rid of unnecessary .json endpoints #323
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
…up with proper credentials
There was a problem hiding this comment.
I'm not sure if this is a good approach. This will will mean that on every invocation of the runtime we'll read all the files over and over again - I'm not sure if they are even part of the build output since they live in content and that likely isn't copied over.
| }); | ||
| } | ||
|
|
||
| if (dev && !client) { |
There was a problem hiding this comment.
I think we should keep this - if we open this repo up and people want to work on this locally, they will have no way of interact with saved REPL, we for sure don't want to give out credentials to everyone
There was a problem hiding this comment.
they can't load specific arbitrary REPLs but so what?
There was a problem hiding this comment.
Yeah this was something I added in sveltejs/sites#281, and I found it very useful for running the REPL locally with a modified version of the compiler to see whether a given change actually fixed someone's repro. It would be a shame to lose it.
If that means doing something hacky where the server load function needs to proxy to the corresponding internal endpoint on the real server and then decode that response so it can be re-encoded, so be it.
There was a problem hiding this comment.
But you just need the file contents, right? And you can easily get that from the hash now — just make a change to the repro in question (add a space then delete it, whatever) then copy the hash from the URL bar, and you can run the same thing locally
There was a problem hiding this comment.
Yeah, it's true that the hash-based REPL storage could also address this.
Previously, there were a couple of extra hurdles. The "file contents" could be plural files contents (each of which would have to be copied separately), but also refreshing the local REPL (to get another new version of the compiler as part of the feedback cycle) would result in the just-pasted REPL being lost and having to be re-pasted (including potentially re-generating multiple files, if the repro had them).
However if one can easily generate hash-based REPL URLs from DB ID-based REPL URLs, that does alleviate a lot of these problems, at least for repros that don't require features that are only available in DB ID-based REPLs.
In that vein, does it make sense to make the REPL enable those more sensitive features (and the skip the 'click to run' button) for hash-based REPLs when running in development mode?
There was a problem hiding this comment.
Yeah, very possibly (though we want to avoid dev/prod discrepancies where we can of course). I think we could file that under problems-for-future-us though
There was a problem hiding this comment.
I mean ... if it's just about leaving this code in, why not just undo the deletion and not have to worry about "enable/disable certain restrictions in certain places"?
There was a problem hiding this comment.
Because it requires us to expose an unnecessary endpoint
|
What if we put it behind a |
|
memoizing it won't help much in a serverless world. But yes, it would at least restrict it to only be loaded on playground routes. Is there a different angle we can take? Rather than generating a server route, we're generating some file during build/dev that is imported? AFAIK this is the way it works on the current svelte.dev site. |
True. But the real question is whether the deployment making an HTTP request for a prerendered JSON file is going to be faster than generating the same data on the machine where the request is being handled, and where the files already live. Seems unlikely, honestly |
|
Not sure I follow, SvelteKit recognizes fetches to itself so there's no network overhead. Update: scratch that I think it falls back to requesting from the network, maybe SvelteKit could get smarter here and handle this without a network jump as well (although this is somewhat of an edge case) |
|
SvelteKit does need to get smarter so that we can combine prerendered layouts with dynamic pages and vice versa, but that's likely a few months off |
|
closing as stale, we can revisit when we eventually implement PPR etc |
3 participants
WIP — there's a few places where we're getting data in
loadfunctions via a server route. This is a hangover from the days before serverloadfunctions, and is entirely unnecessary