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

Isomorphic/universal operation #15

Open
mstade opened this issue Oct 8, 2015 · 0 comments
Open

Isomorphic/universal operation #15

mstade opened this issue Oct 8, 2015 · 0 comments

Comments

@mstade
Copy link
Member

mstade commented Oct 8, 2015

(Ahh the JS community and it's affinity to bike shed on anything, and terms in particular.)

On the call this afternoon we discussed isomorphic nap; that is, the ability to render things server side and then "pick up" on the client side. As I mentioned, I wrote up a gist on the topic of application views sent across network boundaries which is really a different topic but incidentally discusses the same kind of problems. For that gist, the main topic is how can you define application view without necessarily coming up with a whole new media type; but incidentally because of the virtues of hypermedia you can actually implement a kind of isomorphism by also linking to the function that produced the rendered result in the first place. Hey presto, you end up with some thing (in this case, a component) which can be pre-rendered server side so as to keep client side rendering quick (at the expense of some latency and potentially bandwidth) but also provide the necessary details to allow further operation to carry on client side.

I'm opening up this issue as a discussion piece, but also to offer some ideas of which the aforementioned gist is some food for thought.

Worth noting is the distinction between having something that can be executed both client and server side (javascript using node APIs might have troubles in a browser, for instance) versus something that can "continue on" client side but isn't quite the same code as running on the server. I think trying to aim for all code running everywhere is a bit dogmatic; but I finding ways that nap could help embed additional functionality (and indeed, data) that may or may not run universally is a worthwhile goal I think.

In the gist, I discuss using link headers, which is interesting and well supported and might work really well, but isn't great for performance necessarily. For that reason, we'd need to look into actually embedding things into the response. HTML has good support for this with script tags and what not, but not all representations are HTML, and I don't think it's a good idea to go down a route of wrapping all things in the one media type. Rather, I'd say it might be worth looking into multipart responses, whereby you actually respond not just with the one response, but multiple. In particular, I think [multipart/mixed](for things like embedding client side request handlers along with a resource representation) and [multipart/alternative](for multiple representations of the same thing) are interesting things to explore. Crucially, these are not novel technologies, and should hopefully be well supported in browsers, caches, proxies, etc.

Anyway, food for thought.

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

1 participant