Relay.injectNetworkLayer(
new Relay.DefaultNetworkLayer(${GRAPHQL_SERVER}/graphql)
);
So How can I know graphql server has successfully injected this remote graphql server or not ?
You can check if there is a network layer implementation set via Relay.Store._storeData._networkLayer._implementation. If this is defined, your network layer has been injected. Fair warning, the underscore prefix tells me this is an undocumented API and is subject to change at any time.
Related
Am trying to hit my rest API in spring boot with the embeded server configured through browser and postman, but the request doesn't hit the server and am getting 404-not found am pretty new to springboot , please help me in this as in what to check further so that i can test my rest API
This could be due to couple of reasons
Try the following
Ensure the port you are specifying is correct
Ensure the end point you are specifying exist
Ensure the request you are sending is of correct REST action type (GET,POST etc)
Ensure your controller class is available in the same package in which Application class (with #SpringBootAnnotation) exists, else you will have to use #ComponentScan to make sure your controller class is scanned and endpoints available to receive traffic
Most likely, above should help :) If not, you'll need to describe what is done in the application so far
I'm testing a peer-to-peer app that I can send a URL to and then it should make a request to that URL. I can mock the response with the karate mock server, but I would also like to verify the request was made.
One idea I had was to log each request to the mock server to a file, then in my main scenario (which started the mock and sent the URL to the app) read it back for verification.
Is there a better way to do this? Can I access the state of the mock server from the scenario that created it without using a file. Can I tell the mock server to verify its own state?
I'm using the standalone JAR if that makes a difference.
Remember, Karate mocks are all about exposing arbitrary REST end-points that can "see" a bunch of global variables.
All you need to do is expose a "secret" end-point that your test can call to get pretty much anything you want out of the "state" of the mock.
More details here: https://stackoverflow.com/a/61374079/143475 and here: https://stackoverflow.com/a/63512034/143475
I am new worklight . I am using this WL.Client.invokeProcedure.What is the third parameter(useSendInvoke) in the WL.Client.invokeProcedure.
See this question about useSendInvoke: Use of third parameter in the WL.Client.InvokeProcedure
To quote Anton:
This parameter is used internally by WL authentication framework.
Technically there should not be a reason for developer to use it.
There are several ways to invoke adapters.
(1) First one is via client application. This is where you use
WL.Client.invokeProcedure(invocationData, options) API.
(2) Second is by using adapter invocation service -
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_adapter_invocation_service.html.
Basically issuing an http request to WL server and getting a response
from adapter. RPC style.
When you're doing it via (1) - you have two authentication layers -
first is security test defined for application, second is security
test defined for adapter procedure.
When you're doing it via (2) - there is only one security layer -
security test defined for adapter procedure.
UseSendInvoke param (which is, once again, for internal usage) means
that your application will go via path (2) instead of regular path
(1).
Hi i am new to worklight. When i am trying to invoke the adapter using the client side call. There is a parameter in the invoke procedure api call.The parameter is useSendInvoke .What does that mean?
See this question about useSendInvoke: Use of third parameter in the WL.Client.InvokeProcedure
To quote Anton:
This parameter is used internally by WL authentication framework.
Technically there should not be a reason for developer to use it.
There are several ways to invoke adapters.
(1) First one is via client application. This is where you use
WL.Client.invokeProcedure(invocationData, options) API.
(2) Second is by using adapter invocation service -
http://pic.dhe.ibm.com/infocenter/wrklight/v6r0m0/index.jsp?topic=%2Fcom.ibm.worklight.help.doc%2Fdevref%2Fc_adapter_invocation_service.html.
Basically issuing an http request to WL server and getting a response
from adapter. RPC style.
When you're doing it via (1) - you have two authentication layers -
first is security test defined for application, second is security
test defined for adapter procedure.
When you're doing it via (2) - there is only one security layer -
security test defined for adapter procedure.
UseSendInvoke param (which is, once again, for internal usage) means
that your application will go via path (2) instead of regular path
(1).
I am working to integrate data from an external web service in the client side of my appliction. Someone asked me to test the condition when the service is unavailable or down. Anyone have any tips on how to block this site temporarily while we run the test to see how the service degrades?
For those curious we are testing against Virtual Earth, but Google Maps but this would apply to any equally complicated external service.
any thoughts and suggestions are welcome
Create some Mock-Webservice class or interface (and inject it). In there, you could test the response of your system to webservice failures and also what happens, if a web-service request take longer than expected or actually time-out.
DeveloperWorks article on mock testing: http://www.ibm.com/developerworks/library/j-mocktest.html
You need to be sure to test the most common failure modes for this:
DNS lookup fails
IP connection fails (once DNS lookup succeeds)
HTTP response other than 200
HTTP response incomplete or timeout
HTTP response 200 but RPC or document returned is invalid
Those are just a few common failure modes I could think of that will all manifest themselves with different behaviors that you may wish to have your application handle explicitly.
If you set up a computer between the caller and service that routes between them, you can simulate each of these failure modes distinctly and modify your application to handle them.
How about blocking the domain name(s) in question by putting a nonsense entry into the hosts file?