Why You Should Stop Writing Server-Based Web Apps
In this article, take a look at why you should stop writing server-based web apps.
Join the DZone community and get the full member experience.Join For Free
When the World-Wide-Web started in 1993, it served static HTML files with links to other HTML files. It wasn’t long before websites were made more dynamic and accessible—utilizing technologies such as Common Gateway Interface, or CGI, Perl, and Python.
Since the birth of the internet, I have built a number of web applications using a variety of languages, frameworks, and platforms. Among other things, I have written content management systems, application frameworks, a blog engine, and a social media application and I am quite proud of some of the applications. The others...not so much.
Recently I’ve come to the conclusion that I have been going about this all wrong. I am going to stop writing server-based web applications and, in this blog I will explain why you should too.
The Web Request Walk of Shame
Let’s take a look at a typical web request. A person follows a link. The request goes to the web server. The web server runs some code and figures out what view to render. The server fetches some data from a database and combines the data with a template. Finally, the server renders the response as HTML and sends it back to the browser. Sounds simple enough, right?
As you may know, any application beyond “Hello World” starts getting very complicated very fast. Often, one request creates multiple calls to a database or other internal APIs. More calls to databases and services mean more network latency. There could be frustrating caches at multiple levels attempting to solve performance problems. There could be multiple web servers behind a load balancer, making deployments more difficult.
More often than not, monolithic server apps turn into monsters. Breaking up a monolithic app into microservices comes at a considerable cost of effort and adds even more complexity and latency. What’s a web developer to do?
Pump Up the JAMstack
“Wait… static HTML? Like, serving plain HTML files? Are you kidding?”
Sounds like a step back, doesn’t it?
When I first heard about JAMstack, I thought,
I dismissed JAMstack.
Listen. Please don’t dismiss JAMstack the way I did.
The Truth About JAMstack
There is absolutely nothing faster than serving a file. Anything more requires CPU cycles at minimum or a “Web Request Walk of Shame” at worst. The fastest way to serve a file is to leverage a CDN, so files are physically closer. CDN providers are also experts in scaling to meet spikes in traffic and preventing DDoS attacks.
Static site generators are more advanced than ever. There are lots of great options available to satisfy a wide variety of needs. Plus, for folks who need an easy way to manage content, a new market of “headless” content management systems (CMS) has emerged to perfectly complement the JAMstack approach. During the build process, the static site generator can reach out to APIs, databases, an API-based CMS, or anything else it needs to maximize the amount of pre-built markup.
The Best of Both Worlds
You can still write code using your favorite language and platforms! Only now you focus on creating the best APIs for your application. Or, you can use your developer skills to automate the generation of static assets and deploy your application.
The more I have learned about JAMstack, the more I’ve realized there is incredible value in the approach.
- Simplify architecture
- Leverage the best 3rd-party APIs
- Take advantage of CDNs
- Intensely focus on delivering business value
Looking back at some of my previous projects through the lens of JAMstack, I can see how it would have solved so many problems, especially around scalability and deployment. For applications I first thought would be impossible to implement using JAMstack, I now see no better solution than the JAMstack approach.
I believe there is a bright future ahead for front-end and back-end developers alike—a future where we no longer have to write server-based web applications!
Where to JAMstack From Here
This post only skims the surface of the advantages of JAMstack architecture. If you want to learn more, our OktaDev team has created some fantastic content!
- Build a Secure Blog with Gatsby, React, and Netlify
- Secure and Scalable: An Introduction to JAMstack
- JAMstack: Web Apps at Ludicrous Speed (YouTube video)
- StaticGen - a curated collection of static site generators
Published at DZone with permission of David Neal. See the original article here.
Opinions expressed by DZone contributors are their own.