Ability to inject middleware into rule #7
Comments
|
While injecting middleware is not yet available for hoverfy-java, one work around would be starting up hoverfly with middleware outside JVM, eg. : Then use the external hoverfly in hoverfly-java by setting the |
|
@tommysitu, we will give this work around a go. Thanks! |
|
@tommysitu we are able to invoke the middleware with the above workaround in a JUnit test! The next progression would be to move this invocation code into a networkHelper class that our app can call and get the synthesized data back. The only caveat is the HoverflyConfig and SimulationSource are both in the io.specto.hoverfly.junit.core package. We like to have a method like this... public static String getRoomScheduleSimulation() { //or parse the string into Model here... Any recommendations/thoughts? Thanks! |
|
@jxlampdx I am trying to understand your problem a bit better. Do you want to simulate a Restful endpoint (https://wpa.steelcase.com/rooms/a7155e79-842e-11e6-a1a5-000d3a321a2e/bookings) in your JUnit test? Also I am assuming that you are trying to test your application that depends on the synthesised response from that endpoint? |
|
@tommysitu , yes and yes. I like to be able to simulate and return a middleware injected response from Junit test and also able to have a helper method so that we can call it to get the synthesized data and populate the views... The problem we are trying to solve is to synthesize response from services that are not yet available from our backend. |
|
looking for a Gradle Build that is a Compile if it is available? Currently we have testCompile 'io.specto:hoverfly-java:0.3.8' |
|
@jxlampdx It sounds like you want to use the simulation for both your JUnit test, and also inside your application for the time being. For JUnit test, you only need to add the JUnit Rule to your test class: The JUnit rule would auto-configure JVM proxy and default SSL, therefore you don't need these flags "--insecure --proxy http://localhost:8500". Any particular reason you are invoking To use the simulation outside JUnit test, for example embedded in your application to be a stub server, you can invoke this when your application starting up: |
|
Yes, you can get hoverfly-java with compile / testCompile in Gradle. |
|
For hoverfly-java to work with both compile/testcompile. I changed the build.graddle to compile 'io.specto:hoverfly-java:0.3.8 instead of the testCompile 'io.specto:hoverfly-java:0.3.8' . is that correct? |
|
this is my dependencies ... dependencies { } and getting this error... FAILURE: Build failed with an exception.
|
|
Using compile is fine, it looks like you need to exclude Jackson-core dependency from hoverfly-java. |
|
I excluded t 'META-INF/jersey-module-version' and gotten passed the above. but now gotten another runtime error. Tried adding the compileOptions { clean and rebuilt but could get pass this error below. I also tried to remove all the dependencies and added them back one at a time, once I added back compile 'io.specto:hoverfly-java:0.3.8', will encounter the runtime error above. Any other ideas? Thanks! :app:transformClassesWithDexForDebug FAILED FAILURE: Build failed with an exception.
|
|
That's because hoverfly-java requires java 8 to compile. |
|
I see. now that I stepped back and look, if we have the remote instance running as a proxy, we don't actually need the integration in the Android app to invoke it. As long as we inject the middleware code before we call the service in the Android app, we should be good. Thanks! @tommysitu |
|
No problem @jxlampdx. We are always looking for interesting use cases of Hoverfly. Could you be contacted via email? We are quite keen to find out how you are using hoverfly for mobile development. Thanks. |
|
If it helps we have a contact form near the foot of the http://specto.io/ page so no one needs to disclose their email here. |
|
@JohnFDavenport and @tommysitu, I filled out the contact form. Thanks again |
|
Hey, I have been thinking about middleware a lot recently and how it should be used. There are currently two ways of executing middleware in Hoverfly. The first way is through a process that is started for each request. This has performance issues that occur as you start increase the load of Hoverfly. The reason for this is due to spinning up a new process for each request in flight. The result can be hundreds of child processes all spawned from Hoverfly. The other way, (which is currently undocumented as of the time of writing this) is running middleware over HTTP. This allows you to turn your middleware into a HTTP server (or maybe a serverless function a la AWS Lambda). Using this approach means that you generally only need one process to run the HTTP server which can be reused by Hoverfly, reducing the performance overhead with process creation. I have been thinking for a while that maybe the default way people should be implementing middleware is as HTTP servers. I believe its simpler and it is definitely more performant. With the middleware context out of the way, I think implementing middleware as a HTTP server in hoverfly-java could be much easier than worrying about middleware processes. In golang, it is very easy to produce HttpHandler functions that match a HTTPHandler interface to quickly produce HTTP servers. Maybe hoverfly-java users could define their middleware in their tests as a MiddlewareFunction that is then passed to hoverfly-java which then serves it and provides the address to the running instance of Hoverfly? Your opinions @mogronalol and @tommysitu? |
|
@benjih Yes I'm in agreement. We can implement a webserver middleware which starts in the same process as the test, as part of the Java code. This actually frees Java developers up to do whatever they want with the data. |
|
Seems like a great idea @benjih @mogronalol but I have some questions. (1) Would this be generic enough to be used in other languages? (2) Throttling: You could still flood the webserver with thousands of requests during a performance test. At the moment responsibility is being passed from the very efficient multi-threading Go process to a poorly scaling Linux process. The issues start when the tester wants to do something long-running like add a delay. How much better will this solution be? A webserver is unlikely to be more efficient than Go and will hit the same issues, albeit at a higher load. If the webserver calls out to a database will it have to manage a connection pool? It may be better to throttle at the Hoverfly end of things using some form of internal queue to maintain order. That might allow us to keep the webserver relatively simple. (3) When. After Hoverfly 1.0 please. |
|
|
@JohnFDavenport It won't be generic enough for other languages. We will need to start up embedded web server in JUnit tests using lightweight web framework such as Spark: https://github.com/perwendel/spark/ For simulating delay and network latency, it is better to have native support from hoverfly, and avoid the use of middleware whenever we could. |
|
Support for using local middleware is available, thanks to @dipak-pawar! |
The
builderfor rule could be modified so you can pass custom middleware into HoverflyThe text was updated successfully, but these errors were encountered: