It would be great to have an UI

[suadev]

Hi,

I know Marten doesn't trying to be an another Eventstore but, Eventstore's web UI is very useful to trace transactions. No need to go DB and write t-sql to access the customer events. Just a little advice from me.

[oskardudycz]

@suadev could you provide some more details of the features that would be the most helpful for you in such UI?

[suadev]

Same like eventstore ui :)

• Querying streams and projections
• Accesing event detail as json format etc.

[oskardudycz]

@suadev I'll think about it. Probably that won't happen soon but I like this idea, so I might prepare some basic feature at some point.
I'll keep you posted.

[wastaz]

I also like this idea and Ive occasionally toyed with the idea of building something like this myself since I use the eventstore a lot and reading raw stuff in the db gets tiring after a while. However Id suggest that this type of UI should probably be a separate project and not part of the Marten "main" package.

[oskardudycz]

For sure it will end as the separate Nuget. I'll need to get confirmation from @jeremydmiller @mysticmind @jokokko if it might end in Marten repo, or in Jasper organisation.

I was thinking about similar way to plug UI as Swagger does. So plugging into the web app pipeline.

What do you think?

[gregoryyoung]

I got tagged into this. I believe the specific things being discussed are things like our correlation/causation id graphs

Which are pretty cool. This stuff can be implemented on top. Its more defining the required fields for it ($id, $correlationid, $causationid in our case). In general there is no/minimal support required in a storage system to support such things.

One thing worth discussing in building out such a tool is if it belongs in any eventstore implementation or if its better to standardize a way to get data ;-)

[oskardudycz]

@gregoryyoung thank you for the input. I was thinking about something that would be "swagger like" tool, for the first iteration basic (like querying, maybe some diagnostic). For sure not such sophisticated and cool as it is in EventStore right now ;)

I love the idea of collaboration on this topic or finding some common ground that both solutions could benefit. Do you have some suggestions or exact idea of that? I don't have enough experience in EventStore, so right now it's hard for me to guess, but for sure finding some common "protocol" it's possible.

I'm open for discussion and cooperation on that 👍

[gregoryyoung]

The protocol could even be plugable!

In terms of common protocols providing that the goal is primarily reading streams I would actually suggest taking a lead from ES and supporting ATOM. This is also a valuable integration point for many other things + a reasonably well standardized/known protocol. If you look at the ES implementation long polling is also reasonably easy to add. One nice bit here is the "real time updating" aspect that essentially comes for free.

I actually have a ton of command line etc tooling I would like to see available as well (including ability to pipe to display/graphing tools etc).

[oskardudycz]

That sound reasonable, I've step few times on this idea (maybe even in your writing/presentations ;) ).

This is something that I'd need to analyse a bit, as I haven't ATOM programmatically. I'll try to check this concept. If you have something to share that could be useful, then it'd be also great 👍

@jeremydmiller @mysticmind @jokokko your thoughts?

[gregoryyoung]

re something to share I can give you a promo code to see videos on it.

Can you dm me on twitter or email me? gregoryyoung1 at google email

[oskardudycz]

I just sent an email. On Twitter you have blocked DM (probably for persons that you're not following :) )

[gregoryyoung]

no email (its gmail) will be heading out for a bit this evening ...

[oskardudycz]

Yeah, I noticed that, but I ate 1... ;) I hope that now you got it.

[oskardudycz]

Here's summary of offline discussion with @gregoryyoung about the collaboration.

The main idea is to expose the ATOM feeds from Marten in the format that's currently designed and implemented in EventStore. Having that it'd be possible to have same protocol exposed and used through clients. Then besides benefit of having standarised approach it would give the better chances for further collaboration - eg. with UI that’d be able to read from both stores.

Also using ATOM bring benefits like:

• its an existing protocol
• there are clients written almost everywhere
• it scales quite well

I think that providing Atom support would be good option as separate nuget package and delivering first naive beta version that can be used in diagnostic or admin panel (not production ready). We also discussed the possibility to share some acceptance tests code with that to check the parity and making sure that both Event Stores return same, standarised response (maybe also as some shared nuget package). If not then for sure starting point would be to write black box tests before running implementation.

Having that we could check if Event Store UI can query Marten (that would be the quick win for our users), then we could think about maybe providing our own "swaggerlike" UI, that could also query EventStore, or work with Greg to have same UI).

I was also thinking about splitting that implementation into 2 “modules” - one responsible for Atom feed management, second for data translation from the exact implementation. Then at some point first module could be also generalised and maybe reused by both event stores.

But for now I'd like to provide some basic PoC and see how it goes. I know that it might not look like top priority for now, but I think that this might open lots of doors for us. It'd be also good for both communities to have some collaboration.

@jeremydmiller @mysticmind @jokokko thoughts?

[gregoryyoung]

if people want to know how to play with ES to check out atom feeds ... note familiarity with curl is useful but the documents contain all curl commands to explore on your own local node instead of just reading docs

Download from https://eventstore.org/downloads/
Run EventStore.ClusterNode.exe It defaults to port 2113 on localhost for http

You should now have your node up and running.

Start here (the description document for varying ways to read) https://eventstore.org/docs/http-api/description-document/index.html?tabs=tabid-1

There are docs here as well see reading/writing events etc

Writing https://eventstore.org/docs/http-api/creating-writing-a-stream/index.html?tabs=tabid-1%2Ctabid-3%2Ctabid-5%2Ctabid-7%2Ctabid-17%2Ctabid-11%2Ctabid-13%2Ctabid-15 note there are multiple ways of writing (ES format allows multiple writes in a single round trip)

Reading https://eventstore.org/docs/http-api/reading-streams/index.html?tabs=tabid-1%2Ctabid-3%2Ctabid-5%2Ctabid-13%2Ctabid-15%2Ctabid-17%2Ctabid-19%2Ctabid-21%2Ctabid-23 gain multiple ways .... the embed mode is most likely what is wanted (10 events in a page = 1 GET not 11 GETS)

Delete is just curl -X DELETE "http://127.0.0.1:2113/streams/newstream"

Note the differences in the Accept header XML/json there are two formats!

Also very important are the headers that can be included... https://eventstore.org/docs/http-api/optional-http-headers/index.html

There is one specific header likely worth further discussion here and that is ES-LONGPOLL https://eventstore.org/docs/http-api/optional-http-headers/longpoll/index.html?tabs=tabid-1%2Ctabid-3%2Ctabid-5 which will hang an http request waiting if data is not yet available until a timeout or if it becomes available (eg: don't poll!)

[oskardudycz]

@gregoryyoung Thank you a lot for the reference links!

[gregoryyoung]

I should ADD when playing with the feeds ... look at the cache-ability of what you are getting out ;-) You will note that all responses that are NOT HEAD are infinitely cacheable.

[mysticmind]

@gregoryyoung Thanks for all the details and the links!

[jeremydmiller]

I'm going to unilaterally bump this to 4.1 today.