JAMstack is revolutionising the way we think about workflow by providing a simpler developer experience, better performance, lower cost and greater scalability. JAM stands for JavaScript, API & Markup. A modern web development architecture based on client-side JavaScript, reusable APIs, and prebuilt Markup. Dynamic functionalities are handled by JavaScript. There is no restriction on which framework or library you must use. Server side operations are abstracted into reusable APIs and accessed over HTTPS with JavaScript. These can be third party services or your custom function. Websites are served as static HTML files. These can be generated from source files, such as Markdown, using a Static Site Generator. JAMstack websites don't have to be static. There are great services available to help bring some dynamic data to your product. You can also abstract your own functions into reusable APIs. For this you can use AWS lambda functions or Netlify Functions. Many JAMstack products have dynamic comment sections. These are typically used on blogs and a great way to interact with your audience. Setting up an online store on the JAMstack has never been easier.....
Lets also look at single-page application (SPA) which is a web application or web site that interacts with the user by dynamically rewriting the current page rather than loading entire new pages from a server. This approach avoids interruption of the user experience between successive pages, making the application behave more like a desktop application. In a SPA, either all necessary code – HTML, JavaScript, and CSS – is retrieved with a single page load, or the appropriate resources are dynamically loaded and added to the page as necessary, usually in response to user actions. The page does not reload at any point in the process, nor does control transfer to another page, although the location hash or the HTML5 History API can be used to provide the perception and navigability of separate logical pages in the application. Interaction with the single page application often involves dynamic communication with the web server behind the scenes.
Let’s say your next project is going to be a simple HTML website for a resumé, marketing a product or service, documenting your software, or something along those lines. A great option for you is to build your website using static site generators (SSG). There are tons of static site generators in a range of programming languages, such as JavaScript, Ruby, Go — the list goes on. A common CMS (Content Management System), like WordPress for instance, builds the web page dynamically as it is being requested by the client: it assembles all the data from the database, and processes the content through a template engine. With all the options available, it’s easy to feel paralyzed when it comes to choosing a static site generator that fits the bill. There are some considerations that could help you sieve through what’s on offer. Your project’s requirements should throw some light on the features you should be looking for in your SSG. If your project needs lots of dynamic capabilities out of the box, then Hugo and Gatsby could be a good choice. As for build and deploy time, all of the SSGs listed above perform very well, although Hugo seems to be the favorite, especially if your website has a lot of content. Is your project a blog or a personal website? In this case, Hugo and Gatsby could be excellent choices, while for a simple documentation website VuePress would be a great fit. If you’re planning an e-commerce website, then you might want to consider which SSG fits in well with a headless CMS for store management. In this case, Gatsby and Nuxt could work pretty well. One more thing you might want to consider is your familiarity with each of the SSG languages. If you program in Go, then Hugo is most likely your preferred choice. As for the remaining options, they’re either built on top of React (Next and Gatsby) or Vue (Nuxt and VuePress).
Now, headless content management system, or headless CMS, is a back-end only content management system (CMS) built from the ground up as a content repository that makes content accessible via a RESTfulAPI for display on any device. The term “headless” comes from the concept of chopping the “head” (the front end, i.e. the website) off the “body” (the back end, i.e. the content repository). Next is serverless architecture (also known as serverless computing or function as a service, FaaS) is a software design pattern where applications are hosted by a third-party service, eliminating the need for server software and hardware management by the developer. Applications are broken up into individual functions that can be invoked and scaled individually. Next is serverless architecture (also known as serverless computing or function as a service, FaaS) which is a software design pattern where applications are hosted by a third-party service, eliminating the need for server software and hardware management by the developer. Applications are broken up into individual functions that can be invoked and scaled individually. Hosting a software application on the internet usually involves managing some kind of server infrastructure. Typically this means a virtual or physical server that needs to be managed, as well as the operating system and other web server hosting processes required for your application to run. Using a virtual server from a cloud provider such as Amazon or Microsoft does mean the elimination of the physical hardware concerns, but still requires some level of management of the operating system and the web server software processes.
With a serverless architecture, you focus purely on the individual functions in your application code. Services such as Twilio Functions, AWS Lambda and Microsoft Azure Functions take care of all the physical hardware, virtual machine operating system, and web server software management. You only need to worry about your code. PaaS, or Platform as a Service, products such as Heroku, Azure Web Apps and AWS Elastic Beanstalk offer many of the same benefits as Serverless (sometimes called Function as a Service or FaaS). They do eliminate the need for management of server hardware and software. The primary difference is in the way you compose and deploy your application, and therefore the scalability of your application. With PaaS, your application is deployed as a single unit and is developed in the traditional way using some kind of web framework like ASP.NET, Flask, Ruby on Rails, Java Servlets, etc. Scaling is only done at the entire application level. You can decide to run multiple instances of your application to handle additional load. With FaaS, you compose your application into individual, autonomous functions. Each function is hosted by the FaaS provider and can be scaled automatically as function call frequency increases or decreases. This turns out to be a very cost effective way of paying for compute resources. You only pay for the times that your functions get called, rather than paying to have your application always on and waiting for requests on so many different instances.
You should especially consider using a serverless provider if you have a small number of functions that you need hosted. If your application is more complex, a serverless architecture can still be beneficial, but you will need to architect your application very differently. This may not be feasible if you have an existing application. It may make more sense to migrate small pieces of the application into serverless functions over time.
c. 2019, MEP Digital Systems (Pty) Ltd.
No comments:
Post a Comment