These are chat archives for orbitjs/orbit.js

9th
Mar 2016
Dan Gebhardt
@dgeb
Mar 09 2016 21:02
@opsb I think the new Updatable interface came together well - orbitjs/orbit.js#271
I finished an initial implementation for JSONAPISource - and it simplified everything quite a bit
there's still some work tbd re: coalescing and diffing record-aware operations
but I hope that this work is enough to unblock your work on the coordinator / store
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:00
@dgeb just heading back home, looks like you've been busy again! Will review shortly.
Dan Gebhardt
@dgeb
Mar 09 2016 22:01
@opsb great - thanks in advance for reviewing
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:27
@dgeb so I can see why you’ve enforced single operation Transforms, they’re a practical constraint of the JSON API transport. We’ve touched on this before, but with the UX having to take a lowest common denominator approach the value of Transforms does become questionable.
Dan Gebhardt
@dgeb
Mar 09 2016 22:29
I am in the process of writing some more advanced code for coalescing transforms for jsonapi
so that multiple attributes and relationships can be updated together for instance
I know that doesn't get to the heart of your comment though
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:30
I suppose PATCH is the more general solution with JSON API?
Dan Gebhardt
@dgeb
Mar 09 2016 22:31
yes, PATCH is allowed for updating multiple aspects of a record
however, the broader solution is to support jsonapi-operations
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:32
Am I right in thinking that you could send multiple operations transactionally using PATCH?

however, the broader solution is to support jsonapi-operations

right

Dan Gebhardt
@dgeb
Mar 09 2016 22:32
so, unfortunately that's not available yet and will take some time
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:32
perhaps we could give people the option of degrading to non-transactional Transforms?
Dan Gebhardt
@dgeb
Mar 09 2016 22:33
we certainly could
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:33
that might cause more problems than it solves though :)
I suppose we need to think about the migration path here really, sounds like you’re working on covering a complete solution
Dan Gebhardt
@dgeb
Mar 09 2016 22:34
yeah, I am scared of half-complete "transactions"
but it's effectively what many apps do now
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:34
yeah, it is an error state really, no getting away from that
Dan Gebhardt
@dgeb
Mar 09 2016 22:34
right
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:35
ok, so I take it Transactions would be represented as many Transforms?
We’re currently using a single Transform, but that’s not really necessary
The Transaction is more for isolation than logical grouping of operations
Dan Gebhardt
@dgeb
Mar 09 2016 22:38
hmmm
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:39
could be an option on Transactions, but perhaps that’s fudging the issue
Dan Gebhardt
@dgeb
Mar 09 2016 22:41
I don't want the limitations of the JSONAPISource to limit the possibilities of the architecture
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:41
we have to fit orbit to the capabilities of the integrations though
Dan Gebhardt
@dgeb
Mar 09 2016 22:42
yes, so the question is where to cleanly allow for compromise based upon a source's capabilities
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:42
hmm
Dan Gebhardt
@dgeb
Mar 09 2016 22:43
let's say that a form creates a planet and two moons and relationships between them
and the planet creation succeeds but nothing else does
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:44
that decision can only be made on a case by case basis
Dan Gebhardt
@dgeb
Mar 09 2016 22:44
sure
I want to expose the right decision points though
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:45
sure
So there’s two decisions that can potentially be made
1) Transactions => single transform/multiple transforms
2) source.update(transform) => allow partial / require full
Dan Gebhardt
@dgeb
Mar 09 2016 22:48
for (1), I think we want a single transform to represent the concept
let's say that we allow multiple ajax calls to be made in a single call to source.update
from the user's perspective, they expect the transform to succeed / fail transactionally (fully)
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:49
If we think in terms of constraints, the developer can choose how to constrain behaviour at the Source, Transactions then give the developer the decision over how to work within that constraint.
i.e. the global constraints are defined by the lowest common denominator of all of the Sources that need to make updates.
The Transaction would then allow a developer to tune how the application fits into those constraints
Dan Gebhardt
@dgeb
Mar 09 2016 22:51
do you mean Transaction or Transform?
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:52
I mean Transaction in terms of how the developer interacts with the ember-orbit api for instance, Transform is the transport that expresses what they’ve asked for (single Transform vs the more liberal multiple Transforms)
Dan Gebhardt
@dgeb
Mar 09 2016 22:53
ok, they're very closely related, sure
we can allow tuning at any level here I suppose
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:54
I suppose the question is, does it ever make sense to have a Transaction that only partially completes?

we can allow tuning at any level here I suppose

this might be the right place to start

we can tighten around best practices when we have some experience
Dan Gebhardt
@dgeb
Mar 09 2016 22:54
yes
say we allow JSONAPISource to be permissive and perform multiple ajax calls within a single update (as an option)
the server may pair this situation with SSE or a socket to send partial updates that completed
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:55
I think restrictive defaults would make sense at least
Dan Gebhardt
@dgeb
Mar 09 2016 22:55
I agree
I can see a lot of trouble with the above scenario ^
because the planet that's created will be sent to the user over another channel
and will appear in the list of planets even though the user's been presented with an error on submitting (in the pessimistic case)
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:56
In the streaming scenario, Transactions can be used as a broad type of throttling

and will appear in the list of planets even though the user's been presented with an error on submitting (in the pessimistic case)

you could indicate that the planet was saved correctly though

i.e. it is possible to indicate partial success
Dan Gebhardt
@dgeb
Mar 09 2016 22:58
yes, if multiple transforms are used
Oliver Searle-Barnes
@opsb
Mar 09 2016 22:58
I admit the scenario seems a bit of a stretch
I think we need some experience to make this call
Dan Gebhardt
@dgeb
Mar 09 2016 22:59
well, we can provide options to allow for experimentation
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:00
yes, that does seem like the way forwards for now
our model already allows the decision to be made at both points
Dan Gebhardt
@dgeb
Mar 09 2016 23:01
right
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:01
bringing sql semantics to the client eh, who new there’d be so much work involved ;)
Dan Gebhardt
@dgeb
Mar 09 2016 23:02
ha!
it is a hard problem to generalize
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:02
it’s obviously driving your standards efforts anyway
Dan Gebhardt
@dgeb
Mar 09 2016 23:02
that's true
so, for now, should we create an option for the JSONAPISource to allow multiple requests to complete a transform?
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:03
it is something that everyone is reaching for, I know the rethinkdb guys are looking at it
Dan Gebhardt
@dgeb
Mar 09 2016 23:03
yeah
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:03
yeah, that seems good for now at least
hopefully later we’ll be able to just throw an error saying you should switch your server api to use option X :)
Dan Gebhardt
@dgeb
Mar 09 2016 23:04
indeed :)
alright, so this work is all additional to that PR
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:05
right, well, path of least resistance for now I think
we can mix these things in at any point
Dan Gebhardt
@dgeb
Mar 09 2016 23:05
yes
I will continue working on coalescing ops, specific to the jsonapi source
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:06
I’m keen to get a demo app :)
ok
I’ll continue through this PR
Dan Gebhardt
@dgeb
Mar 09 2016 23:06

I’m keen to get a demo app

same!

ok thanks for the review
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:06
extracting the transforms is nice
Dan Gebhardt
@dgeb
Mar 09 2016 23:07
yeah, all the layers are cleaning up well I think
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:07
I’m starting to see why communications teams always end up with functional systems e.g. erlang
Dan Gebhardt
@dgeb
Mar 09 2016 23:07
:)
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:08
Barcelona has it’s first phoenix meetup next week :)
I’m keen to do an orbit integration (another one for the list, maybe I can persuade someone else to do it)
Dan Gebhardt
@dgeb
Mar 09 2016 23:08
nice! have you been using elixir / phoenix?
Chris McCord works closeby down in Boston at Dockyard now
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:09
no, but it sounds like the love child of rails and erlang
Dan Gebhardt
@dgeb
Mar 09 2016 23:09
yep, pretty much
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:09
which sounds great!
Dan Gebhardt
@dgeb
Mar 09 2016 23:09
:)
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:09
I enjoyed using erlang
Dan Gebhardt
@dgeb
Mar 09 2016 23:09
it's on my list
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:09
I was a huge fan of prolog and erlang is the closest I’ve seen in a practical guise
Dan Gebhardt
@dgeb
Mar 09 2016 23:11
well, you'll probably have a good perspective on elixir then
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:11
yeah, hopefully it’s where some of my favourite features get pulled together
always missed pattern matching in ruby
Dan Gebhardt
@dgeb
Mar 09 2016 23:12
:+1:
got to break for a few - will be back later
feel free to merge the PR or point out my mistakes :P
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:14
So Source is feeling a little thin on the ground...
Dan Gebhardt
@dgeb
Mar 09 2016 23:14
yeah, pretty deliberately
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:14
is it worth keeping?
Dan Gebhardt
@dgeb
Mar 09 2016 23:14
a Source could just be Queryable
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:14
sure
Could be useful for tooling I suppose
Dan Gebhardt
@dgeb
Mar 09 2016 23:15
yeah - let's keep it for now - nothing wrong with a base class for such a core concept
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:16
sure, I’m playing devils advocate
Dan Gebhardt
@dgeb
Mar 09 2016 23:16
fair enough
I was pretty ruthless removing code myself
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:17
yeah, that’s good
cathartic ;)
Dan Gebhardt
@dgeb
Mar 09 2016 23:17
after all this time, truly
alright ... better run ... ttys!
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:18
k, ttys
Oliver Searle-Barnes
@opsb
Mar 09 2016 23:27
PR LGTM. Obviously there’s lots of wip WRT to tests/coallesceOperations etc. but I don’t see any blockers and it gives me enough to work with.
Only mention was to replace usage of the depracated QUnit start/stop
I went ahead and merged anyway