Replies: 8 comments 9 replies
-
|
My only comment about NOT "continue[ing] having Lighthouse and vets-api share the same URL (api.va.gov)" is that many apis or services already connected to or using the api will both:
I wonder which is more painful, managing the routing to the 2 apis behind the existing single url everyone already uses, or having every/any app that already uses the api change its' url and implement logic to decide which api to hit? If there aren't any apps that use components from both api locations I guess that doesn't matter, but I don't know enough about it to know, so just raising the question. |
Beta Was this translation helpful? Give feedback.
-
|
As far as I know, this is not a scenario that we have, but I am hoping that folks from both the vets-api side of things and the lighthouse side of things come to comment on this, so that we can find any possible things like that. I am not sure that there are many users of the vets-api services that are outside our ecosystem, and casual investigation seems to bear that out, but more in-depth is needed. The biggest issue with keeping the single URL is that Lighthouse is moving their APIs to Google Apigee, and a completely separate cloud service, so if we continue to route things inside our network, we will end up traversing the TIC possibly 3-4 times on a single request, which will introduce unacceptable latency. |
Beta Was this translation helpful? Give feedback.
-
|
If keeping one single URL adds significant latency, I agree that having two separate subdomains would be the better way to go.
I agree that more research is needed on how many services this change will impact. Feedback on suggested subdomains: |
Beta Was this translation helpful? Give feedback.
-
|
My biggest concern with using vets-api.va.gov would be if we were to integrate some other microservice which was not part of vets-api, would that still be an appropriate URL? Generic is what I was aiming for, to be honest. |
Beta Was this translation helpful? Give feedback.
-
|
I am left confused, because I thought the purpose of the Lighthouse Program was to onboard all the API's that the VA has (I know all is a stretch) - and have them be in one catalog all flow thru a single managed gateway/platform. It was my understanding that the VA wanted to stop having every group go off and do their own thing. Sounds like that is what this proposal is? Is this because of the Apigee concern of the gateway being in Google Cloud and the latency that would seemingly create being in the AWS cloud for the actual services? In other words, you don't like the architecture that the Lighthouse Program is doing and wish to separate yourself? |
Beta Was this translation helpful? Give feedback.
-
|
There's no 'like' or 'dislike' involved in this situation, the Lighthouse team is of course free to do whatever they want to do. In the architecture diagram which Lighthouse has presented, there are some requests which might traverse the TIC more than once, and that could introduce significant latency into the system, for sure. There is an explainer document here: https://vfs.atlassian.net/wiki/spaces/ECP/pages/1907523684/Explainer+-+VA.gov-Lighthouse+Overlap and a Direction setting document here: https://docs.google.com/document/d/1i0WgBFcOK0sL1x_WL5V7JMDRxPsM9aRcszput9iVkp8/edit#heading=h.o1b49rfssykx which might explain a little bit more about why we are doing this |
Beta Was this translation helpful? Give feedback.
-
|
tagging @nathanbwright so that he is aware since VANotify uses that external domain for some incoming traffic |
Beta Was this translation helpful? Give feedback.
-
|
Tagging @k-macmillan for awareness. |
Beta Was this translation helpful? Give feedback.
-
|
Agreeing with @kylesoskin and @rmtolmach that some more research may be needed to gauge impact. I might be missing something in the architecture, but there are a ton of apps that use vets-api, especially for feature toggles that need it to be publicly accessible to work, so pulling it behind SOCKS, even temporarily would break the site. Again, there might be something I'm missing or maybe we can add to this doc to clarify what happens to the vets-website apps accessing vets-api from *.vfs.va.gov and how long that period would be. I'm sure there's work to update review instances and GHA workflows/jenkins(?) as well |
Beta Was this translation helpful? Give feedback.
-
|
There is no intention to give the *api.va.gov URLs to Lighthouse until we have a solution which is externally accessible (in the case that an external URL is needed, which appears to be necessary) already in place. There is no intention to have anyone use SOCKS to access this API, ever. vets-website apps would never be expected to access vets-api from *.vfs.va.gov What are you concerned about with reference to review instances and GHA workflows and Jenkins, in particular? I'll modify the RFC to make this clear, but it's good to know that we will definitely need an external URL. |
Beta Was this translation helpful? Give feedback.
-
Can you clarify this comment, @timwright12 ? Do you mean that there are applications other than VA Mobile and vets-website that access the vets-api APIs via the external internet? |
Beta Was this translation helpful? Give feedback.
-
|
Just those two, but I'm considering vets-website a collection of applications rather than just 1. I should've clarified there, we have 71 React apps inside vets-website that use vets-api to varying degrees at different time. |
Beta Was this translation helpful? Give feedback.
-
|
Ah ok, so when these apps make calls to vets-api, what URL do they use to do that, is it the *api.va.gov url? Are they making the calls from the client's browser? |
Beta Was this translation helpful? Give feedback.
-
|
The react apps hit https://api.va.gov/flipper/features from the client when using feature toggles We also have a dashboard hitting: https://api.va.gov/v0/backend_statuses -- this one isn't a big deal though since it's just a single URL |
Beta Was this translation helpful? Give feedback.
-
|
This document lists the expected changes that the new domain separation is likely to bring, such as:
We're seeing input and feedback from people who work with these API to make sure we're on the right track and didn't miss anything. |
Beta Was this translation helpful? Give feedback.
-
|
Moved to #39992 |
Beta Was this translation helpful? Give feedback.
-
|
RFCs have been moved to: https://github.com/department-of-veterans-affairs/va.gov-platform-architecture |
Beta Was this translation helpful? Give feedback.
-
Summary
When we separate the Lighthouse APIs from the vets-api, we will be giving Lighthouse control over the api.va.gov subdomain. This will necessitate that we choose a new subdomain for vets-api.
We will use this name initially for an internal-only URL, in the .vfs.va.gov subdomain, which we have control over, and once we have an external URL granted from the VA, we will make the APIs available via the new .va.gov URL.
Motivation
We would be requesting an externally available URL for this set of APIs to support the use-case of external clients needing to access the APIs from the public internet. We believe there are consumers who would need this functionality.
Since this will be a permanent new URL, we want to be sure that we take the time to choose an appropriate name. It will be difficult to change this URL in the future once it is in use.
The expected outcome of this would be that the Lighthouse APIs would be available on the public internet at api.va.gov and our set of APIs which is backed by the vets-api processes would be available on the public internet at a to-be-determined URL.
Detailed design
The initial internal URL for building and testing this new arrangement will be
internal-api.vfs.va.govor a combination of the environment and this URL, e.g.:The external URL will be
platform-api.va.govor a combination of the environment and this url, e.g.:Suggested possible subdomains/URLS- platform-api.va.gov- platformapi.va.gov- vets-api.va.govThe initial design would include an AWS ALB (possibly re-using an existing ALB) for the initial API endpoint.
It is possible, though not likely, that we could use only ALB routing rules to send the traffic where we intend. Many times traffic will need tweaks or mangling, or headers manipulated, ad this would require some sort of reverse proxy to be next in the path.
The next step in the path, if necessary, would be a reverse proxy or API gateway. This would allow any manipulation of the traffic that was necessary. It is possible that we could continue to use nginx as we do in the existing revproxy. Other possibilities include using Kong gateway, Traefik with middlewares (already in use on our Kubernetes clusters) or another API gateway such as Tyk, Fusio, or some other TBD software. (An RFC to discuss the options here will be created).
Once the traffic exited the reverse proxy/API gateway, it would be routed either to vets-api, or possibly to some other service running in our infrastructure.
Alternatives
Alternatives to this architecture would be to continue having Lighthouse and vets-api share the same URL (api.va.gov) but this would create a difficult mess to untangle once Lighthouse moves their systems to GCP and Apigee. I do not believe this is a viable option, without introducing unacceptable latency and complexity to the system.
The only other alternative to creating a new external URL would be to use the internal-only URL,
internal-api.vfs.va.gov, available only from within the VA network. I believe that there are reasons for having this URL available from the internet, but the scope of those use-cases is unknown at this time. If it is determined that there is no use-case for an externally available API, then we would remain with the internal URL only.Adoption strategy
The initial strategy for adoption would be to create a parallel system under an internal-only url (.vfs.va.gov) which would allow us to develop the new way to access the vets-api API. We can do this without interrupting the existing revproxy or any existing infrastructure.
Once we have the new system in place and configured, we can request the new external URL from the VA ESECC, and start to migrate usage to the new public URL. If it turns out that external access is not needed, we can skip this step and just migrate users to the new internal URL.
Beta Was this translation helpful? Give feedback.
All reactions