Decoupled CMS or Monolith Blog is concern.
These days, I am thinking about making a website of my own. The requirement is simple. I want to save the blog posts I will forget after doing them. Then find it again when I have to repeat these steps. Plus, I have to show my recruiters what I am doing.
The answer is a blog. Yes, a blog. However, I have to think about how do I publish the blog. Choose a free theme, and start writing is easy for many people.
As for me, I know I will write a few, but I have to show my work and learn JS, especially Node and NextJS. Even monolith, I have to theme myself and start a website. I am a Drupal fan, and I chose Drupal.
I faced many problems with Drupal earlier. However, I have some understanding of Drupal so far. I chose Drupal as the backend. The Frontend you read this post is NextJS, my favourite framework of JS. I am Laravel Developer, and choosing NextJS is the easiest way to start working with it.
The main problem is how to decouple the Drupal. When I first touched Drupal, it was tough to understand or work with. Its learning curve is steep and not very workable with other applications. After time flies by, it becomes easy, using composer dependency and many more. Laravel and Drupal are very close to each other. Laravel Herd now supports Drupal at the time of writing.
When I looked for the decoupled Drupal, it does have the documentation of decoupled CMS. REST export also plays well for decoupled Drupal, and I love it. Then I proudly chose decoupled Drupal.
NextJS is not a very new framework for me. I am working on it during Covid Era when SEO is critical for that website. Now it is Version 13. I am back to NextJS, and many features like the app router, UI Streaming hit me.
Architecture Consideration
The decoupled CMS is not very easy for me. In other ways, theming everything for Drupal is not easier. Finally, I chose NextJS and decoupled Drupal.
There are two reasons. First, I want to separate the presentation and Data layers. Second, I know how painful the plugins of Drupal are. The difficulty of maintenance makes technical debt. After some time, they make a huge mess.
I know limited information about NextJS, but I am used to VueJS, Laravel and some frameworks that use npm. So, I can do it.
Another way is to build a theme for Drupal and start writing on it. It is simply just a monolith blogging website. It has two problems, scalability and maintenance.
When the website becomes bigger and bigger, it needs to be scaled. Whether it will or not is another problem. When it needs to be scaled up, I need to distribute the Frontend to many servers, known as horizontal scaling. Some do vertical scaling, for example, stack exchange. I need two servers minimum for failover, plus geo-distribution.
The best example includes Medium and social media, Netflix and streaming services. They can load posts and images within seconds. I had a project handling up to 9TB of storage, which was a headache. I needed a cache of 2TB to serve the traffic. They download at least 3GB to 50GB on signed URLs, and I have to work on both uploads and downloads.
That experience makes me think every project needs to scale immediately according to the production.
Implementation
The progress costs me about a week. To be precise, I build 3 or 4 days to make the perfect image. I hope it will cost more hours to make everything smooth and clear.
NextJS has the best function of caching. I have to use a memory cache when NextJS does not have caching functionality, but it is now built-in. However, it is not working well with App Router. It caches everything and boom, I'm stuck.
However, there is always a workaround. First of All, don't use it. Whatever it is, it solves. Also Drupal, it is hard to get some posts and parse them into a single post. Categories and Path Alias are headaches.
Conclusion
Finally, I can run the NextJS and decoupled NextJS in my blog, and I will write a lot more about NextJS, Laravel and more. We love the mountains after we put them under our feet.
View Sample: GitHub.
