Is ssr supported in apps deployed on ic?

Developers
1

How can SSR (Server-Side Rendering) be implemented in applications running on the Internet Computer, and is it possible to incorporate SSR logic into frontend applications deployed on the Internet Computer platform?

2

It’s possible, but not really a supported use case for now. @kpeacock implemented Motoko Server, see this forum post, but it’s still in a proof-of-concept stage AFAIU

3

still i think its restricted , as i am trying to deploy the leptos app , and axum and other related dependencies causing errors.
i am trying to create a trunk build inside ssr folder , which is used in the dfx.json file but i am not able to create the build.

i get this error:
error: Only features sync,macros,io-util,rt,time are supported on wasm.
→ /Users/veerpratap/.cargo/registry/src/index.crates.io-6f17d22bba15001f/tokio-1.40.0/src/lib.rs:473:1
|
473 | compile_error!(“Only features sync,macros,io-util,rt,time are supported on wasm.”);

1 Like
4

Yeah, you can’t run a tokio server or other typical SSR setups on ICP. You need something like Kai’s Motoko Server

5

so like i want to understand a bit better m
icp supports ssr but in its won way when we fetch data from it ,
we cant implement our ssr logic when deploying on it?

6

SSR, meaning server side rendered JavaScript is not possible on the IC yet. We need support for a full JavaScript runtime with all browser APIs polyfilled.

With Motoko server, you can generate some dynamic HTML, CSS or JS files to serve to the browser, but you cannot execute them on the server, which is what most SSR frameworks do these days.

The closest you will get is SSG at build time.

1 Like
7

Fleek is the most promising service that comes close to realizing frontend SSR with decentralized systems.

While SSR is not currently supported there either, they have shown a more explicit intention to support it than IC, and since Docker images are supported there, the workaround for developers will be less burdensome, even for non-JS frameworks like Leptos.

8

You are going to run into a couple of issues here.

  1. Certifying your responses - Gateways try to make sure your responses are certified by the canister. I know this has changed a bit, but I’m pretty sure you’ll still get non-certification errors if you try to serve a web resource not from the canister_id.raw.ic0.app endpoint. Origyn did a custom proxy at one point to get around this, but when you do that you open up users to a man-in-the-middle attack. Because canisters have to sign a certificate with your dynamic content you are looking at extended latency and likely having to upgrade each request to go through the http_request_update pathway with a redirect to the certified page. This isn’t going to be a great experience.

  2. The newly surfaced subnet issue will make this very interesting. Right now queries(serving most web resources) is a query op and doesn’t really get affected by a bob/yral subnet attack, but once you have to dynamically generate and certify the content your requests become updates and will require you to increase your compute allocation significantly to experience anything close to acceptable web experience(likely close to 100 if you want 2 - 4 second response) which is a commitment of ~$3,500 a month.

We would need some kind of query-only certification process to make it realistic. In the past I’ve thought a good bit about this, but haven’t done much work on it recently.

See Certification v2 Questions - #2 by NathanosDev for more info.

And this bounty which is still open: Assigned: BNT-13 - Motoko Certified Assets Canister - #3 by domwoe