search

eiffel-community / community

Community guidelines such as governance, how to contribute, code of conduct, etc
Apache License 2.0
4 stars 15 forks source link

New project ''eiffel-event-repository-api" #99

Closed t-persson closed 3 years ago

t-persson commented 3 years ago

Name

Eiffel event repository API

Description

An API against event repositories that exposes the endpoints required by REMRem and other tools for the Eiffel community. This API will expose the endpoints described in the swagger schema here: https://github.com/eiffel-community/eiffel-event-repository/pull/11

This will be an empty project to start (just some scaffolding and boilerplate) in order to develop this fully open source within the Eiffel community. This means that anyone is welcome to help out. It will be written in Go and, to start with, use MongoDB as the database since it's what we are using with the Eiffel GraphQL API. Nothing stops people from implementing more database drivers.

Project license

Will be licensed the same as every other project within the Eiffel community; under Apache 2.0.

Name of initial maintainers

Tobias Persson tobias.persson@axis.com Magnus Bäck magnus.back@axis.com

Infrastructure needs such as Git repositories

Git repository: eiffel-event-repository-api

magnusbaeck commented 3 years ago

Note that only a subset of the ER API will be implemented, namely the endpoints that we agreed should be standardized and documented (which is on @m-linner-ericsson's todo list). Mattias, unless you upload a PR for that rather soon (Tobias is fast ;-)) we'll probably have some clarification requests.

magnusbaeck commented 3 years ago

I approve this proposal.

e-backmark-ericsson commented 3 years ago

I'm a bit concerned about the name for this project. I thought first that it was just a container for the ER interface swagger documentation, but when reading the description I understand that it intends to contain an (or several) implementation(s) of that interface. The existing "eiffel-event-repository" project is also an implementation (or is supposed to be when we finally get it open sourced). They will both then implement the same API, so if we should have two complementing ER implementations in the community I think they should have more appropriate names. Since both the existing one and this new proposed one assumes MongDB as their backends (at least to begin with), the only differentiating factor is the programming language (and the fact that the "old" one is not yet contributed to open source).

Also, isn't the "Eiffel Graphql API" project also an implementation for an event repository API? Where in the Sepia architecture would these two projects reside?

m-linner-ericsson commented 3 years ago

Got triggered by Emil's comment above. When I read https://en.wikipedia.org/wiki/API I think of the specification, not the implementation. Does this make sense?

magnusbaeck commented 3 years ago

Fair points. For obvious reasons I don't know much about Ericsson's ER, but the proposed eiffel-event-repository-api would land squarely in the historical events lookup Sepia category. Maybe eiffel-event-repository does more than that, like manage indexes and other things that indicate an ownership of the database rather than just an API to it? If not I agree that they're functionally equivalent and that eiffel-event-repository-api might not be the best name, but I'm struggling to come up with something else.

magnusbaeck commented 3 years ago

(My last comment was in response to Emil. Didn't see Mattias's response until later.)

Got triggered by Emil's comment above. When I read https://en.wikipedia.org/wiki/API I think of the specification, not the implementation. Does this make sense?

Strictly speaking, yes, an API would be something describing the interface itself rather than providing an implementation of it.

Rewinding a bit, the suggested repository would contain an implementation of the soon-to-be-standardized ER API, initially on top of MongoDB event repositories but potentially also other backing databases, with no claims to owning the database or its storage (i.e. you bring your own database). I'm not sure how to condense that long sentence into something short and sweet, so a reasonable option might be to pick a name that doesn't try too hard to describe exactly what it is, similar to Eiffel Gerrit Herald or REMReM.

e-backmark-ericsson commented 3 years ago

Regarding where to place this new "thing" in the Sepia architecture, I think it actually lands in the "Event Persistance" box. It is not 100% clear to me how Sepia divides things, but I read the "access modes" as "tasks performed by a client that is interested in communicating with Eiffel services", and the "Event Services" as the actual Eiffel eco-system services. There are no "implementations" proposed among the different access modes. So "historical events lookup" would be the action that a client performs towards an Eiffel event service. So I'd say that the proposed "API" fits into the same box as the ER does.

Thinking out loud here: Is the proposed project more like an SDK? I.e. something that can be used to implement a "real" service that should handle persistant event stores?

the suggested repository would contain an implementation of the soon-to-be-standardized ER API Yes, and that is exactly what the (Ericsson) ER is as well, an implementation of the ER API, and that is intended to be provided through the eiffel-event-repository project. I understand that this new repo could contain other implementations as well, not just an implementation over MongDB, but is there a reason to have multiple different "ER implementations" in the same repository?

I totally understand that you have a need to implement an ER, as long as we fail to open source ours, so I don't want to stop you from doing that in the community. And it should be perfectly possible to rename a repository after it's created if we see the need for it (but that would of course affect all developers having cloned it), so as long as there exists a good description of what the project intends to contain I'd say you should just pick a name and start implementing it.

REMReM is actually a quite exact description of what that service does, but it is an acronym (REstful Messaging for Registered Messages)

What about "GoMIER" - "Go MongoDB Implementation of ER"?

m-linner-ericsson commented 3 years ago

I agree with Emil about stopping you from going forward. I also agree with Emil about the naming suggestion. I would prefer a description of what it does rather than calling it an API.

t-persson commented 3 years ago

We do not really want to lock ourselves to using MongoDB with the name. We would probably want to support several other databases as well. How about "Goer" ?

e-backmark-ericsson commented 3 years ago

Sure Goer would be fine. Or GoER if we should make it a bit more complex to write :)

m-linner-ericsson commented 3 years ago

GoER/Goer is fine for me

magnusbaeck commented 3 years ago

@t-persson This issue can be closed now, right?

t-persson commented 3 years ago

@magnusbaeck Yes, I missed the "fixes" keyword