Building nojs-first applications (and some thoughts about an isomorphic data layer)

[colemickens]

Hi. While I started out... a while ago... with html/js, I haven't really kept up with trends with recent trends. However, I've been really intrigued by Remix (https://remix.run) and the fact that it seems so possible to build applications that work for users that have javascript entirely disabled. However, it's not Rust and doesn't really handle data isomorphically the way I think might be possible.

I see that Percy supports SSR, but is it amendable to a SSR-first model? How does Percy's model compare to Remix's? Do you think it could take any inspiration from it?

Similarly, I'm curious if you have thoughts about isomorphic data access -- I'm wondering if something like BonsaiDB could be used to allow highly isomorphic Rust code that works for an application to be used in a SSR-only mode, or a thicker-client mode where the Rust codes executes templates on the client side with the same data-access layer hitting a partially replicated BonsaiDB stored offline in-browser.

(I've also been thinking about something like Percy, with some prescribed data layer, that could also then use that data layer to also subscribe to changes from the server, either via SSE or via BonsaiDB-native features). I think these features would make a pretty neat/unique full package, but maybe some of that should just live outside percy, if it's not too ambitious in general?

[chinedufn]

Hey Cole!

I'm not familiar with Remix or Bonsai DB, but my understanding is that what you're asking boils down to:

"Can Percy's data layer support an SSR-first data model".

If so, my answer is:

---

A design goal behind Percy is to make sure that it is easy for people to swap in whatever libraries / approaches that they like.

For example, I'm currently using a third-party crate called app-world for state management.
It's designed to make it easy to re-use all of my client side logic across multiple targets (browser, iOS, Android).

Of course that's pretty geared to my own needs. Other people will have completely different needs and priorities. They're free to use whatever state management library best suits them.

---

We definitely want it to be easy to use (almost) any state management approach alongside Percy's APIs.

You can provide any state you like to your routes, which should allow you to take advantage of any state management patterns that you like.

Approaches to state are currently under documented.

---

So yeah.. the features that you're bringing up sound like things that should live outside of Percy, but if I can add any documentation or answer any questions on how to best use them alongside Percy then please don't hesitate to let me know!

Especially if there's a specific pattern that you have in mind.