Enterspeed has just dropped updates to our Delivery API and Routes API. Both updates support static site generation.

In Delivery API news, we've cranked up the volume on retrieving views. Need a ton in one go? No problemo! With our new POST method, you can now send a batch of handles or viewIds and fetch up to 1,000 views in one request :

See more details in our docs.

The Routes API is stepping up its game and now supports a continuation token for paginating the response. It's not just an update; it's the recommended way to navigate the Routes API.

See more in our docs.

And as always: Have fun using our API. If you need any help, please make sure to reach out. We're happy to assist!

When you install the Enterspeed Umbraco package on an existing site with content, media, and dictionary items, you should do a full seed to ingest all the data into Enterspeed. This is simple with just a click of a button.

But what if you change a hostname for a subsite or update your code to include additional properties for your media items? How do you re-seed the affected nodes without doing a full re-seed?

With version 2.4.0 it’s now possible to select specific nodes you would like to re-seed, being all media items only, a specific content node with or without it’s descending nodes or specific dictionary items.

It’s even possible to clear the queue of seeded items if you accidentally seeded the wrong items.

Nice right?

Just go ahead and update your package reference to the latest version and check it out.

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!