search

leggetter / realtime101

Helping you choose the right real-time framework for your app by demonstrating the 101 of real-time apps: chat.
2 stars 0 forks source link

Real-time Chat App Spec #1

Open leggetter opened 9 years ago

leggetter commented 9 years ago

Purpose

To create a TodoMVC of realtime - a realtime chat application.

This should be achieved by building a common chat app specification and then anybody can contribute an example applications that adhere to the agreed specification using various realtime frameworks.

The goal for the moment is for the example application to be be HTML5 although there is potential for native apps in the future.

This is exactly how TodoMVC works and it's been amazingly useful to many developers when working out which JavaScript MVC framework fits their needs.. Hopefully we can do the same for realtime frameworks.

Basic proposed functionality

Although each framework may introduce it's own concepts, and we don't want to force the TodoMVC of realtime application to have add-on features that don't fit the application, it is worth having a list of common realtime framework features that the application could demonstrate:

We really want the focus of the application to be demonstrating how to use the API provided by the realtime framework. As such, common functionality like validation and parsing should be moved off to a library in a similar way as todomvc-common.

Front-end JavaScript Framework

TodoMVC demonstrates that there are a lot of front-end frameworks to choose from when building a front-end JS app. What JS framework are we going to choose for all realtime101 apps? Or should we stick to VanillaJS?

Realtime Frameworks with back-end requirements

Some frameworks will work without the need for a backend. Others will either require a backend e.g. Socket.IO or will suggest it's "best practice" for the framework. As such we should allow each example to also provide code for the back-end of the solution.

What about frameworks that offer support for different backend technologies?

paulbjensen commented 9 years ago

With regards to "A messages view to see existing messages and for new messages to appear in", is there a need to persist the messages in a database of some sort?

leggetter commented 9 years ago

With regards to "A messages view to see existing messages and for new messages to appear in", is there a need to persist the messages in a database of some sort?

Personally I think that'd be outside of the scope of the example. Although I accept that some frameworks offer persistence built-in.

Persistence could be an optional extra?

paulbjensen commented 9 years ago

Agreed, just wasn't sure if existing messages meant needing to store them.

johnman commented 9 years ago

Just a suggestion, i guess the goal is to keep things simple so multiple implementations can be shown, but if you wanted to show a bigger use case for realtime then maybe a trading example would be more appropriate. Although this may not be the end goal (simple example that can be demonstrated across many frameworks/languages)

leggetter commented 9 years ago

@paulbjensen - I'll update the initial text to clarify. Thanks for asking.

@johnman - chat is most definitely the 101 of realtime technologies and we are trying to create the TodoMVC of realtime. Although trading did help drive realtime web technologies forward through providing a clear route to revenue.

I'm also going to update the initial issue text to provide the type of functionality that we're trying to exercise within the realtime frameworks. Although trading provides a route to more advanced features like batching and throttling I think we can demonstrate those features - if required - using some more simple e.g. activity streams.

jparreira commented 9 years ago

TodoMVC demonstrates that there are a lot of front-end frameworks to choose from when building a >front-end JS app. What JS framework are we going to choose for all realtime101 apps? Or should we >stick to VanillaJS?

@leggetter I guess it will be difficult to have consensus on the JS framework to use. Maybe we should stick to VanillaJS as the least common denominator.

leggetter commented 9 years ago

@jparreira :+1:

3rd-Eden commented 9 years ago

frameworks

I don't think we even have to discuss or reach consensus about the JS framework to use if we just provide API's that need to receive a certain JS object to update a view. It's all about the real-time frameworks here, not how you should build a chat box. Those API's should be the same for all frameworks.

basics

I do think that for the basic functionality we should also provide a way for people to logout/disconnect from the chat.

expectations

As for the functionality expected from frameworks, I would suggest to make a distinction here between replying to an incoming connection and broadcasting a message to multiple connections.

backend vs services

It might make sense to just categorize the examples in to two groups, those that are build-upon third party services and those that can be hosted your self. But it might also make sense to just split it all up in to two different projects all together. One with a focus on "front" of the chat and one on the "back" of the chat.

codeplanner commented 9 years ago

First of all... I think this is a great idea since it will help spread knowledge about realtime frameworks. Hopefully we all want this regardless of what framework or tech we like the most.

Front-end

I would like to see one UI with vanilla-JS where all functionality is wrapped by a common "interface" for all operations. Then each framework implementation will just implement the logic for sending a message inside of the method. This way we can keep it clean and make it easier for the users to understand how each framework works.

If a realtime framework is dependent of (let's say) jQuery then that implementation will use jQuery in the wrapper

What I am really trying to say is that all implementations should look the same since that will make things easier for people looking at the samples. The only difference should be in the way communication is handled.

Back-end

If the framework is a SaaS and does not have a back-end that folder should just be empty (or missing). All other frameworks that do have a backend will provide the logic in the back-end folder. No need to have separate solutions for framework with or without backends IMHO.

As Phil mentions there might be frameworks that offer more than one backend tech. My suggestions is that if that is the case they can just structure each sample as

/Backend/Java
/Backend/CSharp
/Backend/PHP

Kind of like the idea that Arnout mention... That the sample for each framework is split up in two different projects. One for front-end and one for back-end. If there is no backend due to SaaS that folder is just empty or missing.

Security

Would be nice to have a "real" sign-in/sign-out functionality as Arnout mention, but maybe not in the first version? Or??? I think that the choice of security should be as transparent as possible so that all samples have as similar implementation

Features

If we want to show all features in all frameworks we might split it up in two parts. On for basic and one for advanced? Some frameworks will not have features that others have, so maybe it is fair to have one basic sample that all frameworks can provide samples for.

I think the samples will be awesome if we just iterate and add functionality as we go (but with a plan). I would like to see the basics first, maybe just:

and then later on add...