Hello question about `api gateway / service mesh` ...
# pact-js
h
Hello question about
api gateway / service mesh
When services to services interact through api gateway or service mesh, what is the boundary of the consumer test? I think from
consumer <-> api gateway/mesh MOCK
and generate pact then
pact <-> api gateway/mesh + Provider
is that right approach? but for me, api gateway / mesh is just one layer to invoke function or other services. how to write contract for that? for example, most of AWS lambda integrate with API gateway. I can see example of lambda to invoke the function to write contract test, but I am not really sure how to deal with api gateway / service mesh layer boundary. hope it makes a sense lol
m
I’ve just merged an old PR that was in DRAFT status to https://docs.pact.io/recipes/apigateway. (It might take 5/10 to show up with the content whilst the netlify build runs)
That should give you some ideas
h
oh cool thanks Matt, 👍
Use a test only controller that is aware of the different public-facing request paths
is that mean we can skip gateway part, but adding gateway like layer for testing purpose? and get request and response?
m
yes, basically
only if the paths are different (which they often can be)
👍 1
h
Happy Monday Matt, one extra question, our company uses graphql mesh, so some endpoint were REST(aws lambda) and converted to graphql, is this case I think blackbox approach is better? send graphql request/response? little bit complicated , but I know about your opinions 🙂
m
I’m not sure I follow sorry, could you please elaborate?
Are you saying you’ve replaced HTTP/RESTful endpoints with GraphQL?
h
yeap becuz some of services are using REST(legacy) some of them are graphql, so company uses graphql-mesh services to convert REST to graphql (https://www.graphql-mesh.com/) to talk service to service
so in this case I think
graphql-mesh
is kind of same as
api gateway
but I am not sure, CDCT should send REST(without mesh) or just include graphql mesh + provider and send graphql call
I think graphql request(more like blackbox) is more make a sense, as consumer is looking for graphql response, but I want to know your opinion
m
Does the mesh run on developer machines or only in environments?
I’d say it’ll be hard to pact test though, because of the way it will want to work
h
we can run in local machine with graph ql mesh
m
If you do write pact test, you should write them as far as the consumer is concerned - what queries it actually makes (GraphQL). Then you would need to ensure the gateway (graphql mesh) knows how to handle it. But that would require unit tests of the mesh, that also setup contract tests to downstream systems
in theory, contract tests are perfect here because now you have an all-knowing intermediary, and if it gets out of sync things will break. but in practice depending on the tooling it might be difficult
h
in this kind of complicate case, BDCT is better? as it is more like blackbox ?
m
possibly, but we don’t support GraphQL schemas at this moment
h
yeap looking forward to see it in the future 🙂 I will try to roll out CDCT first with simple direct end points communication then once BDCT graphql release, I will look for other services 🙂
👍 1
I am in the beginning stage of promo contract testing in my company but so much things to consider lol haha but glad I can ask questions in here thanks Matt
🙌 1
m
You’re welcome!
❤️ 1