Submitted Date	17 Mar 2021
Approved Date	17 Mar 2021
Status	ACCEPTED
Impact	LOW

Overrides/Supersedes

This decision was migrated from the Tech Leads Decision Log as part of a consolidation process. The original decision record can be found here.

RFC

N/A

Stakeholders

Edge API developers

Contributors

Craig McNally Mikhail Fokanov Viachaslau Khandramai (Deactivated)

Approvers

This decision was made by the Tech Leads group prior to the adoption of current decision making processes within the FOLIO project.

Background/Context

As development teams begin to adopt the spring way for module development, it's become apparent that there's a desire for some of these teams to work with the same tech stack when developing edge APIs.

Two examples:

Assumptions

N/A

Constraints

N/A

Rationale

N/A

Decision

Create a spring way equivalent/port of edge-common, and pull share/common classes/utils into an edge-api-utils library which can be used from both edge-common and the spring way equivalent (edge-common-spring).

Implications

Pros
- N/A
Cons
- N/A

Other Related Resources

JIRAs

UXPROD-2973 - Create Spring-way equivalent of edge-common CLOSED
EDGCMNSPR-1 - Create Project Skeleton CLOSED
EDGCMNSPR-2 - Port edge-common to spring-way CLOSED
EDGAPIUTL-1 - Initial development of edge-api-utils CLOSED

Notes

edge-dematic can be used as a reference. Much of this work can be seeded from that repository and generalized.
The Concorde team has agreed to take on this work as it would allow them to use it for development of edge-search-srs.

Browser not supported