I'd like to measure the length of some async calls made with WebFlux. I've been reading through various sources, as I understand the #Timed annotation is working with AspectJ and basically just starts a timer before the method call and stops it after. This obviously won't work with async methods.
Are there any solutions for WebFlux or the only thing I can do is passing around execution timestamps, cluttering my application logic?
Project Reactor natively supports Micrometer, please refer to the documentation to find out more:
https://projectreactor.io/docs/core/milestone/reference/#_publisher_metrics
For example, you may want to monitor reactor.flow.duration.
I am researching tools for Component Testing for Microservices in the dotnetcore world.
Along with Component Testing I am planning to do Contract Testing as well using Pact.net.
While reading Pact.net here:
https://github.com/pact-foundation/pact-net
I found link to:
https://github.com/seek-oss/seek.automation.stub
which says its a Pact based stubbing library for .NET.
This makes lot of sense to use since I am going to use Pact and my Pacts can be used for stubbing.
But before this I was considering WireMock.net https://github.com/WireMock-Net/WireMock.Net. Has anyone tried each and share their feedback which one I should pick? WireMock seems to be very popular in community compared to this Seek Automation stub.
Thanks for your help in advance!
You could ask this on the Pact gitter channel https://gitter.im/realestate-com-au/pact
I am trying to figure out the best way to determine if I am running UI tests for a web application. The reason I am trying to do this is because if I am running UI tests, the only purpose of these tests are to make sure that the UI is working properly and to do that, they should run against mocked APIs (we have a separate set of integration tests to make sure the UI and a true backend API work properly together). Also mocking the API calls will make test test run a lot faster which is another reason to mock them. I consider these "unit tests" for the UI.
I also don't want to have 2 separate copies of the same codebase where everything is the same except the UI test version includes the javascript file that mocks all the required calls needed for the UI tests to run properly. If I where able to figure out that I am running the application in UI test mode then I would be able to know whether or not to include the javascript file to mocks the calls.
Is there any "standard" or "accepted" way to do something like this?
When you start running tests - raise a flag in the DB and have a service you can call to check that flag. make sure to turn that flag off once the tests ended.
The short answer to "Is there any standard or accepted way to do something like this?" would be: no.
This is mainly because you don't want your UI to know this kind of information at all. You want your UI to just be your UI. As soon as your UI starts taking some decisions based on whether it's in "test mode" or "production mode", you embark on a slippery slope that will ultimately lead to a nightmare code-base.
This does not mean your problem cannot be solved; just that the solution should be approached in a different way. I'll first explain the general principles without any language specifics, then provide some guidelines for javascript.
General Principles
The only reason for you to be struggling with this is that your UI is too tightly coupled to the API.
The solution happens to be exactly the same as any situation when you wish to use mocks.
Program to an interface, not an implementation. (Ensure your UI binds only to an abstraction of the API - not the "true/production API".)
Separate instantiation from interaction. (Don't let your UI create any of its API dependencies, because that binds it to a specific implementation - rather provide interface on the UI for it to be given the specific API instance it should use.)
Program to an interface
First note that the above phrase does not mean your language needs to support an "interface" construct. (It's just an unfortunate choice of name by some language implementors.)
Define a base class/object which defines each of the methods/messages that your API should support. (However, none of these will actually be implemented on the base class/object.)
Your UI should have a variable/field/reference to the APIInterface.
Your UI will call the methods it needs from the API via the interface reference. E.g. APIRef.DoMethod1(...) or APIRef->DoMethod1(...) or [APIRef DoMethod1:...] etc.
Separate instantiation from interaction
The thing to avoid here is:
CreateUI {
APIRef = CreateAPI;
}
The above binds your UI to a specific implementation, and forces you to include those files/dependencies in your UI code. You would rather have your UI be told which API to use. E.g.
CreateUI(APIInterface APIToUse) { //NB: Notice that the type use to refer
//to the API is the abstract base type
//defined earlier (keeping to the "Program
//to an interface" principle).
APIRef = APIToUse;
}
//or
SetAPI(APIInterface APIToUse) {
APIRef = APIToUse;
}
Now your production application could look something like this:
API = CreateTrueAPI;
UI = CreateUI(API);
Whereas your test application could look something like this:
API = CreateMockAPI;
UI = CreateUI(API);
Notice how with this solution, your UI doesn't have a clue about "test mode" or "production mode". It just uses the API it is given. The only thing that knows about the "test mode" (in a manner of speaking) and the mock API is the test application.
Applying the principles to Javascript
First, let me state for the record: although I am familiar with the language principles of Javascript, I have never done JS development. So there may be some unforeseen complications. However, in the worst case, with a little tweaking and research, I'm sure you'll figure something out.
Javascript supports duck-typing which basically means you can send any message to any object, and at runtime the object will decide if it can actually process the message. You lose out on compile-time checking that you haven't made any typo errors, but as I understand it: you don't really need to define the abstract base interface at all.
So...
Simply ensure your UI has a reference to an API object.
Ensure your UI doesn't include any API implementation files (neither the true/production version nor the mock version).
In your production host create the true API, create the UI and pass the true API to the UI.
In your test host create the mock API, create the UI and pass the mock API to the UI.
I know this question is too wide to be answered with a simple "use this framework", but I would really appreciate your advice on that one.
I'm looking to make a (quite complex) project than will run over an API. I'm open to any programming language (PHP, Python, Java mostly) and found many frameworks that are more oriented to make a RESTful web server.
The only major constraint I have is that I would have a reusable, simple and not-code-spaghetti independent package in order to improve my API later easily or even switch to an other framework with no pain.
For Python & Java, I thought about making a dedicated package. Each action would call the dedicated method in the package, the package would return object/dict and the action would transform it to the proper format.
After many research, I hesitate between two framework that could be good for my work but I need your advice because I wouldn't make any mistakes here.
Play! Framework (Java)
Pros :
Router are RESTFul oriented (you define the method (GET, POST, etc), the request and the class.method to use)
You don't have to make one class per action
Cons :
The Model is already included. If I later change the framework, maybe I will be stuck with it (but apparently not since Play! seems to use JPA)
Maybe the fact that if I want to send parameters to the action that would be defined in the method signature, I have to adopt the ClassName.properties instead of a json like {ClassName: {properties: 'value'}}
Tornado Web (Python)
Pros :
Seems to be very powerful : used by FriendFeed (at least) !
Auth via major OpenId, OAuth and Facebook already implemented
Very light (could be a problem)
Cons :
Not so popular : you understand better the work by going into the code than the doc
Urls seems to be very basics (As far as I saw it, you have to define all the urls in one file, with all the class included)
One Class per action (that could be heavy)
Decorators for the basic (testing if user is auth, etc) must be made
For using them in production, it would be easily possible with apache & mod_proxy or nginx.
So, my questions is quite simple : what would you choose (between those two or others, I'm not closed to suggestions) and why ?
Thank you really much for your advice!
My favorite RESTful Web App development framework is Restlet. It's a Java framework/library (it can be thought of as either) but it works well with Jython and JRuby, so if you prefer those languages you could still use it. I mostly use it with Groovy.
I prefer Restlet because:
Its API fully embraces and aligns with RESTful paradigms, so it encourages you to work RESTfully. For example, when a Router routes a request to a ServerResource, it creates a new instance of the ServerResource for every request. This encourages the implementation to be stateless. And there's a rich class hierarchy with all the concepts required to implement a RESTful web app: Client, Server, Protocol, VirtualHost, Request, Response, MediaType, Status, etc.
Its API includes classes for writing both servers and clients, and they're very consistent and almost symmetrical. For example, there's a ServerResource class and a ClientResource class. ServerResource.get() and ClientResource.get() both return a Representation. The only difference is that you implement ServerResource.get() and generate a response representation, while you call ClientResource.get() and receive a response representation.
The API is consistent with Java conventions. For example, if a request made with ClientResource.get() receives an error response such as 401, a ResourceException will be thrown. And if you're implementing a ServerResource and want to return an error status, you just throw a ResourceException (which is a RuntimeException, which is nice).
Via its extension mechanism, it plays very nicely with a broad array of the best Java libraries around. Extensions are included for various HTTP client and server libraries, databases, templating libraries, security libs, data libs such as XML, JSON, OAuth, OData, etc., and even OSGI.
Deployment is very flexible. You can embed a Restlet-powered API in an existing Java app, an existing Java Servlet app, or any standard Java Web App (Servlet) server. Or you can build a stand-alone server app with an embedded HTTP server such as Jetty — that's my preferred approach. And because it runs on the JVM, it runs on almost any hardware or OS.
It's mature, reliable, responsibly maintained, steadily improving, and well supported both by the community and commercially.
It's open source, and has very clear and well-structured code. The developers are happy to accept any contributions. I've submitted a few patches and had them committed to trunk quickly with no drama.
Other options I'd suggest would be the Python microframework Bottle and the Ruby microframework Sinatra. They're both simple, straightforward, lightweight, and effective. And because they work with the WSGI and Rack stacks, there's a rich set of "middleware" modules which can easily be used with them.
This is a pretty fundamental question when using NHibernate in a web application, but I don't see any agreed best practice when searching the web. I've seen it done in lots of different places:
Created and disposed in the Repository method - This just seems silly to me, since when you get the object it's already detached.
At the beginning and end of the Controller Action - This seems better, but annoying to have to do it for each action.
At the Application level, in global.asax beginrequest and endrequest - This seems the best idea, but again, I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
Maybe there are other approaches?
Can IoC containers help in some way here?
Maybe you know of a good resource on the web regarding this?
And - what method do you use?
Thanks
Session per Request is probably the most used approach.
I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
In IIS 7 You can have access to the Session state in the Init event of Global.asax. That's why sharp arch uses beginrequest.
As for session management I agree with you - Global.asax is the best place for it. Event if you want to have a clean separation between layers and remove DAL settings from UI you can use HttpModule for it.
Also you can have a look at ayende's blog. It explains his way of session management