One of our essential focuses in Enterspeed has always been delivering content at high speed (heck, even our name includes speed). 

We want our customers and their users to be able to fetch content blazingly fast. To achieve this, we need to have the content deployed in the region where the user is located.

Most of our customers and their users are in the WEU region (West Europe), but we have also been lucky enough to serve customers in the SEA region (Southeast Asia).

Since our focus always has been speed, it seemed natural to deploy all of our customers' content to both regions to ensure the fastest speeds.

However, this is where our main focus conflicts with one of our other focuses - helping reduce our customers' carbon footprint by processing their data upfront. 

To achieve this, we must be mindful of where to store this data since delivering fast content takes processing power and storage. 

We're doing this by changing which delivery regions are enabled by default for our users.

As of today, the default delivery region for all new and existing tenants will be set to the WEU region (West Europe). 

This change will not affect tenants actively using the SEA region (Southeast Asia).

The SEA region (Southeast Asia) will still be available, but it will be enabled by request rather than by default.

Version control is essential in software development since it helps individuals and teams manage, collaborate, and safeguard their projects.

Since your Enterspeed schemas are the basis for your site's content structure, it makes sense to include it in your version control, e.g., GIT.

Also, schema creation and frontend development often happen simultaneously when developing a new feature.

To include your schemas in your version control, you will need to install the Enterspeed CLI.

Once done, you can clone your current schemas using the es-cli schema clone command. This will create a folder on your local machine called Schemas containing all your current schemas.

Next, type the es-cli deployment extract -e [your environment name] command. This command will generate a deployment plan specific to the provided environment. The resulting JSON file will include the schema alias and version number of all schemas that have been deployed to that particular environment.

You can now commit and push all your schemas and deployment plan to your repository. Next, let's see how to work with a schema locally.

Developing schemas locally

Now that we have our schemas on our local machine and in our version control, we're ready to start developing.

When we have made changes to a schema, e.g., updated a schema or created a new one, we need to import it to Enterspeed.

To do that, we use the es-cli schema import -a [schema alias] command. This command will import the schema, even if it's a new or updated schema. This way, you don't have to call either a create or save command.

To test your newly imported schemas, you can open the schemas inside the Enterspeed app, where you can test them against real source entities.

Once you have verified that all works as intended, it's time to deploy the schemas. Deploying schemas via the CLI is done using the es-cli schema deploy [schema alias] -e [your environment name] command.

The schema deploy command will trigger the deployment of the schema to the specified environment, initiating the processing and view generation. It will also update your local deployment plan to match the new version of the deployed schema.

That way, your deployment plan is always up to date and ready when you merge your change into the main branch.

Other developers can now run a full deployment to update their own environment using the es-cli deployment deployment deploy -e [your environment name] command.

Want to see how this works? Check out the video below.

If you are interested in seeing how you can use the Enterspeed CLI in your release pipeline, you can also check out this video below.

Inspecting and debugging routes is now easier than ever.

We have added the Route Inspector page in our app, enabling you to see what's going on quickly.

What do we mean by that? You see, routes can be a little tricky to debug, to put it mildly.

Let's first look at a "normal route" - a generated view.

Here we can see that the route /fairy-tales/the-snow-queen/ is generated by the source entity 1147-en-us, which gives us the view 1147-en-us/View/contentPage.

That's great and precisely the expected behaviour for most routes. What can be confusing and introduce head-scratching is when we start having redirects. 

Say we have a redirect for the route /fairy-tales/the-fire-king/, which is generated by source entity 1234-en-us, take redirects us to /fairy-tales/the-snow-queen/.

Before the route inspector, finding exactly which source entity was causing this redirect could be tedious. Now it is much easier to get a feel of what's going on.

As we can see in the example above, we can quickly locate which source entity is causing the redirect.

Sometimes… something comes along… that’s so fantastic… not even an Owen Wilson “Wow” can capture its magnitude. We are so excited to announce the preview release of JavaScript Schemas 🎉

Tenants with this feature enabled will now see the option to choose either JSON or JavaScript format when creating a new schema.

So, why is this exciting? As you already know, the schemas in Enterspeed are all about transformation.

We take our existing data from our data sources (CMS, PIM, etc.) and build schemas that generate the views we use in the front end.

Sometimes all that is needed is a simple one-to-one mapping. But other times, we need some custom logic to either format the data correctly or return the correct data to a specific user.

This is where we experienced a limitation with JSON schemas. JSON is fantastic for representing and structuring data. However, all custom logic could only be done using Enterspeeds own built-in methods.

This is fine for some of the most common cases, but as the logic and use cases got more complex, so did the job of developing and maintaining these methods.

That is why we decided to give the power back to the developer by providing them with a familiar and versatile language – the one and only JavaScript.

Ensuring all routes were presented in lowercase is now as simple as appending the URL with toLowerCase().

What’s next?

Our goal for the preview release is to achieve feature parity with JSON Schemas.

However, we also have a list of enhancements planned. One particularly exciting addition is the support for shared JavaScript modules, including third-party NPM packages and custom modules.

We are also focusing on improving the overall developer experience, aiming to make JavaScript Schemas as user-friendly as other IDEs like VS Code.

Lastly, it's important to note that the preview release does not currently support Algolia and webhook destinations, which are still under development.

How do I get it?

Want to test it out? Reach out on your usual support Slack channel or write to us at support@enterspeed.com to request access to the preview.

We can't wait to see what you can build with JavaScript Schemas.

We hope you want to try out the new JavaScript Schemas, and we'll be grateful if you'll try your use case and provide your feedback.

Please note that this is a preview release; we do not recommend using this for production tenants. We might make changes based on your feedback!

We expect to roll out general availability later in the summer.

On Friday, we will update Partial Schemas so that they function exactly like Full Schemas. You don't need to do anything before the upgrade*, and during the upgrade, there will be no issues with ingesting entities or deploying schemas.

After the upgrade, you will find that your Partial Schemas have been moved from the dedicated Partial Schemas section to a folder in the Schemas section. Once the upgrade is complete, you will see a banner in the Schemas section. With the upgrade, you can now version and deploy Partial Schemas to different environments, just as you would with Full Schemas. This upgrade also brings CLI support for Partial Schemas. 

We plan to perform the migration process in three phases, with the third and final phase taking place on Friday between 13:00 and 15:00 CET. If your tenant is in phase 1 or 2, you will receive further communication from us.

If you have any questions or concerns, feel free to reach out to us via your usual Slack support channel or email us at support@enterspeed.com.

*Less than 1 % of tenants have "alias collisions" and will receive direct communication.

The Enterspeed Ingest API makes it super easy to ingest vast amounts of data from your CMS, PIM, ERP, etc.

The source entities ingested are then instantly available in the UI in the “Source entities”-table and will, depending on your schemas, generate or regenerate a view.

That’s great and all. Using the API is extremely powerful. But sometimes you don’t need the most powerful thing to solve your problem. You just need it to be quick.

If you’re hungry now, you would prefer those sweet, sweet Taquitos (shout out to all the Taquitos-enthusiasts out there 🙌) from the local 7-eleven you can get instantly, rather than wait 30 minutes for a restaurant to make your meal.

This is why we’ve added the option for you to add entities directly from the UI.

On the “Source entities”-page, you will now see an “Add entities”-button in the top right corner. Clicking this button will open a modal that allows you to either upload one or more JSON-files or add your entity manually.

Nice.

Simply select the source you want the entity/entities added to. If you want, you can also change the generated Origin ID, which is a random UUID on the “Add manually”-option and is the filename on the “Upload files”-option.

As a help, we added the Request Body Schema, which shows which properties are available and which are required when adding an entity.

Enjoy!

Are you using Umbraco and Enterspeed together? 👯😍

Then we’ve great news for you. Because did you know that you can easily change the default culture logic in our Enterspeed package for Umbraco? 👏

🤹With Umbraco, you can have multiple sites running with different cultures, e.g. a site for your Danish visitors and another for your English visitors. 🤹

Maybe you also have a site that doesn’t vary by culture? In that case, the site will use the language that’s set as the default language in Umbraco. But if that’s not the language you want or if you have another custom culture logic, you can easily hook in and use your own custom culture logic in our Enterspeed package to Umbraco.

Awesome, isn’t it? ✨

Check out the documentation 👉 Culture and hostnames | Enterspeed Docs

The package is an add-on for our Umbraco integration, so if you use Enterspeed on Umbraco, this is great news for you 😊

Cloudinary is a cloud-based image and video management service.

The Cloudinary-Umbraco package will automatically upload the Umbraco media to Cloudinary and ingest the Cloudinary url to Enterspeed instead of the Umbraco url.

That means you can now effectively use your Umbraco media library in a decoupled architecture! 😮

Awesome stuff, right?

The integration is open source and you can find it alongside our other integrations in our documentation.

How does it work, you ask? See for yourself 👇

What happened?

There haven't been any new updates from us at Enterspeed in the last couple of months. There hasn't been anything except the sound of silence.

But fear not; there's no darkness here.

We have been busy optimising and tweaking our processing layer, making it run like a smooth, well-oiled machine.

You see, we experienced an incident with a backlogged processing queue at the beginning of January. This incident caused us to throw everything in our hands and optimise our processing layer with multiple small and large improvements.

This update will show what we've been doing in Enterspeed for the last couple of months and what we have done to avoid similar incidents.

Fair processing

Processing is usually very straightforward: One source entity is ingested, and a transformed view is ready for the Delivery API in a few seconds. 

And this works very well. However, at other times, the processing process becomes more complicated. 

Examples of more complicated processing scenarios are, e.g. a schema deployment or a re-ingest of all source entities. 

Processing in these scenarios results can result in many thousands of processing jobs. Thus processing time is not as instant as in the 1:1 source entity to view scenario.

That is by design, and we don't claim or even want to scale to instant processing times when the volumes become large. So this pre-processing model comes with some latency tradeoffs. But the problem was that one customer could affect other customers, and nobody likes noisy neighbours.

This is, of course, not something we can accept, and we have therefore implemented what we call a "fair processing queue". Without going into too much technical detail, we can now regulate how much processing time is available for different classes of tenants and different types of processing jobs. 

Overall, this allows us to remove the noisy neighbour problem so that all tenants will experience that ingesting a source entity will result in a generated view a few seconds later. 

The more complicated processing scenarios still create roughly the same number of jobs. We want to underline that the fair processing queue allows multiple customers to share the same resources fairly. 

Both from a cost and sustainability perspective, this was the design requirement in the fair processing queue concept we wanted to introduce.

So, we are thrilled with the design and performance of the fair processing queue.

No more over-processing

Another issue in those dark hours at the beginning of January was what we internally call "over-processing". 

In some cases, updating one source entity resulted in a spike in processing jobs. 

One of the key features of Enterspeed is that the developers need to worry less about cache invalidation and leave that to Enterspeed. 

In the inner details of these features, we found two bugs that triggered the re-processing of too many source entities. Re-processing too many source entities and a shared queue were the two main issues for the incident in January. 

Of course, we fixed the two bugs, but we also added a feature to the new fair processing queue: job de-duplication. 

We can now detect duplicate jobs within the same batch of processing jobs to reduce the overall number of jobs. 

This saves time and results in a win both for costs and sustainability. 

Death by a thousand paper cuts

The last thing we want to mention is the small optimisations.

When working with hundreds of thousands of processing jobs - and we saw millions at peak - all the small inefficiencies start to add up to large numbers. 

And this is one of the cool parts of working with some really large numbers; the small optimisations make a real difference. 

One of the really interesting things was an unexpected behaviour from a specific IoC container registration that caused a spike in CPU usage. 

We ended up removing all applicable IoC container registrations of IEnumerable<>, to optimise CPU usage. 

We also made several changes to how we query data from our data store. 

So if you want to learn more about continuation tokens and point reads in Cosmos DB, don't hesitate to get in touch. 

Another tweak to our datastore was to move more of the Cosmos DB containers to tenant-specific containers for our Enterprise tier.

Overall we are very pleased with the changes, optimisations and tweaks we have introduced. 

As with all software, we continue learning from our customers - you, our excellent technology partners - as the platform is being used for more than we imagined.

Until next time 👋

Just call us The Pointer Sisters because, boy, are we excited! And no way we’re going to hide it. 

This edition of Enterspeed Product Update contains so many incredible things. 

So… Let’s get excited!

feature CLI 1.0

We teased in our last EPU that the CLI (Command-line interface) would soon see the light of day. That day has finally arrived. We’re proud to announce version 1.0 of the official Enterspeed CLI.

The Enterspeed CLI lets you work with your tenant for all sorts of tasks, for instance:

• Managing environments
• Managing source groups
• Creating and deploying schemas
• And much more…

You can either work with the CLI locally, or you can implement it in your CI/CD pipeline – whatever fits your workflow.

Head over to the CLI documentation to see how you can get started using it. 

You can also check out this introduction video that our colleague Jesper W. made.

feature Schema snippets

We love coding. But sometimes less is more, which is why we base our schemas on low-code principles. 

Often you want to get something done quickly and efficiently without manually having to type a lot of code.

Well, we got your back, Jack. We’ve made it even easier to create your next schemas thanks to our new schema snippets feature.

Simply start typing the name of the field, property type, or example schema you want to use, and a list of options will appear in the editor. Click the tab button and BAM! You got yourself some code 👨‍💻

How easy is that?

We currently support the following shortcuts for schema snippets:

• "triggers" (field)
• "properties" (field)
• "route" handle (field)
• "route" URL (field)
• "actions" (field)
• array (property type)
• object (property type)
• reference (property type)
• partial (property type)
• dynamic (property type)
• Example schema: Breadcrumb navigation
• Example schema: Category products
• Example schema: Map all source entity properties
• Example schema: SEO Composition
• Example schema: Site settings
• Example schema: Top 3 product reviews

feature Schema versions overview

Do you know what can be a pain in the neck to keep track of? Different schema versions deployed to different environments independently of each other.

That is why we created a “Versions” overview page. It lets you see exactly which version of your schema is deployed to which environment.

Neat 📸

feature Schema compare versions (diff checker)

Well, now you no longer have to (even though we can understand if you still want to be like Travolta, he’s got some sweet dance moves) thanks to our “schema compare versions” functionality.

On your schema page, simply select the version you want to compare with, and a “diff checker” will appear, highlighting all the changes from the previous version.

You can even edit your current version at the same time.

feature commercetools integration

Our last few integrations have been focused on traditional CMS, but now it’s time to dive into a new category. This time with one of the worlds leading commerce solutions, commercetools.

commercetools, founded in 2006, is a cloud-based headless commerce platform with customers around the world. 

We’re so happy that we're now able to support these customers with this integration.

The integration lets you import your product, variants, and categories into Enterspeed.

GitHub link: https://github.com/enterspeedhq/enterspeed-source-commercetools 

feature Contentful integration (beta)

We have also developed a new integration to Contentful, the cloud-based CMS. With this integration, you can ingest your content from Contentful into Enterspeed.

The integration is now in beta and does currently not support all events and data types in Contentful. 

GitHub link: https://github.com/enterspeedhq/enterspeed-source-contentful-cp 

feature New Umbraco integration

One of our most popular integrations, our Umbraco integration, has just had a major update. To make things easier for users (and for us), we have unified our different Umbraco integrations into one, starting from Umbraco 9.

This makes it easier to update for the users, easier for us to maintain, and much easier for everyone to navigate the documentation.

The new unified integration supports Umbraco 9, 10, and 11, as well as all future Umbraco versions.

We have also added support for the new Block Grid Editor for Umbraco version 10.4 and version 11.

You can read more about the integration right here: https://docs.enterspeed.com/integrations/umbraco/getting-started

Improvement Unopinionated “Getting started” tutorial

We have made quite a few demos and articles based on exciting frameworks like Next, Nuxt, Astro, you name it. 

But sometimes you may not feel like having the Chocolate chip cookie dough ice cream with sprinkles and whipped cream on top. Sometimes you just feel like… Vanilla.

That is why we’ve created an unopinionated “Getting started” tutorial, completely free of any CMS or framework and simply based on good old “vanilla” JavaScript.

You can find the tutorial right here: https://docs.enterspeed.com/tutorials/creating-a-simple-site/intro 

Improvement Redeploy schemas

This is the good old “Have you tried turning it on and off again?” – but for schemas.

Sometimes stuff happens. For one reason or another, you might need to generate a new view without needing to update your source entities. 

This can easily be done by creating a new version of your schema and deploying it. But that quickly gets annoying if you need to do it multiple times – and you risk ending up with a lot of versions of your schema. 

We have introduced an easier way to do this. In the bulk deploy pane, you now have the option to redeploy already deployed schemas, meaning the version will stay the same but will trigger a regeneration of your view.

Improvement Create schemas directly in folders

In the last edition of EPU, we introduced schema folders, and boy, where you guys existed. That's until you realised that you had to prepend the folder name in the schema name in order to place it in the folder.

Then suddenly, it felt like being back in 2012 with some of you saying, “Ain’t nobody got time for that!”.

Don’t worry, we get it, which is why we've made a shortcut button for creating schemas directly inside your folders. 

Improvement Prefill types upon schema creation

This last improvement is yet another benefit for us lazy people. Yay!

When creating a schema, we previously introduced the option to prefill your source in the schema. Now we have taken it one step further by also enabling you to select source entity types.

These source entity types will automatically be added to your schema’s triggers inside the data source.  

fix Fixes and tweaks 🛠️

•    Source entities filters are now saved when navigating to a single entity and back.

•    Umbraco integration: Fixed that media domain was not added to all media types.

•    Improved visibility of dropdown labels in dark mode.

Until next time 👋