January 2021 is packed with a lot of small and bigger improvements. One of the highlights is the support for geo searches for geolocation fields. In this blog post, I will showcase the most important improvements.
The geolocation field has been improved significantly. In addition to the old format, that is described in the documentation, the field also accepts GeoJson objects now. This means you can store complex objects like polygons in Squidex now. Furthermore a distance search has been implemented. In theory this sounds like a small feature, because most database servers already support geo searches. But the main problem with our database is that you can only have one geolocation field per table. Therefore this feature has been implemented by leveraging the capabilities of the full text search and you can have as many geolocation fields per schema as you want.
Our query system has been extended to support geolocation searches. For example search for a content item within 1000 meters around a geolocation in OData:
Or make the same query with JSON syntax:
When you create a schema field, you have to decide whether the field is localizable and you can create content in multiple languages or if it is not localizable. This decision was permanent and it was not possible to change that. This caused major issues because very often small companies start with a single market and realize later that they want to open their service to other countries. Everything had to do with how the content was stored in the database. We have changed the implementation and migrated all content to the new internal structure to make it possible to change fields.
Fields can still not be changed but you can just delete the field and recreate it with the same name but with the changed localization setting. Squidex converts your data then to the new format when it is queried.
The asset dialog has been improved to preview more formats.
For example you can preview Videos now:
or documents like Word or PowerPoint:
Furthermore a text editor has been integrated to edit text based documents directly:
The GraphQL endpoint has been optimized under the hood. Some big changes have been implemented to reduce the memory footprint of GraphQL schemas, making the system more performance and stable. We are expecting more performance improvements when the new major of the GraphQL library is going to be released in the next few days and we also consider moving to another library to bring in more features and even better performance.
So far the GraphQL schema was cached for 10 minutes, because it is a very expensive operation to create a new schema when you change the structure of your content items. We have improved this and found a very fast way to compare the current GraphQL schema with the actual content structure in each request. When such a change is detected the GraphQL schema is replaced in the background with a newer version. This means that you do not have to wait until your changes are live.
We also realized that most internal services and the API always returns the total number of items when you query the database for contents or assets. In many cases this is not necessary and just means an additional database call that can be avoided. Therefore these paths have been optimized to reduce the number of database calls.
Squidex has also received very helpful contributions from the community this month.
The highlights are:
I hope these features are helpful for you and we have more things in the pipeline. Very soon we release an extension to the scripting system and you can query other contents and assets in your script now. For example if you want to denormalize your content.
If you are looking for a feature that is not implemented yet, we encourage you to open a feature request in our Support Forum.