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

Option to disable the Fetch behavior of rendering raw data into HTML #2177

Closed
ulvidamirli opened this issue Aug 12, 2021 · 13 comments
Closed

Comments

@ulvidamirli
Copy link

ulvidamirli commented Aug 12, 2021

Describe the problem

As in official document:

When fetch runs on the server, the resulting response will be serialized and inlined into the rendered HTML.

This behavior intercepts with my reason to use SSR on SvelteKit.

Because I don't want my server-side JSON response to be accessible by the client (other developers) as a raw JSON. I do it for preventing possible parsing of raw JSON data. And also to avoid visibility of some app-specific data (they are not security-related data).

Describe the proposed solution

I would like to have an option to disable rendering JSON as raw data into HTML. Just only rendering it to the template.

Alternatives considered

No response

Importance

i cannot use SvelteKit without it

Additional Information

No response

@benmccann
Copy link
Member

You could turn off client-side rendering. As long as your API is accessible on the web they could just hit your API directly to get the data, so taking it out of the page might not help you a lot

@benmccann
Copy link
Member

Or, alternatively, if you turned off ssr I think that might stop it from including it in the page. (I haven't tested)

@ulvidamirli
Copy link
Author

I'm trying to solve this issue by making database queries from the .js file and then import it with the load function inside the module context. SSR is valuable for me, but I don't want anybody to see the raw JSON. Do you think that would work? I can't get it to work, though because of errors. Need some help

@benmccann
Copy link
Member

load cannot make database queries. it must call an HTTP endpoint

@ulvidamirli
Copy link
Author

ulvidamirli commented Aug 12, 2021

You could turn off client-side rendering.

I tested it, works. But other functionalities don't work which are very important for the page.

load cannot make database queries. it must call an HTTP endpoint

Can I just make a query with a _query.js file and export as a JSON object, and then import this exported JSON from the load function?

@benmccann
Copy link
Member

No. load runs on the client. It can't access your database no matter what you name your files.

You could also probably prerender your page so that the database is queried at build time and load doesn't need to run in the browser

@ulvidamirli
Copy link
Author

ulvidamirli commented Aug 13, 2021

It would be better to have partial hydration for these types of scenarios, I think. For example, another type of load function that gives us a chance to make the queries or API calls on the server.

You could also probably prerender your page so that the database is queried at build time and load doesn't need to run in the browser

By doing this, the pages won't update when I edit data on the database right? That's a disadvantage for me as well.

@rmunn
Copy link
Contributor

rmunn commented Aug 17, 2021

Because I don't want my server-side JSON response to be accessible by the client (other developers) as a raw JSON. I do it for preventing possible parsing of raw JSON data. And also to avoid visibility of some app-specific data (they are not security-related data).

Are you somehow blocking or disabling the Network tab of the browser developer tools? Because otherwise, your clients (who will definitely know about the dev tools since they're other developers) will be able to see the JSON response from your server to their browser anyway, whether or not it's been included in the HTML of the page, simply by using the Network tab of the dev tools.

And since as far as I know there's no way for a web page to disable the client's access to the developer tools (if you know a way, I'd be interested to learn it), what you're trying to achieve (hiding the server's JSON response from your customers) is impossible. So in my opinion, it's not worth adding extra complexity to Svelte-Kit's fetch function for this use case, because it wouldn't actually get you what you want anyway.

@ulvidamirli
Copy link
Author

ulvidamirli commented Aug 17, 2021

@rmunn, Sorry for my poor explanation. The thing I want is simply to get access to DB (for making queries) from the load function. And it will give me a chance to avoid using JSON API.

By doing that, I think the raw JSON (since I won't use JSON API but only query results) won't be accessible to the clients/devs from the network tab or anywhere else. And SvelteKit will output HTML with data already rendered server-side.

In SvelteKit I didn't succeed to do this without turning off hydration. And without hydration, other functionalities in the component won't work. I think there may be the type of specific load function which 100% will work on the server-side without hydration. Which is much more like a traditional server-side rendering. And other hyrated stuff will work as before.

@benmccann
Copy link
Member

That's impossible. load runs in the browser. You can't access your database from the browser

@keehun
Copy link

keehun commented Jul 10, 2022

@benmccann I wonder if I could ask for what @ulvidamirli was asking for but in a slightly different way as I think there was a bit of miscommunication:

(Edit: after writing this comment, I read through a few other issues where partial hydration was discussed. Basically my long comment is a ➕1 vote for partial hydration. My particular use case—which is not performance based!—has not been mentioned, so I’ll keep my comment here.)

Here’s my use-case: I’m developing an application like an encyclopedia/dictionary where the content is fairly static and doesn’t need to be updated instantaneously. We will rebuild the site at a regular cadence. I do have other parts of the page (like search/autocomplete/etc) that benefits a lot from Svelte’s conveniences. The API doesn’t need to be a secret or hidden, but as you can see, there’s a lot of reduction in traffic we can achieve if the API is only hit during build-time.

I’ve tried the trick where you import browser from $app/env and short circuit load() when in the browser. While it works as I expect, it throws errors into console as the page attempts to hydrate and is missing that data it would have fetched in the load() call.

Right now, my solution is to run a python script that is executed before sveltekit build which will pull all the JSON files from the API. These files get put in the static directory. In essence these files serve as the API “server” so visitors will never actually hit my API services. This is working well for now, but I would like to see if I can skip this middle step.

The only other way I can imagine implementing this is by utilizing something like jinja2 or another “code generation” tool that would read the API and actually generate Svelte code which then would be built by Svelte.

Both of these solutions fall far from the tree of what I would consider a good, long-term solution. SvelteKit and pre-rendering already does everything I want except for that “hydrate everything again in the browser”. So as soon as I get a lever where I can specify what doesn’t need to be hydrated again in the browser, I would be golden. Perhaps similar to what Deno’s Fresh is calling “islands” which are separate files of code that denote what needs to be hydrated in the browser. Basically, component-level configuration to enable or disable hydrating. Right now, it seems like it’s either the entire page or the whole site or nothing.

Thank you for your time.

@benmccann
Copy link
Member

@keehun you're asking for partial hydration. There's a ticket for that here: #1390

@keehun
Copy link

keehun commented Jul 10, 2022

Yes, thanks! I edited my comment to refer to that as I was reading that thread while you were reading my comment I think. Thanks!

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

4 participants