Add operations to document meta

[sandreae]

Adds a field called operations to DocumentMeta GraphQL type which returns a list of all operations contained within the document view being returned. The returned items are not complete operations, instead a new GraphQL type OperationMeta is used. This contains id, publicKey and previous fields.

📋 Checklist

• [x] Add tests that cover your changes
• [x] Add this PR to the Unreleased section in CHANGELOG.md
• [x] Link this PR to any issues it closes
• [x] New files contain a SPDX license header

[codecov[bot]]

Codecov Report

Merging #255 (ffb056e) into main (a82cd4a) will increase coverage by 0.17%. The diff coverage is 87.50%.

@@            Coverage Diff             @@
##             main     #255      +/-   ##
==========================================
+ Coverage   93.99%   94.17%   +0.17%     
==========================================
  Files          59       61       +2     
  Lines        4928     5011      +83     
==========================================
+ Hits         4632     4719      +87     
+ Misses        296      292       -4     

Impacted Files	Coverage Δ
...quadoggo/src/graphql/client/dynamic_types/tests.rs	100.00% <ø> (ø)
...uadoggo/src/graphql/scalars/operation_id_scalar.rs	28.57% <28.57%> (ø)
aquadoggo/src/graphql/client/dynamic_query.rs	92.02% <97.72%> (+0.83%)	:arrow_up:
.../src/graphql/client/dynamic_types/document_meta.rs	92.53% <100.00%> (+11.58%)	:arrow_up:
.../src/graphql/client/static_types/operation_meta.rs	100.00% <100.00%> (ø)
aquadoggo/src/graphql/scalars/public_key_scalar.rs	92.85% <0.00%> (+28.57%)	:arrow_up:
...quadoggo/src/graphql/scalars/document_id_scalar.rs	78.57% <0.00%> (+28.57%)	:arrow_up:
...ggo/src/graphql/scalars/document_view_id_scalar.rs	78.57% <0.00%> (+28.57%)	:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[adzialocha]

This adds a new feature which is not specified yet, maybe we should discuss this first in an handbook issue?

[sandreae]

This adds a new feature which is not specified yet, maybe we should discuss this first in an handbook issue?

Yeh, I'm happy to discuss this with an eye on specification.

Do you feel that we shouldn't have anything in aquadoggo which isn't in the p2panda specification? My feeling with this PR is that it is a nice additional feature which the aquadoggo node implementation would offer which wasn't in the specification. In this case, GraphQL makes this very easy for us :+1: (this query only runs if you specify the field explicitly).

I'd be quite happy with this being a pattern we explore for features which have no side-effects like this.

What do you think @adzialocha @cafca ?

[adzialocha]

I like that we aim at doing a "strict reference" implementation of the p2panda spec, basically meaning that everything we specified we build or vice versa. Also it roughly follows currently what we defined in the contribution guidelines, and maybe now with the spec solidifying we shouldn't make an exception for us. Not following the spec is something for the wider community and their independent implementations 😅

For really experimental new things they can live in branches until they get merged?

These are just my initial thought, we haven't talked about it yet and I don't want to make it harder than it is, so let's have a meeting maybe and update the guideline depending on what comes out of it?

(I like this feature btw, just wanted to raise the flag, it's our first excercise in adding new features, soon having a stable spec and contribution guidelines we never looked at 😊).

[adzialocha]

More ideas for bringing in "experimental" features into main:

Move it behind Rust feature flag experimental-x or specifically when it is in GraphQL API introduce a __experimental key?

[sandreae]

Nice, I like all these suggestions. I think there should be a way to introduce new features which are not specified yet, there is value in iterating on ideas in order to understand what we eventually want to specify, but also agree that having a very "strict to spec" implementation is a worthwhile goal. Let's decide what pattern we want to follow and put it in the contributor guidelines :+1:

[cafca]

All of what you said here makes a lot of sense! I don't really have anything meaningful to add haha

[sandreae]

I asked the p4p gang how they approach spec making and simultaneous implementation. Similar thoughts to us in general, having a strict reference implementation is valuable for developer comprehension of the spec and core protocol features, being able to add useful features (particularly on query endpoints) is valuable for improving user experience at low developer cost.

One nice suggestion was to separate any "extra" features we might implement into their own module. So when reading code it is very clear what is core and what is extra. This would work well in conjunction with both your suggestions for putting features behind flags @adzialocha 👍

[sandreae]

The query api implementation has changed so much that this code is no longer useful so I'm going to close this PR.