Hello there!
This question is more of a conceptual...
# pactflowb
Beth Pennell
05/12/2022, 4:39 PMHello there!
This question is more of a conceptual one, as I'm trying to get my head around the best implementation of pact for my use case.
The project I'm working on is looking to implement a microservice design, but most of the services will be reliant on 3rd party APIs and integrations including Salesforce, HooYu and Equifax.
Its one of the reasons I've been so excited about the release of bidirectional contract testing. Originally I thought it'd be a case of curling an endpoint to get a public facing version of an Open API spec... until I actually saw the inside of the APIs (SF especially).
Am I right in thinking that the base concept for the provider side spec is just "get an OAS in any way you can" and push it to Pactflow, for which Postman-to-oas seems the most sensible call as this is a tool we already use. Do you then need to centre the postman collection on all endpoints and functionality? Or just the bits the consumer cares about (e.g. were not going to use all of Salesforce functionality for our application)
š 2
m
Matt (pactflow.io / pact-js / pact-go)
05/13/2022, 3:26 AM
Its one of the reasons Iāve been so excited about the release of bidirectional contract testing. Originally I thought itād be a case of curling an endpoint to get a public facing version of an Open API spec... until I actually saw the inside of the APIs (SF especially).š
š 1
Matt (pactflow.io / pact-js / pact-go)
05/13/2022, 3:29 AM
Am I right in thinking that the base concept for the provider side spec is just āget an OAS in any way you canā and push it to Pactflow,Well, sort of. Thatās all that Pactflow needs. But the key thing, is that the OAS is a valid representation of the provider (it can be a subset which is safe, but canāt contain things the provider canāt do, because itās used to determine safety for consumers)
for which Postman-to-oas seems the most sensible call as this is a tool we already use. Do you then need to centre the postman collection on all endpoints and functionality? Or just the bits the consumer cares about (e.g. were not going to use all of Salesforce functionality for our application)Technically, only the bits the consumer needs. The upside of mapping out the entire provider experience, is that if a new consumer comes along, or new requirements for the existing consumer mean it would now consume more of the providerās interface, you donāt need to wait for a provider to update the tests and the corresponding OAS. If it were me though, hearing your problems, Iād probably just map the APIs you know you use as a starting point and going from there. The SF surface area is quite big, so it might be wasteful to go too far beyond that.
b
Beth Pennell
05/13/2022, 4:09 PMYeah, I've managed to obtain an OAS spec for it today, but that's presented me with a new problem in that the spec file is 15.8MB.
So there's no chance that's going to fit into a header b64 encoded. Is there another way to upload provider specs when they exceed header size from the PUT request to the pact broker / pactflow?
Beth Pennell
05/14/2022, 10:25 PMIgnore the above, misread the example! Will give a proof of concept a go
š 1
m
Matt (pactflow.io / pact-js / pact-go)
05/14/2022, 11:24 PM