Recently, I have been studying some related contents of JAMStack and found it is really a good thing. Therefore, I want to write an article to share this concept with students who are not familiar with JAMStack. This article mainly includes the following contents:
- What is a JAMStack
- What are JAMStack’s advantages
- What applications is JAMStack suitable for
- My personal reflections
What is a JAMStack
concept
JAM in JAMStack is an acronym for JavaScript, APIs, and Markdown. A Stack is a Tech Stack, a collection of specific technologies that we use to build applications. For example, the popular Stack in foreign countries is called Mean Stack, which means to build a Web application using MongoDB + express.js + AngularJS + Node.js technologies. So the easiest way to describe JAMStack is to use JavaScript, APIs, and Markdown to build Web applications. So JAMStack is a problem solution, not an implementation.
Then let’s take a closer look at how JavaScript, APIs, and Markdown play out in the JAMStack world.
JavaScript
In the concept of JAMStack, JavaScript refers to JavaScript that implements dynamic Web effects on the client side. It can be either Web frameworks like React and Vue or native JavaScript. It is responsible for the dynamic content of web pages.
APIs
The API here is the same as the API we normally call for development. JAMStack’s Web application sends AJAX requests or GraphQL queries via JavaScript to a back-end API that returns data to the front end in some format (typically JSON) to implement some user interaction.
Markdown
Mardown is a lightweight markup language. In the JAMStack world, files of type Markdown are often used as data sources for generating static HTML files. Those of you who have blogged with Hexo will be familiar with this concept, because hexo works by generating static HTML from Markdown files based on themes or templates that we specify and hosting them on Github Pages or other similar static web servers for others to access.
In addition to Markdown files, the static data source of JAMStack can be other things. For example, Gatsby (an implementation of JAMStack), which we will talk about later, allows static pages to be generated by directly reading the contents of the database using SQL through plug-ins.
After knowing the specific contents of these three concepts, we can experience how JAMStack works through a small demo of Gatsby.
Gatsby Demo
Due to the limitation of article space, I will not tell you the specific usage of Gatsby here, but I will write a series of articles later to teach you how to use Gatsby to build a relatively large content website (CMS) for free, you can pay attention to it.
To put it simply, Gatsby is a static-site generator that allows developers to rapidly develop websites using modern technologies such as React and GraphQL. It is a tool that exists in the build phase of the website. In order to give you a straight view, I used Gatsby to build a simple personal blog website. The source code of the website can be found in my Github repository.
Blog sites contain the following features:
- Blog list page: Displays all of my blog posts. (Static content)
- Blog details page: displays the details of each blog post. (Static content)
- Blog Comment list: a list of visitors commenting on blogs and showing visitors commenting on this blog. (Dynamic content)
You must have noticed that I marked the right side of each function point above whether the function is static or dynamic. Static content is content that doesn’t change very often and that gets the same results from different users over a period of time. Dynamic content is content that changes frequently, such as visitors’ comments on my blog. So why do I distinguish between these two types of content? To answer this question we can look at how the blog application works using a server-side rendering (SSR) solution. First, the visitor sends a request to the SSR server to view a blog. The SSR server receives the request and requests the content of the blog to the back-end service. Then it renders an HTML page and returns it to the user. At this time, if other users also request the same resource to SSR server, SSR server will still do the same work, request resource + render page. At this point, the SSR server actually consumes a lot of IO and CPU resources to do these repetitive rendering, and as your blog visits increase, these useless resources will be consumed more and more, and the user experience will deteriorate without upgrading the server side resources. At this point, you might ask, since server rendering is such a waste of resources, why don’t we just pack webpack and put it on a static server and render all the pages in the browser instead of SSR? This is no problem from the level of blog function, but it is very unfriendly to search engine optimization (SEO), Baidu can not include your blog, your site is not popular!
In order to avoid repetitive useless rendering and to be seO-friendly, Gatsby adopted a technical scheme to distinguish the static content and dynamic content of websites. For those static contents that are not frequently changed and hope to be included by search engines, Gatsby will generate them in the Webpack packaging stage, so that there is no need to waste resources to render the page when users visit the page. Moreover, these static files can optimize user experience through CDN. For content that changes frequently and does not need to be indexed by search engines, they will wait until the browser actually renders the corresponding component and then dynamically fetch the data through APIs.
Let’s take a look at the code directory structure of a blog site:
In the above code, the Server folder stores a simple Express application for managing user reviews, while the SRC folder is the front-end resource of Gatsby operation, which contains the following contents:
- Blogs: This folder is used to host blog content, and each Markdown file generates a static HTML file.
- Components: Stores the React component.
- Images: A source of images for your blog.
- Pages: Route folder of a website. Each file in this folder generates a corresponding HTML static file that is returned when the route is requested. For example, there are now two routes under Pages. The 404 route corresponds to the page where the resource was not found, and the Index route corresponds to the main page of the blog.
- templates: The template folder of the website, under which there is only a template file called blog-post.js, when Gatsby was building the website, every Markdown file under blogs folder would generate a corresponding HTML file through this template file. The blog’s HTML file will be returned when the user accesses the server without the need for server-side rendering.
Then we can take a look at the files generated by the Gatsby package:
As can be seen from the above figure, Gatsby generates a corresponding HTML file for each file under the Pages folder, and a static HTML file for each blog under the Blogs folder, as well as some JS files executed on the client. The generated files can be served directly by the static web server, and you can also put them in the CDN for faster user access.
Finally, let’s take a look at how this blog site works:
In the above picture, I click on the blog “How to achieve wealth freedom right now”. When I enter the blog details page, the browser does not request the HTML file of blog details from the server, but directly completes the rendering in the browser. The user experience is very smooth. This is actually a big highlight of the Gatsby app, which is: The Gatsby packaged app morphs into a React SPA app after the browser first requests a pre-generated static HTML file, and then the user interaction is no different from that of a regular SPA app. In other words, Gatsby not only retained the advantages of SSR program SEO friendliness, but also retained the smooth user experience of SPA application. It can be said that it took advantage of each other’s strengths and made up for each other’s weaknesses.
Other examples
There are so many applications for JAMStack that we just don’t notice them. For example, the React website, Reactjs.org, which is very familiar to React developers, is built using Gatsby. So beyond simple documentation and blogging sites, can JAMStack be used to build complex business applications? The answer is yes, in addition to some simple CMS platforms, JAMStack can also be used to build e-commerce platforms such as Braun. Surprisingly, the famous programmer learning website freeCodeCamp is also built using JAMStack technology stack. Check out the freeCodeCamp architecture design videos or articles on Google and I’m sure you’ll have a better understanding of JAMStack.
The advantage of JAMStack
I’ve already outlined some of JAMStack’s advantages in the introduction above, including SEO friendliness and a smooth user experience. What else is interesting about JAMStack?
A high performance
Why is JAMStack high-performance? This is because the application of JAMStack separates the static and dynamic parts of the site, and content that doesn’t change frequently is generated ahead of time, eliminating the need for additional computing resources for server-side rendering. In this way, when users visit a page for the first time, the speed will be very fast, and these static resources can be placed in the CDN to further improve user experience. Another benefit of separating dynamic content from static content is that the responsibilities of our back-end interfaces are clearer, the number of apis is smaller, and performance is better.
High cost performance and high scalability
Since the content of our front-end is some static files without the requirements of server rendering, and the static resource server does not have high requirements on performance, we do not need a lot of cost in purchasing the server, and we can even use some free resources such as Netlify and Gatsby Cloud to host our files. For the back end, since we have completely separated the front and back ends, the back end can use some cheap Baas or Serverless services, such as Auth0 as our user authentication service, Firebase as our interface service, etc. The nice thing about using these Baas and Serverless services is that they are cheap, and they charge based on interface usage. How many users you have determines how much you spend, and if you have very few users, you don’t even need to spend a dime.
In addition to its high cost performance, JAMStack also has great scalability. For example, let’s say your current blog site suddenly becomes popular because of a blog post. If your front-end static files use CDN, your site can easily scale, everything is automatic, you do not have to do anything, and if you use Serverless and Baas solutions, everything is automatic, users will not feel the difference in experience. You only need to pay a little more for the service you use.
Better developer experience
Taking Gatsby as an example, it allows us to use some modern front-end technologies for development, such as React, Styled Components and GraphQL, etc. These technologies are familiar to front-end developers, and there is no great learning cost, so the developer experience will be very good. In addition, because Gatsby uses React, it is indirectly connected to the React ecosystem, so that developers can use various best practices and libraries of the React ecosystem when developing Gatsby applications, which will undoubtedly greatly improve our development efficiency.
Higher security
Because JAMStack is a technology that separates the front and back ends, the lack of back-end rendering reduces the risk of attack. For example, the CMS platform generated by Gatsby is much more secure than the traditional WordPress platform :).
What applications is JAMStack suitable for
Since JAMStack has so many benefits, shouldn’t we just use JAMStack in all our projects? The answer is no, because JAMStack requires us to separate the static part of the site from the dynamic part, where the content is generated at build time and the dynamic part is rendered in the browser, which makes it unsuitable for building the following types of applications:
- Nuggets, like Zhihu, are apps that are mostly created by third-party users. Because the content of these applications is created by platform users, and users can constantly modify and delete the content that has been created, it is not reasonable to use JAMStack to have the content of the site built frequently.
- Twitter, twitter, social applications. In addition to frequent updates, there is more dynamic content than static content in such applications. For example, the user’s home page only displays the updates posted by the people he follows, so JAMStack is not suitable for use.
- Some apps that don’t need SEO. A big advantage of JAMStack is that it’s SEO friendly, so if your application doesn’t need to be indexed by search engines, there’s no need to use JAMStack.
- Apps with lots of content. Because JAMStack requires us to build all the static resources each time, it is not suitable for sites with a lot of static content (such as more than 50K pages), which takes a lot of time to build each application.
JAMStack, on the other hand, is ideal for building the following types of applications:
- Project documentation, such as the React website.
- The official website of a business or organization.
- Personally managed blog site.
- Small – and medium-sized CMS platforms.
- Small and medium-sized e-commerce platforms.
- A mix of static content that needs TO be SEO and dynamic content that doesn’t need SEO. Some To B platforms, for example, have both a user workbench and static content related To action documents.
Of course, the applications I listed here, whether applicable or not, are in fact some very general classification, we have to make a case-by-case analysis in the actual development, according to the actual situation to evaluate whether our application is suitable for the development of JAMStack.
My personal reflections
I’d like to end with a few thoughts of my own on JAMStack.
First of all, I am very optimistic about this technology stack and will use it in future development. Because it helped me solve the problem of website SEO. Before I knew JAMStack, if I wanted my site to be included in search engines or I had to write HTML and native JS in slash-and-burn mode, it was obviously very inefficient to develop. Another solution is that I use modern development technologies such as React, so I have to learn SSR technologies such as next. Js to achieve SEO. One problem with this solution is that there is a certain cost in learning next. However, after using JAMStack or Gatsby, these problems are solved easily, because I can continue to use the React stack which I am familiar with to rapidly develop Web applications, and I can achieve SEO effects without considering the server side rendering problem. Isn’t this wonderful?
Secondly, I think JAMStack is very helpful for us to practice some of our uncertain ideas (entrepreneurial ideas). When I talked about JAMStack, I mentioned that with JAMStack you can actually deploy your application for free, because you can put your front-end static code on some free static resource hosting server, and then use some free Baas API service on the back end. Of course, this only works if we don’t have a lot of users on our platform, and we still have to pay when we have a lot of users. But wasn’t the number of users small when we started? If we buy the server resources and domain name in the morning, only to find out later that the idea doesn’t work, that’s money lost. On the other hand, with a free service, we don’t lose anything if what we make goes bad.
In general, I have a lot of confidence in JAMStack, especially as a CMS content management platform, which I believe will catch on and possibly replace WordPress.
Personal Technology dynamics
The article was first posted on my personal blog
Welcome to pay attention to the public number of green Onions to learn and grow together
