Building a POC application with Next.js, choosing Vercel vs. Cloudflare - Part 1

The world of headless and a MACH based architecture has been part of our lives for around 8 years now. Did you know that React and Vue.js went Initial Release over 9 years ago and Next.js and Nuxt.js went Initial Release over 6 years ago!

Now, whether you are a startup or an established organisation, starting a new project or experiencing the trials tribulations of moving from an alternative, potentially aged/monolithic approach, putting aside the prerequisites of a strong vision, business plan, and product-market-fit; many technical founders, solution architects and dev teams are in many respects being forced into the MACH world and scrambling to make smart decisions on their framework of choice.

In this article I discuss experiences of deploying a proof of concept Next.js application to the web. As a truly amateur developer, with a background in mainly Microsoft .NET technologies, I wanted to prove if the hype of fast, simple, powerful application development was real and describe the journey I see many of the aforementioned people going through now and in the coming years.

Disclaimer: this article is not about what frameworks to choose, as it is not my core expertise, but here are some articles if your looking for more on that:

• The State of JS 2022: Rendering Frameworks - 5 min read
• Next JS vs React : Which Framework to choose for Front end in 2023? (radixweb.com) - 15 min read.
• Comparison of Gatsby vs Next.js | Gatsby (gatsbyjs.com) - 5 min read
• Next.js vs. Nuxt.js: Ultimate guide - LogRocket Blog - Long read
• MACH Global Research 2023 (machalliance.org) - 10 min read

What am I doing here?

A question I often find myself asking!

So, I happened to stumble into a conversation a few weeks ago about an idea that if executed well, could potentially change an industry. What it is, is not important right now, it's certainly not my idea, not an industry I know all that well and as you know, ideas are often, just that!

The expectations on me in the conversation, as often is, was "how hard would that be to build". Now, I have always maintained that in any project, technology is the least of your worries and the last part of the barrier to "getting started".

Even seasoned SaaS CTO/CPO's who are 2, 5 and even 10 years down the line will likely recant technology decisions they made on day 0 and share the mistakes, gotchas and hindsight moments they had along the way.

What's important to me (in the context of this endeavour), is prototyping.

Prototyping means, how can I quickly put together a something that works, allowing me to demonstrate the fundamentals to key stakeholders and use it to iterate on as the "idea" comes to fruition or evaporates into nothing.

Now, I would describe my approach to this and in fairness, any technology project as "lean" or "pragmatic". This means that, I am looking always for the holy-grail of technology decision making...

How do I make decisions today, that get me as close to my MVP, as quickly as possible, without spending lots of money AND avoid being stuck with or locked in to certain stacks/frameworks that may cause significant disruption later down the line?

These are areas of time and money drains I am often looking out for;

• Investment in code or software platforms, in 2023 most programming languages are open source, you likely don't need a content management system and any downstream or back office tech can be mocked/inferred. Choose starter kits wisely and where possible, avoid getting lured into proprietary development platforms such as Force.com or even Microsoft Power Platform. They are amazing and have their place, but not usually the right choice if you are building IP that you likely wish to call your own.
• Investment in DevOps and Hosting, whilst developing and demo'ing on a local laptop is the norm, being able to share the POC in a secure way with interested parties is a better experience. We also need to remember, this is only in idea stage and most DevOps/Hosting systems are proprietary and require some level of customisation and setup. We may need to graduate to a fully-fledged DevOps/WebOps platform (such as Dataweavers , Microsoft Azure DevOps , Platform.sh ) later. Which would extend far beyond the POC into what I call "operational problems" like Security and 24x7 support. For now though, we need simple build & deploy functionality that ideally works out the box (more on this nugget later!).
• Closed platforms, whether free or otherwise, some platforms like Webflow for example, offer a "zero-code" approach to building front-ends. But it only runs on their hosting platform or you have to pay to "export". Whilst Webflow is a brilliant product, it's IMO not a great choice to originate your own IP in terms of an application, that has a web front end. In fairness to them, its also not their market or USP.
• Paid-for UI frameworks, I am a huge believer in open source CSS frameworks such as Bootstrap. They take care of so many foundational issues like browser compatibility and grids. However these often have paid-for UI frameworks that extend them. Some of them are beautiful, however I see two important things here; Firstly, you don't need them to get a POC off the ground, if you are too focused on the UX in those early weeks, you will distract yourself from solving real problems. Secondly, at some point you will hire a designer and a front-end developer, and in my experience they will HATE these UI frameworks, slowing them down. Whilst I think this opinion will change over time, it's fairly agreed that a strong UX and the development of a UI/UX is still an art that cannot be bought off the shelf.
• Trying to do too much in your POC, putting a MLP, MVP, Definition of Done line in the sand early is important. If you are time boxing your POC, you may want to consider ranking and prioritising what will make the cut. If required, circulating your mini program of work with stakeholders is important too, make sure they have a no technical jargon buy in of what you are spending your time on. Get agreement upfront if a stakeholder wants to see something specific, try to avoid half-way through major scope changes. In reality this is the toughest one to look out for, but good planning and everyone working together aligned to the same vision and plan usually eradicates most issues.

Finally, putting aside higher-purpose guiding models and frameworks such as SAFe and Pragmatic Marketing there are few defined models that talk intimately about technology decision making from a leadership perspective. Many SDLC models assume that the technology and framework choices are already made or assign one person to that decision. This is something I believe many vendors in space take advantage of, but subject of another blog, another day.

Wow, that was a lot to cram in.

So, the decision has been made, Next.js it is!

If you recall, I said that I wasn't here to compare frameworks.

But, I needed to choose a framework for this POC, so why did I choose Next.js?

My real world experiences of Next.js started about 18 months ago, guided by senior developers in my teams, they were adamant that alongside Nuxt.js it offered a strong framework, acceptable learning curve and wave of innovations happening almost weekly. I think I can call myself "experienced" these days, but it felt like I was getting the vibes of excitement from early .NET days, which is fair to say, have stood the test of time for many applications/use cases.

I guess I am also a sucker for good, consistent and relentless marketing. With the strong tie between Vercel and Next.js, my experience in the Sitecore world and the many connections on LinkedIn, I cannot go a few days without seeing something about Vercel on my radar. It was looking good for Next.js straight out of the gate and to be honest not many other solutions really hit home.

What "fundamentals" did I actually need?

Now that is a bloody good question.

"Fundamentals" mean the mix of functional and nonfunctional requirements.

After taking less than an hour (you should spend more time!) jotting down the "fundamentals", here is what I felt needed for the POC;

• Full-stack framework
• Configuration over code
• Proven API support
• Database support (ideally SQL, MySQL or Cosmos)
• Built in or powerful CSS framework
• Boring stuff taken care of (Routing, Middleware, Rendering, API routing)
• Authentication and Login, with OAuth 2.0 support
• Dashboard, Profile and Basic Content pages
• Search with 3rd party data support
• Host on free or very low cost services

This is not an exhaustive list, but here are my pro's & con's in my head on my way to making the decision to go with Next.js:

The purists reading would like add a heap more, but remember I am approaching this from an amateur dev perspective with the intent on doing as much myself as possible in the first few weeks. Your situation maybe different.

Having spent around 1/2 a day investigating each of these options, I felt like I had assembled a set of tools that were going to work well together.

Here is the detail on what I chose:

• Next.js - It gave me the sense it was all up, the best fit and met MANY of my functional and operational requirements.
• Tailwind CSS - I've been looking for Bootstrap alternatives for a while, this is that and offers native documentation/support in Next.js.
• Prisma & Planetscale DB - Offered a free managed MySQL offering and Prisma is the Next.js recommended ORM. Note I avoided the also recommended PostgreSQL, I have had bad experiences in the past.
• VS Code IDE - Whilst I run MacOS, VSCode is extremely familiar to me.
• GitHub Enterprise - I pay for my own GitHub account anyway and it felt like the logical choice, the free edition would suffice.
• GitHub Co-pilot - I subscribed to the 60 day trial of this, keen to see how it can help me navigate the Next.js framework.
• Platforms Starter Kit by Vercel Platforms Starter Kit (vercel.pub) - Gave me code that solved many functional requirements AND a project structure to work from that reduced my learning curve. It is also actively maintained.
• Next-Auth - It supported all of the 3rd party social login services I was likely to need, offering configuration over code for almost all providers.

My biggest blindspot in all of this was my lack of programming skills, more specifically JavaScript. Whilst I can hobble together code and GPT-4 is amazing at allowing me to prompt common problems into code samples. I needed something that was going to deliver working code, quickly and allow me to iterate on, knowing that it wasn't so far away from being production capable that it would be a long-term write off.

By this point I had many of these tools installed locally and whilst I needed to do some cleanup of sample and test repositories, installations of MySQL and random versions of Node.js, I was ready to start getting this stack setup.

In Part 2 of this article we'll go through how long each step took and learnings along the way. Part 3 will discuss where we hosted the application and why.

All comments and questions welcome.