TasteStack/TodoMVC-Server Consolidation

[kouphax]

As previously discussed on Twitter I think there may be merit in merging previous efforts in todomvc-server with this project.

Hoping this issue will act as a basis for the discussion.

Considerations

• I have started jotting down some ideas on a spec on the todomvc-server Wiki. Its far from complete but raises some questions I've had.
• I created an exemplar project for the TodoMVC client code (this could be added as a submodule to example servers). The code is the Backbone app without the Local Storage aspect. I notice it won't "fail" if the server returns a non 200 error and I wonder if we should refine the client project to handle such situations properly.
• I wanted to define a spec for how the servers API should behave when called in the various ways. This would then allow people to test their implementations (I also planned to write a small app that would test an implementations endpoint by giving it a URL - this would help people to ensure their app is valid against the spec)
• I have rolled in the option of various persistence layers. We could then build out a matrix of web frameworks against persistence for easy lookup. This would be useful to provide a complete stack for people who want to see how Node and Riak look together for example. I assume from the name TasteStack this may be something that you'd see value in as well? I realise, though, a Todo app isn't exactly the best fir for a lot of persistence mechanisms (e.g. why would you even bother with a graph DB?)
• I want to refine the pull-request process so that it includes enough information (at least a YAML config file) that can be used to build a reference/lookup site (similar to how MicroJS works I believe).
• I initially included a NoJS option - whereby people could submit an implementation of the TodoMVC app without having to use the client code/javascript & XHR (e.g. not an SPA - just a normal multi page client server CRUD app). Not convinced this would necessarily be aligned with this projects goals and I'm happy enough to leave it out.

Thats about all I can rattle off for now. Lets talk about this and hopefully come to an agreement on the next steps.

[addyosmani]

You raise a lot of interesting questions and I think we should definitely formalize the specification for these more full stack implementations. We should also, similar to TodoMVC think about organizing our folder structure to allow for multiple frameworks and stacks as time goes on.

Love the list of thoughts. This is a terrific effort and I'd like to ask if you're happy to drive (at least initially) TasteStack with our help. Interested? If so I'm happy to give you commit rights. We want this idea to succeed.

That you've started putting together a spec and demonstrated interest in pursuing this idea further is fantastic.

[addyosmani]

On your point about suitability of a Good app TasteJS itself is all about defining a more complex application that goes beyond TodoMVC. It'll be multi view/CRUD/use author and so on. We'll share more info about this once we have more details refined.

[passy]

This is fantastic! 👍

A random thought: There are many different API paradigms apart from the RESTy approach you took like hypermedia APIs, XMLRPC, all sorts of new real-time communication channels and many more. Do you think those could have a place here or is this something that would go beyond the scope and would only complicate the comparison?

[kouphax]

@passy Personally speaking I'm open to explore non-resty things but it would certainly expand the scope of the project greatly :). I'm not sure it would necessarily hurt the comparison though (assuming it is handled in a structured/formal manner) because ultimately I'd still like to see, for example, a stack that streamed data into a MongoDB instance through Play! 2 via WebSockets using Backbone. Anyway we should certainly explore this more!

@addyosmani I'd love to help out, it was something that I'd been considering for a while now and decided to just go ahead and start spiking things out to see how they fitted. So yeah - happy to run with it.

[kouphax]

What I'll do for now is continue trying to define/refine a TodoMVC spec for a suitable stack, any work done in this area for TodoMVC will likely add value to any future endeavor anyway.

[passy]

Sgtm! :)

[sindresorhus]

Late to the party. But this sounds fantastic to me :D

I don't see why we couldn't explore other transports than REST, though REST should be the focus.

[ahmadnassri]

Hey guys,

a thought on a "TodoMVC" like showcase for APIs lead me here.
this conversation was a year ago, what direction is this going? cuz I'd like to pitch in!

[sindresorhus]

Nowhere yet. We've all been busy with other things.

What we need is someone to push this forward. We obviously haven't been able to.

Would you be interested?

[ahmadnassri]

yes, I would have to confirm my schedule for next couple of weeks so I can block off time to spend at least 48 hours to put some documentation / proposals together to move this forward.

I'm currently in SF so probably won't start till next week.

if anybody has any thoughts/documents/conversation archives to share it would be very helpful.

[sindresorhus]

if anybody has any thoughts/documents/conversation archives to share it would be very helpful.

tastejs/meta#9