search

GraftJS / graft

full-stack javascript through microservices
http://graft.io
MIT License
227 stars 15 forks source link

Implement AetherBoard example app #3

Closed AdrianRossouw closed 9 years ago

AdrianRossouw commented 10 years ago

It's kind of hard to make any decisions about what an API needs to look like, without at the very least trying to build something in the problem domain. (see: #2 )

So we've decided to build out a collaborative whiteboard app called AetherBoard.

The project itself is something I had been working on to be able to pull off in a node knockout situation, and is a new iteration of a project we did for the 2011 contest

We were going to aim for pseudocode at first, but after plotting out the spec, I think it's more feasible to build the pieces and then figure out how they want to be connected to each other.

We’re hoping to have a working demo by nodeconf, since @mcollina is doing a jschan presentation.

check out the issue queue and lend a hand if you are interested ?

https://github.com/AetherBoard/AetherBoard/issues

mcollina commented 10 years ago

What's the stuff we need to do? Let me throw in a list of pre-requirements for Aetherboard to happen:

  1. basic graft
  2. jschan websocket

Anything else? Can we crack down the bare minimum graft API for Aetherboard to work? This will drive #2.

AdrianRossouw commented 10 years ago

Check out the readme and the issue queue, it's quite well documented now.

I don't think they are pre-requirements, as in blockers to making the project happen.

Aetherboard is something I could have built without the existence of graft or jschan, but those libraries are going to make it a really elegant and straight forward solution.

Those are definitely the success criteria for the project though, although I'd add :

  1. a well documented and complete example application
  2. ... that is actually useful and can help show the value of graft
  3. the initial spec for what graft-compatible services could look like.
  4. research into what existing solutions there are for certain common problems.

So the order I see things best working is :

  1. put together enough of the ui so we can see things on screen (basically done)
  2. build out the handful of services needed to get something up on screen (in progress)
  3. wire things together with in-memory jschan (? optional?)
  4. figure out what the graft api looks like that uses these pieces correctly.
  5. build out the temporary websocket layer.
  6. the server side of this equation should be basically done already.
  7. add persistence ?
mcollina commented 10 years ago

Wiring things together with jsChan might be painful, I'd go straight to graft (it does routing!). Anything simple (even just on in-mem jschan) can help making aetherboard more graft-like from the very beginning.

I'll focus on the websocket layer and/or I can sketch a basic graft API.

AdrianRossouw commented 10 years ago

What I'm talking about is building like 2-4 of the services that I've laid out so far, and just using jschan to chain them together. For something that simple, i really don't think we'd need routing yet, right ?

My gut is also telling me that I would feel more comfortable building something a bit more substantial with jschan than the rexec example we ported from upstream. I mean, if jschan really does turn out to be painful to use, I would prefer us have the opportunity to fix the underlying issue, rather than layering an abstraction over it straight away.

While I think you are definitely the right person to be tackling the websocket stuff, I do also really want to see what you are thinking for the graft api. But maybe we should do that in a branch though, so we can iterate towards a working install that has lines showing up on the screen asap (even if not synced to any kind of server)

mcollina commented 10 years ago

What I'm talking about is building like 2-4 of the services that I've laid out so far, and just using jschan to chain them together. For something that simple, i really don't think we'd need routing yet, right?

Albeit being stream-oriented jsChan offers a very different API if compared to what we sketched in #2. However, you should be able to do what you want. Let me know if you need any fixes!

While I think you are definitely the right person to be tackling the websocket stuff, I do also really want to see what you are thinking for the graft api. But maybe we should do that in a branch though, so we can iterate towards a working install that has lines showing up on the screen asap (even if not synced to any kind of server)

I will focus on the websocket stuff for the time being. I'd code a quick-and-dirty msgpack over ws thing and then research the spdy-over-websocket theme. In this way we can move forward Aetherboard, and maybe switch later to the spdy thing.

mcollina commented 10 years ago

Just to let you know I've released jsChan v0.0.4 that includes websocket support (with the msgpack trick, incompatible with libchan).

AdrianRossouw commented 10 years ago

aetherboard is in progress now, and we've already gotten a few bug fixes / features out of this process. will update and close this issue when the project reaches some nominally stable state.

AdrianRossouw commented 9 years ago

this is as built out as it needed to be for this issue.

i've moved aetherboard out of it's own org, and will be managing issues on there.