Implement a reasonably complex app, to demo and explain important concepts

[mstade]

As much fun as nap is, we aren't doing a good job explaining why the resourceful architecture is a Good Thing™. It's tricky to explain as well, and because there are multiple concerns – often times cross cutting – that nap tries to tackle it's tempting to compartmentalize them and so it often becomes an almost academic discussion, for lack of a better description. There's no 10-second soundbite that really captures the essence of it, and "organizing your application to adhere to the six contraints of REST" is, well, not very palatable.

To that end, one idea is to implement a reasonably complex application – something you might find in the real world, so no to-do app – which can then be used as sort of a reference project to discuss various different subject matters. Such topics might include the simplistic view of things, like "how do I render a view?" or "how do I get data?"; to more complex topics like "what's content negotiation?" or "how do I drive a client using hypermedia?"

Its not entirely clear to me what that application might be, but we should probably take this opportunity to come up with some requirements for it and maybe we can work our way backwards from there to figure out what a suitable fit might be. I do think it's important that it's an actual real-world thing with some purpose, and not just a contrived hello-world style example. It'd also be good to pick something that's not too esoteric, so that there are good products out there that we can be inspired by and not be spending lots of time figuring out UX or features.

Some random ideas:

• A chat application, much like Slack or HipChat. Reasonably complex, covers a lot of topics and not least tackles the problem of realtime streaming. Also offers up an opportunity to demo a server side aspect. (See #15.)
• Email. Again reasonably complex, and kind of similar to chat albeit perhaps less realtime and sort of less social. Plenty of
• A game of some kind. Games often lend themselves very well to the notion of splitting things up into resources, and can also present good opportunities to discuss hypermedia. Consider a small puzzle/adventure game, where interactions and affordances are all hypermedia driven, such that the actual application becomes small and is driven by the data. Perhaps difficult to scope and come up with ideas for though, unless we blatantly steal some simple game. (Like LIFE or Jones in the Fast Lane for example.)

[mstade]

It might help to identify the heavy hitters in terms of concepts and principles we want to highlight (for now at least, this can be an expanding set,) and possibly work it out backwards from there.

[aaronhaines]

I like the 'Slack' idea. It covers lot's of qualitatively different types of content - messages, profiles, documents etc - with their associated views, which would be useful in conveying the idea that these things can come from different sources but can be composed together

[cristiano-belloni]

A cool chat application could be done with WebRTC Data Channels. The only server we'd need in that case would be a generic WebRTC signalling channel server (there are tons of open source ones). Commuications would be P2P after the first handshake. On the other hand, this would restrict browser choice to the FF, Opera and Chrome.

[aaronhaines]

Not a bad thing : )

[mstade]

I don't think browser compatibility for the example app is that important, but I do think we should aim for a server side component because that affords us the opportunity to also use nap server side. If we should want to avoid server side altogether we may as well just make an IRC client.

Chat's a pretty good everybody-gets-it app, it's the kind of app that has a very broad target audience. From a technical standpoint I agree with @aaronhaines (who of course has unique experience building chat using this kind of design! ;o)) that it showcases a number of topics that I think we'd like to discuss, and is something we can refer back to from several different cookbook style articles.

[cristiano-belloni]

Server side for isomorphism, you mean? I guess we will still have it. We're going to need a service that serves (or isomorphically builds) the pages and a (separate) service that implements the chat system.

The only difference between server-side chat and WebRTC chat is that with the first one you tipically connect from the clientside via websockets, send the server a message and then the server pushes it to the other participants in the room, while the second uses websockets to start up a p2p connection, then the clients send messages directly one to each other.

If we don't want to use websockets, we can use the more awkward SSE, which is polyfilled pretty much everywhere. Also, if we want large numbers of participants in the same room, we should not use WebRTC.

@mstade: out of curiosity, how is an IRC client serverless?

[mstade]

Not just for rendering, but actually organizing even the server side app using nap. Maybe not an overly important goal, but I think it's worthwhile to show that a resource oriented design isn't a front end-only thing.

IRC isn't serverless, but there are so many servers already running that we'd be able to just connect to freenode or wherever. My point is that doing a WebRTC thing would make the server side component so small (which is cool) that wrapping nap around it would just be overkill (less cool.) I think it'd be a whole lot of fun doing a p2p thing, just that if we also want to exhibit how versatile the resource oriented design can be then we shouldn't shy away from a reasonably complex server side component as well.

If we only want to focus on front end, then I'd say it probably makes more sense to do a client-only thing and leverage something like IRC for which infrastructure already exists. I suppose you'd need an HTTP proxy to set up the connection to the IRC server and relay messages back and forth, but I'd be surprised if something like that isn't already freely available.

I think we should do a server side thing though, simply for the reason of showing the versatility of the design, and not just for rendering things client side or sharing code. I don't much care what the transport mechanism for messages is, whether it's sockets or SSE or polling or carrier pigeons. In fact, it might even be useful to showcase multiple variants!

[cristiano-belloni]

Ah, ok, i understand. That's an ambitious and interesting goal. What would view resources on the server return though? I guess snippets of HTML that then the client has to hydrate?

[mstade]

That depends on the Accept header; presumably resources communication on the server side would use media types that makes sense there, JSON being a likely candidate. A client asking a server for application/x.nap.view could get interesting, since that is essentially just javascript that operates on a node but you'd have to serialize it, which ties in somewhat with #12. Frankly, I think application/x.nap.view is an anti-pattern and should probably be retired in favor of something like the idea I posted in that application view trickery gist some time ago.

I don't see much difference in resources communicating client side or server side, it's all just application logic and requests should be fulfilled regardless of where they originate. What gets interesting really is what you do when you have to cross boundaries, like network or application domains (consider postMessage between frames, for instance.) Ideally, as a resource or consumer of a resource, this would be entirely hidden away from you such that you just don't know whether things are being served in-memory or across a network.

My apologies, I'm ranting now, but anyway I do think the idea of showing nap operating across boundaries is really valuable, and while I don't think you can (trivially and generically) do this with nap currently, I don't think it's necessarily that far away from happening.

[cristiano-belloni]

My apologies, I'm ranting now, but anyway I do think the idea of showing nap operating across boundaries is really valuable, and while I don't think you can (trivially and generically) do this with nap currently, I don't think it's necessarily that far away from happening.

No, I'm liking this :)

The Gist is mind-blowing. If the origin of the resources is effectivey "blackboxed" (i.e. the consumer of the resource doesn't have to know where the resource comes from) and the resources are universal (ie the same module can be indiscriminately required either on the server or on the client), then we have a system in which the physical topology of resources is only defined by the routing configuration, and that would be amazing.

[mstade]

[...] then we have a system in which the physical topology of resources is only defined by the routing configuration, and that would be amazing.

That, good Sir, is exactly what I mean – just that you described it approximately four million times better! :o)

[cristiano-belloni]

:cool: So, I agree, let's build an application which is exactly like that! :))