Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

projections API #22

Open
the-mikedavis opened this issue Apr 20, 2021 · 4 comments
Open

projections API #22

the-mikedavis opened this issue Apr 20, 2021 · 4 comments

Comments

@the-mikedavis
Copy link
Collaborator

the-mikedavis commented Apr 20, 2021

connects #7

the projections API is a bit cryptic for me

I've been able to hobble my way through the rest of the protos pretty much just on sheer experimentation and checking with the other client libraries. The projections API is a bit out there and I'm not really sure what the difference is between a continuous, a transient, and a one-time projection (just to begin with). The Event Store team is supposedly in a major documentation refactor, so I'm gonna put this one on hold and go get the more familiar persistent subscriptions API.

@the-mikedavis
Copy link
Collaborator Author

looks like the eventstore team threw up some docs on the grpc projections API https://developers.eventstore.com/clients/grpc/projections/ just yesterday 🚀

@TiteiKo
Copy link

TiteiKo commented Sep 14, 2022

Hi there, have you been able to look at the new documentation and understand projections better yet?

(untold underlying question: any idea how complex and time consuming implementing them would be?)

@the-mikedavis
Copy link
Collaborator Author

I haven't looked into it myself. We drive projections through the HTTP API since the HTTP API is easier to integrate with infrastructure-as-code tools (terraform, ansible, etc.), so we don't have a good use-case for using projections via Elixir.

With the addition of subscriptions/reads of the $all stream and filters though, projections are no longer very useful to us in general. They cause some write-amplification when you have many of them which can be avoided by with $all+filters.

I would prefer that the projections API code is added by someone with a use-case for it. It should be somewhat easy: Spear just needs a nice wrapper for the projection RPCs in projections.proto:

  • new functions in lib/spear.ex
  • wrappers for those new functions in lib/spear/client.ex
  • some test cases

#49 could be used as a good example.

The gRPC code already exists (https://github.com/NFIBrokerage/spear/blob/main/lib/spear/records/projections.ex) so you could use projections now with a combination of Spear.Records.Projections macros and Spear.request/5 if you need.

@TiteiKo
Copy link

TiteiKo commented Sep 18, 2022

I didn't know that $all + filters was as, if not more, viable than projections. I'll keep it simple and make the most out of the existing tools.

Thank you for taking the time to answer ✨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants