- Home
- >
- Software Development
- >
- The Emerging GraphQL and Serverless Stack for Building Static Web Sites – InApps Technology 2022
The Emerging GraphQL and Serverless Stack for Building Static Web Sites – InApps Technology is an article under the topic Software Development Many of you are most interested in today !! Today, let’s InApps.net learn The Emerging GraphQL and Serverless Stack for Building Static Web Sites – InApps Technology in today’s post !
Read more about The Emerging GraphQL and Serverless Stack for Building Static Web Sites – InApps Technology at Wikipedia
You can find content about The Emerging GraphQL and Serverless Stack for Building Static Web Sites – InApps Technology from the Wikipedia website
Newer JavaScript libraries like Next.JS and Gatsby are seeing increased interest amongst single page app and static site developers who are looking for speed and low cost when building new websites at scale. Startups are building next generation stacks combining GraphQL, cloud-based storage, and edge service providers to deliver their sites. The next goal? To make the whole architecture model serverless.
Hugo Meissner, founder and CTO at Blazity runs a number of Polish news sites, such as Pikio, that make million-plus API calls a day. He is keen to leverage speed as a competitive advantage by migrating his existing tech stack away from current servers and to a new architecture approach that draws on GraphQL, serverless and a content delivery network to reduce load time and serve up content at scale.
With three or four months remaining on his current contract with his hosting provider, Meissner is hoping the work he has done on rebuilding a prototype site using GraphQL will be ready to migrate over to later this year. Around the same time, the JavaScript framework he is using — Next.JS — which has just entered stable release of its version 3.0, can now export an entire project as a static site. That removes the need for any server-side rendering and makes it possible to host the site as an HTML/CSS file and JS file on a content delivery network (like Now.sh or Netlify). Once that is in place, Meissner can look at leveraging AWS Lambda to automate the entire site delivery to readers, paying only for compute when a reader actually views the site.
The New Static Site Architecture Model
All content is stored in an AWS Aurora database that is used by Graph.cool, which is the API provider and principal data source for the entire Pikio website.
GraphQL is rapidly gaining widespread adoption, especially amongst publishers, and it is increasingly being used as a complement to delivering single page apps and static sites through a serverless architecture. More tools are expected — particularly around evolving Content Delivery Networks (CDNs) to become more feature-rich “edge service providers” — that support publishers make use of this architectural model.
Graphcool builds a data model on top of Aurora using the GraphQL schema to expose the content through a single API endpoint.
The Graphcool endpoint is then used by GraphCMS to create a headless CMS and to provide more tools for the publisher to define their content model.
CEO and cofounder of GraphCMS, Michael Lukaszczyk said developers are increasing their interest in leveraging GraphQL for content-based sites. “Developers are not happy developing CRUD interfaces as well as GraphQL servers,” said Lukaszczyk. “Our product takes those two pain points and solves them. The benefit is the speed of development: you get GraphQL which is more performant than REST, especially if you query a lot of relational data. And for developers, it is more fun. For certain cases, REST is completely doing the trick, but if you have a complex data structure then we see developers going with GraphQL.”
Once the content management system is set up, the site can be created using the Next.JS framework. “Next.JS had everything I needed and is really simple to get started with. It does page routing, has a cool styling system, prefetching, and everything built in,” said Meissner. “The initial load gets handled by the server so you get yourself a rendered HTML at the speed of light, and prefetching of routes makes it so when you click a link, it’s JavaScript was already processed by the browser, hence the instant response.”
Meissner pointed to the prefetching capability as a particular need for competitive news content sites, which can prefetch the other pages of the site when a reader hits a landing page, so that future site links are delivered instantaneously. Although within Next.JS, in order to maintain its goal of being a universal framework that is focused on app infrastructure, it does not prefetch the data (or content). The prefetching is limited only to the structure of the site and not the actual content. For that, Meissner uses the Apollo package to pull the data via the GraphQL API from GraphCMS into Next.JS. With the move to version 3.0 and the ability to export a static site, Meissner is hoping that task will no longer be necessary.
Lukaszczyk says at GraphCMS, he is rarely seeing developers use the Angular framework anymore for their development projects. Next.JS and the Gatsby framework are emerging as frontrunners in the way sites are currently being built.
Using version 3.0 of Next.JS, Meissner says the site will then be exported as an HTML/CSS file, a Javascript file and a folder of the static assets (like images and a robots.txt file). Those files can then sit on an edge services provider network like Netlify, or Now.sh.
“Now.sh is really cool, and digging into the API enables you to do a lot more powerful things with your deployments, but you have to actually set up the CDN distribution yourself. Netlify is an infinitely scalable global CDN with a lot less configuration from my viewpoint. At present, the biggest scalable issue is server-side rendering. We use server-side rendering with SSR cache, but it is still costly,” said Meissner. “Once we move to the serverless, static site approach, there will be no server-side rendering. Then we can look at site automation, probably through AWS.”
Meissner said the Pikio prototype is testing much faster for load time, is easier to maintain, and will be considerably cheaper.
“The ideal is instant load, but minimizing bundle size, and compressing photos are not easily done for a news site with over 60,000 articles, so automating that is a problem in itself. At present we are tied to WordPress, which is tied to their templating language and we wanted to move to a modern stack. WordPress costs, and you still have to take care of scaling the entire website and managing the SQL database. With our new architecture model, you export it as a static site and you just have an API endpoint, that is the only thing that has to scale.”
Meanwhile, GraphCMS is working on importing tools to help their customers migrate from WordPress to their headless CMS. After that, they will need to build a clean interface for the publishers who are more used to using the WordPress interface for uploading their content.
Feature image: Photo by Sanjeevan SatheesKumar on Unsplash.
Source: InApps.net
Let’s create the next big thing together!
Coming together is a beginning. Keeping together is progress. Working together is success.