I've done some research into the subject of response serialization for NestJS/GraphQL. There's some helpful information to be found here, but the documentation seems to be completely focused on a code first approach. My project happens to be taking schema first approach, and from what I've read across a few sources, the option available for a schema-first project would be to implement interceptors for the resolvers, and carry out the serialization there.
Before I run off and start writing these interceptors, my question is this; is there any better options provided by nestjs to implement serialization for a schema first approach?
If it's just transformation of values then an interceptor is a great tool for that. Everything shown for "code-first" should work for "schema-first" in terms of high level ideas of the framework (interceptors, pipes, filters, etc). In fact, once the server is running, there shouldn't be a distinguishable difference between the two approaches, and how they operate. The big thing you'd need to be concerned with is that you won't be easily able to take advantage of class-transformer and class-validator because the original class definitions are created via the gql-codegen, but you can still extend those types and add on the decorators necessary if you choose.
I am working on a project that has over 2000 integration tests that full circles the database. I want to speed up the process so I thought why not fake the database.
We are using Fluent NHibernate as our ORM which is probably why I am having such trouble. We have already implemented this concept in a program that does not use NHibernate but rather basic CRUD operations.
Basically on any CRUD operation I would like to save the object in memory to say a dictionary list. This will speed up the process of our tests which will hopefully lessen our build times. Not to mention the cool factor.
I have looked into having two separate sessions and having the session factory use one or the other but I would have to implement many methods/properties that I really don't care about.
I also considering using a go between in class that does the translating myself but it would probably include me changing A LOT of existing code. I am trying to limit the impact on the rest of the project as much as possible so regression testing will not be a HUGE factor.
Please let me know of any other suggestions anyone has!
Thanks!
Use a SQLite in-memory database. Here's the blog post that originally showed me how...
http://jasondentler.com/blog/2009/08/nhibernate-unit-testing-with-sqlite-in-memory-db/
Prior to using ORMs we always performed object caching in our service layer. This gave us the ability to switch between different data layers without having to change our caching implementation.
Nowadays we use both Entity Framework (mainly code first) and NHibernate. NHibernate seems to have much better caching features with several 2nd level cache providers available.
Another problem I am faced with is that for both of the above ORMs we make use of lazy loaded properties. So if we are retrieving an object from the cache we normally have to reattach it to the current ObjectContext/ISession, something we can't really do in our service layer.
So should I really be looking at implementing caching at the repository/data layer; and is it likely that I will find a common solution that will work for EF and NH?
Thanks
Ben
Have you looked at the CQRS pattern? Because caching is policy, I'm suspicious of trying to automate these decisions with a "one size fits all" cache like a second layer cache. E.g., if what you really want to cache is the HTML for your site home page, then a second layer cache is just a waste of memory and an invitation to bugs.
CQRS turns these mechanical considerations into policy decisions. And it's ORM-agnostic.
My experience is that 2nd level cache provided by the ORM will cache the data based on the actual resultset retrieved from the database. This can give you a lot of overhead because the object instantiation and data population is pretty costly.
The advantage is that lazy loading etc will work fine, but big results will still use up a lot of resources when repopulating the objects.
We use a combination of 2nd level cache and the ASP.NET cache in our webapplication because of the costly overhead, which in rare cases saves us as much as several seconds (!), but with the drawback of not being able to lazy load collections or update the entities.
This is based on NHibernate only, I have never worked with entity framework but I'm guessing all ORM frameworks suffer from this.
As a newbie to nHibernate, I am finding the creation of sessions to be a tad confusing.
Why doesn't nHibernate ship with something like what (i believe) Unit Of Work does?
or is there something built and UofW is more of an addon/preference? (context: ASP.NET MVC web application with SQL server).
Note: I am new to nHibernate, and spoiled with how MS does things. I would love it if things that are generally required to be shipped with the product download etc.
The session is kind of unit of work and also an identity map. You can create your own unit of work abstraction over it. Different applications need different kinds of unit of works and different programmers like different implementations too.
You won't need more than 50 lines of code to create your own unit of work implementation to abstract session and transaction management.
In case you haven't found it yet... there is a Unit of Work component for web applications that is part of the NHibernate Contrib project, called NHibernate Burrow. It is reasonably flexible and supports short (session-per-request) and long (sessions spanning more than one request) conversations.
I have used Burrow with ASP.NET MVC in the past and it works fine, though I haven't tried the long conversation in MVC. In it's current state, in order to use it, you will need to update the library references and compile the Burrow project. It's a little extra work but it's worth it.
I agree with Paco, although in a web application this can be a little more work.
I think the real issue is that most of us want to isolate our upstream code from a direct dependency on NHibernate and therefore we don't want to work directly against the session.
Once you wrap you head around NHibernate this abstraction becomes pretty simple but but it's a little harder to get your head around this abstraction at the same time you are trying to learn about NHibernate for the first time.
AOP is an interesting programming paradigm in my opinion. However, there haven't been discussions about it yet here on stackoverflow (at least I couldn't find them). What do you think about it in general? Do you use AOP in your projects? Or do you think it's rather a niche technology that won't be around for a long time or won't make it into the mainstream (like OOP did, at least in theory ;))?
If you do use AOP then please let us know which tools you use as well. Thanks!
Python supports AOP by letting you dynamically modify its classes at runtime (which in Python is typically called monkeypatching rather than AOP). Here are some of my AOP use cases:
I have a website in which every page is generated by a Python function. I'd like to take a class and make all of the webpages generated by that class password-protected. AOP comes to the rescue; before each function is called, I do the appropriate session checking and redirect if necessary.
I'd like to do some logging and profiling on a bunch of functions in my program during its actual usage. AOP lets me calculate timing and print data to log files without actually modifying any of these functions.
I have a module or class full of non-thread-safe functions and I find myself using it in some multi-threaded code. Some AOP adds locking around these function calls without having to go into the library and change anything.
This kind of thing doesn't come up very often, but whenever it does, monkeypatching is VERY useful. Python also has decorators which implement the Decorator design pattern (http://en.wikipedia.org/wiki/Decorator_pattern) to accomplish similar things.
Note that dynamically modifying classes can also let you work around bugs or add features to a third-party library without actually having to modify that library. I almost never need to do this, but the few times it's come up it's been incredibly useful.
Yes.
Orthogonal concerns, like security, are best done with AOP-style interception. Whether that is done automatically (through something like a dependency injection container) or manually is unimportant to the end goal.
One example: the "before/after" attributes in xUnit.net (an open source project I run) are a form of AOP-style method interception. You decorate your test methods with these attributes, and just before and after that test method runs, your code is called. It can be used for things like setting up a database and rolling back the results, changing the security context in which the test runs, etc.
Another example: the filter attributes in ASP.NET MVC also act like specialized AOP-style method interceptors. One, for instance, allows you to say how unhandled errors should be treated, if they happen in your action method.
Many dependency injection containers, including Castle Windsor and Unity, support this behavior either "in the box" or through the use of extensions.
I don't understand how one can handle cross-cutting concerns like logging, security, transaction management, exception-handling in a clean fashion without using AOP.
Anyone using the Spring framework (probably about 50% of Java enterprise developers) is using AOP whether they know it or not.
At Terracotta we use AOP and bytecode instrumentation pretty extensively to integrate with and instrument third-party software. For example, our Spring intergration is accomplished in large part by using aspectwerkz. In a nutshell, we need to intercept calls to Spring beans and bean factories at various points in order to cluster them.
So AOP can be useful for integrating with third party code that can't otherwise be modified. However, we've found there is a huge pitfall - if possible, only use the third party public API in your join points, otherwise you risk having your code broken by a change to some private method in the next minor release, and it becomes a maintenance nightmare.
AOP and transaction demarcation is a match made in heaven. We use Spring AOP #Transaction annotations, it makes for easier and more intuitive tx-demarcation than I've ever seen anywhere else.
We used aspectJ in one of my big projects for quite some time. The project was made up of several web services, each with several functions, which was the front end for a complicated document processing/querying system. Somewhere around 75k lines of code. We used aspects for two relatively minor pieces of functionality.
First was tracing application flow. We created an aspect that ran before and after each function call to print out "entered 'function'" and "exited 'function'". With the function selector thing (pointcut maybe? I don't remember the right name) we were able to use this as a debugging tool, selecting only functions that we wanted to trace at a given time. This was a really nice use for aspects in our project.
The second thing we did was application specific metrics. We put aspects around our web service methods to capture timing, object information, etc. and dump the results in a database. This was nice because we could capture this information, but still keep all of that capture code separate from the "real" code that did the work.
I've read about some nice solutions that aspects can bring to the table, but I'm still not convinced that they can really do anything that you couldn't do (maybe better) with "normal" technology. For example, I couldn't think of any major feature or functionality that any of our projects needed that couldn't be done just as easily without aspects - where I've found aspects useful are the kind of minor things that I've mentioned.
I use AOP heavily in my C# applications. I'm not a huge fan of having to use Attributes, so I used Castle DynamicProxy and Boo to apply aspects at runtime without polluting my code
We use AOP in our session facade to provide a consistent framework for our customers to customize our application. This allows us to expose a single point of customization without having to add manual hook support in for each method.
Additionally, AOP provides a single point of configuration for additional transaction setup and teardown, and the usual logging things. All told, much more maintainable than doing all of this by hand.
The main application I work on includes a script host. AOP allows the host to examine the properties of a script before deciding whether or not to load the script into the Application Domain. Since some of the scripts are quite cumbersome, this makes for much faster loading at run-time.
We also use and plan to use a significant number of attributes for things like compiler control, flow control and in-IDE debugging, which do not need to be part of the final distributed application.
We use PostSharp for our AOP solution. We have caching, error handling, and database retry aspects that we currently use and are in the process of making our security checks an Aspect.
Works great for us. Developers really do like the separation of concerns. The Architects really like having the platform level logic consolidated in one location.
The PostSharp library is a post compiler that does the injection of the code. It has a library of pre-defined intercepts that are brain dead easy to implement. It feels like wiring in event handlers.
Yes, we do use AOP in application programming . I preferably use AspectJ for integrating aop in my Spring applications. Have a look at this article for getting a broader prospective for the same.
http://codemodeweb.blogspot.in/2018/03/spring-aop-and-aspectj-framework.html