After 547 days of developement we are pleased to announce the first official release of Enonic’s integration with Next.js framework.
Next.XP is a combined toolkit that provides an opinionated framework for bulding Next.js websites with Enonic as the headless CMS back-end. Next.XP gives developers the best front-end-framework, while editors can enjoy a familiar content creation environment using visual page builder, tree structures and much more.
What are your overall experiences with adopting this as a way to develop XP apps, any big “gotcha’s” that you should be aware of if we would looking into this?
Do you co-locate the code for the XP app and the NextJS app or do you split it into separate repos? It seems the develop of apps using this framework might require working on two separate repos at the same time when developing a new XP app.
I have a bit experience with Headless XP having done two such projects now. One with NextJS (not with Next.XP) and one with SvelteKit as the frontend.
@espen_haviken You should be asking yourself what problem it is you are trying to solve by going Headless.
If you need to expose the content of your site as APIs that can be consumed by multiple platforms (e.g native apps) or by 3rd parties – then Headless can be a good solution.
At mattilsynet.no we exposed the content trough GraphQL-APIs, so that it can be consumed by 3rd parties (like Veterinærinstituttet).
But… If you just want to follow the most recent trend and go headless, be aware that there is a cost to develop on this more complex architecture, and there is a cost to maintain it.
We’ve kept them in separate repos. But we are moving to a monorepo to make it easier to keep version of the front and backend in sync. We often need to commit code to both frontend and backend togheter to add a new feature.
Thanks for the input It’s often easy to talk about all the “nice” parts of something you build, but I love hearing about small or complex parts that creates hassle, cause those are the important ones to know about when you are designing a new development process.
We are currently in process of trying to come up with a new way of building our sites. Our current process uses a custom Gradle plugin to merge a separate, in-house gradle dependency into each site xp app to add all the shared functionality between our different sites into the app. What we have seen is that this adds a lot of complexity to the build process, both through complex NPM and Gradle tasks, but also through stuff like NPM and Gradle being pretty sensitive to version upgrades, development sometimes ends up requiring development in the shared dependency and the separate site at the same time to deploy a new feature, etc.
For all of these “new” react-related ways of doing XP apps, there seems to be quite a big trade-off towards complexity, either during development (the requirement to split development of a new feature between two separate repos/apps etc), but also with regards to ops, since you now need to run two parallel services both during development and production to be able to serve your website.
I am hoping to K.I.S.S., not add even more complexity for our developers
As Tom Arild says, there is additional complexity related to the Headless approach. However, with Next.XP we have minimized this dramatically. Basically we have implemented the functionality of the Enonic Site engine into Next.js.
The promise of headless is freedom to use your favourite front-end tools, more flexibility related to deployment/hosting, and simpliied upgrades (upgrade CMS and front-end independently).The downside is as mentioned “more moving parts”.
Quite uniquely in the CMS industry, Enonic XP allows you to code JS directly in the CMS. So, if you like React, but prefer the tight integration and simplicity offered by building directly on XP - take a look at our React4XP framework (which will shortly be available in v4 with great improvements).
It’s often easy to talk about all the “nice” parts of something you build, but I love hearing about small or complex parts that creates hassle, cause those are the important ones to know about when you are designing a new development process.