Simon Faber has proposed to scope LightNet at first to a library. The product itself than could be made with Next.js.
I have a lot of experience with static site generators and have used Jekyll, Hexo and MetalSmith extensively. My own website is built with MetalSmith. And in my job at Fonkel, I introduced these static site generators. I also have created a tool that builds static sites from Drupal, where the mini sites themselves are done with Jekyll.
I think there are interesting aspects to this idea. I also see some challenges:
Pro:
- Easy deployments
- End user performance
- Decoupling from ‘Distribution’ and ‘Engagement’
- Cheap to run
- Run it anywhere
Cons:
- Build times, the bigger the library grows the longer the built will take. I have very bad experiences with the build times; running for 45 minutes for a simple Jekyll site with 300 blog/article items.
- It will be harder to enable statistics for federation as the team would not necessary control the infrastructure where it runs.
- Access control can only be on/off not specific to each media item.
- Decoupling also brings challenges. The CMS side of things has a lot of commonality with the engagement side. But all these things have to be built twice in complete different ways. Which increases complexity horizontally.
- CRUD
- Authentication
- Authorization
- a terminal tool (in the beginning) to deploy is hard for Erin or other content managers.
- I think in this approach it will be harder to develop an offline app as the testing gets more complicated.
- Updating translations requires a full new build
How to evolve 1
I think this technology could lend itself for having an evolving architecture.
- media static site (distribution)
- media static site, with comment section like Disqus (distribution & engagement)
- It is of course also possible to find an open source Discus, that is what I basically mean, but could not find it very quick. I know these exist.
- The comment section would only integrate on the client side via an embed code.
- media static site, with comment section like Disqus and sharing git repositories with encrypted media. (distribution & engagement)
Federation in this case could be that media meta data is pushed into a repository with git secret. And everyone who has been allowed to access certain media is able to de-crypt that media meta data.
There is no federated search available (media meta data is encrypted). A catalog of datasets might be possible to place inside GitHub by using a specific LightNet tag. Similar to BibLogos.
Challenges that I see:
- Changes take very long to distribute (manual rebuilds).
- You still need different systems for things that are similar on an abstract level.
- Federation requires git secret (which uses GPG) and additional complex tooling. It also shift to developers.
- Engagement can not happen at the static level, so less re-use of concepts such as authorization, crud and authentication.
- It does not align with non functional requirements
- It can not honor the licenses by limiting access to certain media items in specific contexts.
- It does not support re-use of the API for other uses not envisioned. (record-my-sermon.com).
My advice
Search for an other alternative that lowers complexity.
I think it is not a good idea to create LightNet with a static site generator:
- Erin will not be able to manage the sites in the beginning.
- Changes take time to be visible.
- It limits possibilities for future integration and re-use.
- Incremental site generation can improve build times but then all the advantages such as the easy deployments are gone.
- From my perspective this is a not in line with the vision.
I think Next.js on the whole could be used however I also see challenges with the direction it does things. It is a bowl of coupled things. Using for example the <Image /> tag binds the product to a specific build process. It is harder to decouple.
Why do I think it is better to have control on the components level? Why create a new meta-framework? Or better said, why to create a specific app? Because you can control the solutions and make them fit better with the requirements.
How to evolve 2
It would also be possible to use Next.js only as a stepping stone. In this scenario the channel viewer is created with Next.js and in the first stage it is deployed statically and in a later version a NodeJs server is added.
This can be a great way to lower complexity in the start. I have looked at the docs. Which state what functionality work in static mode. It looks fine to me. I do wonder how images should be done and especially when thinking about hot-linking other peoples their data.
How to evolve? When using static site generation only as a stepping stone to create the channel viewer and not as a conclusive methodology to maintain you can go many ways in the next phase.
I do think Next.js is very opinionated and does all the coupling for you. I personally would not choose it as I would want to have control on the coupling myself.