Fluidity vs Umbraco Content Nodes

With the recent release of Fluidity we are getting some really great feedback and questions, and one that popped out to me recently was sent by a GitHub member coonmoo who wrote;

'First of all, thank you very much for this package.
It works like a charm!

But I'm not sure what kind of advantage does this project offer compared to "normal" Umbraco content nodes where creating the same structures is possible?'

Whilst I gave coonmoo a reply on the issue tracker, I thought it was a really great question and one worth a blog post.

Content vs Data

The real crux of the question boils down to the difference between content and data. In an Umbraco context, content is the main site content that makes up the website, where as data is just rudimentary values stored in a repository somewhere.

Based on this description I can hear you thinking "well, can't we just think of a root content node as a repository and all it's child nodes as data points?" and technically the answer is yes, but, when using content nodes in this way it comes with a bunch of added features that may end up causing you some headaches.

You see, content is a rather special type of "data". It can be published and unpublished, it can be routed to on the front end, it is automatically indexed in Umbraco's Lucene indexes and it maintains a version history and audit trail. "Sounds handy" I hear you thinking, and yes they are, but they can also be a burden if you are managing large amounts of data.

Content Node Overheads

Some items could just be ignored such as the publishing/unpublishing however these will still be visible in the UI and could cause confusion from an editors perspective. Other things such as versioning and the audit trail however could quickly cause your database to fill up with redundant information if you collect a large amount of data. There are fixes for this, such as the UnVersion package, however this takes initial planning and still has a small overhead on saves as it still goes through the normal content saving pipelines but just does some extra cleanup at the end.

Even if you maintain a good database cleaning strategy, you now also have to take into consideration the Umbraco maintained Lucene indexes. By default all content nodes will get indexed in both the Internal and External indexes. If left in the default configuration you may quickly find you indexes grow and index rebuild times take longer a longer. In it's simplest form you could just exclude all your "data" doc types, but this requires you to remember to do this, but if you do want to index your data, then you might have to ge creative in order to separate it out from your regular content index.

Even if you maintain a good database and lucene cleaning strategy, you now also need to think of the internal memory cache. This is the internal cache for all your content models that is persisted in memory. This has been optimised over the years to handle content very well, but it has it's limits. The more content you push into it, the more memory it will take up and the slower things will get.

Lastly from a data storage perspective we also need to consider the database structure its self. The Umbraco database structure is a rather complex and normalised one, meaning your data can be rather difficult to get at by any other means other than the Umbraco API. And if you already have a database table of data you'd like to manage from Umbraco then, well, you'd be completly out of luck.

Fluidity to the Rescue

So as you can see, just using the Umbraco content nodes to store data comes with quite a lot of elements we have to consider. Now, if you wanted to spend some time, you could build your own editor UI in Umbraco as it has all the extension hooks you'd need in order to do this, however it is a rather steep learning curve for the average developer and this is where Fluidity comes in.

The reality is most editing UI's will look and behave pretty similar. You want to be able to list your data items, create new ones and edit and delete old ones. In addition, you'll like have a model of your data in your code base. What Fluidity does then is bridges that gap, acting as a kind of mapper between your model and a desired editing UI. With a few lines of code you can create a management interface for you data and have streamlined to perfectly suite your needs with none of the content node overheads.

Conclusion

As you can see, using Umbraco content nodes might feel like a simpler approach, but in the end, there are a lot more complexities than you might realise. With Fluidity however you can have a similar amount of freedom and flexibility in defining your data structures but do away with a lot of extra content based features you just don't need or want whilst maintaining data repositories.

I really hope this helps explain the differences between the two approaches and gives you a bit of understanding as to where Fluidity fits in the Umbraco landscape.

So, the next time you need to manage a data repository in your Umbraco project, why not give Fluidity a try.