You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Create a new repository, tentatively called cal-itp/eligibility-server (suggestions welcome)
Move the current localhost/server project there
Set up the usual tooling (pre-commit, mkdocs, etc.)
Goals
There are a number of advantages in having a standalone server project. A more robust implementation can help us design better testing scenarios for the client (benefits), while creating a path towards expanding into new eligibilities that may require custom verification logic. Separate projects can move at different speeds and respond to needs more nimbly.
The initial goals would be:
Usable by benefits in a local development context for testing (e.g. via a public Docker image)
Usage documentation, beyond the sparse text we have online now
During the transition, we don't need any major changes or features added for the server; the primary goal is to split the two projects apart while maintaining their current compatibility.
Alternatives
The status quo, where the server lives side-by-side in this same repository, is not all that bad. It simplifies local usage of the test server, and keeps a tight relationship between the client and server tokenization and encryption code. We could alternatively refactor the server into a top-level directory and work on it as a more monorepo concept.
The text was updated successfully, but these errors were encountered:
Background
The
localhost/server
directory contains a simple Flask app implementing a very basic Eligibility Verification API server. This server can be used for testingbenefits
with only local resources via the service defined inlocalhost/docker-compose.yml
. Read more about running the test verification server.Proposal
cal-itp/eligibility-server
(suggestions welcome)localhost/server
project therepre-commit
,mkdocs
, etc.)Goals
There are a number of advantages in having a standalone server project. A more robust implementation can help us design better testing scenarios for the client (
benefits
), while creating a path towards expanding into new eligibilities that may require custom verification logic. Separate projects can move at different speeds and respond to needs more nimbly.The initial goals would be:
benefits
in a local development context for testing (e.g. via a public Docker image)During the transition, we don't need any major changes or features added for the server; the primary goal is to split the two projects apart while maintaining their current compatibility.
Alternatives
The status quo, where the server lives side-by-side in this same repository, is not all that bad. It simplifies local usage of the test server, and keeps a tight relationship between the client and server tokenization and encryption code. We could alternatively refactor the server into a top-level directory and work on it as a more monorepo concept.
The text was updated successfully, but these errors were encountered: