Caching - prefetch, other strategies

Has anybody implemented an approximation of Route prefetching in Next.js in their elm app (mostly likely through fetching data from backend ahead of time in a per page data cache)?

How do people feel about a per page data cache versus a cache of graphql responses across all pages keyed by graphql request versus a cache of normalized entity data keyed by entity id?

I like the per page data cache, because it seems simple to maintain and ensure cache hits, but I haven’t made up my mind yet.

I think elm-pages v3 (not sure about v2) might be able to do this. Not certain though.

Thanks. I found prefetching in elm-pages.

In my case, I am not interested in build time rendered or server rendered pages exactly, as the data will be dynamic per user, but something loosely inspired by prefetching of rendered pages.

Yeah, I think elm-pages v3 supports what you’re describing. @dillonkearns might be able to clarify though if I’m wrong.

Yes, elm-pages v2 and v3 both do prefetching of the route data on hover :+1: Uses the same strategy as NextJS (adds a preload tag so the browser can preload the data).

For what it’s worth, server-rendered pages are great for handling dynamic user-specific data. You’re welcome to choose your own preference of your favorite stack of course, but just wanted to clarify that the server-rendering strategy is designed to work with this kind of use case (elm-pages v3 can do server-rendered routes).


You can also handle routes on the server-side at request-time. The tradeoff is that rather than servering HTML and JSON files from the build step, your server will need to build the page when the user requests it.

I am a little confused on what it would produce exactly? (That is, is the server producing an html page or an html page with an elm app inside or something else? If there is an elm app inside how does it connect with the overall elm app?)

If you’re familiar with NextJS, it works just like that! elm-pages v3 (which is still in a pre-release phase at the moment) resolves data on the server and then passes that to the client. Under the hood it’s running two Elm apps, one that executes on a server to resolve data and server-render the initial HTML, and then one that hydrates in the browser. I’ll be sharing more about it in the coming weeks, but here’s an example you look at. This is TodoMVC but adapted to be full-stack. The app runs all of the DB persistence and manages login using magic link auth with cookie-based sessions.

There’s a live demo here:


My dream setup so far for data layer in csr/spa is (based on some discussions at work):

  • store pattern
  • Rest API with json:API standard and elm codegen or library to handle jsonapi conventions and defining rest request functions
  • Http caching
  • implement custom link component which triggers fetching page data into store on link hover

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.