The M of Markup implies the use of HTML, and more specifically that of static HTML pages. These static pages are not generated by a webserver as they would have been in the past, instead they are generated as part of your automated build process by means of a static site generator.
A static site generator is a command line tool that processes input files and turns them into a website. These input files are optimized for the task at hand, such as markdown files for content editing, handlebars templates for semantic page composition or YAML files for metadata. There are literally hundreds of static site generators for you to choose from. Each of these comes with its own set of assumptions, conventions and opinions.
I originally started out with Jekyll, but after a while switched to a different approach. Instead of trying to fit all of the requirements to the opinions of a command line tool, I'm now building a custom site generator for each site to exactly fit its needs. This may sound like a lot of work, but with the help of Dish, my static site generation library, it becomes fairly trivial.
Once your build process outputs a static website, you can host it anywhere you like. A common hosting approach is to serve your apps directly from a CDN. Hosting on a CDN has many benefits:
- Instant global availability and great download speeds.
- Very cost effective, even a large site will only cost a few euro's per month.
- No need to manage webservers or deal with hosting providers.
- Many CDN's come with custom domains, free SSL certificates, built in routing rules and failover capabilities, etc...
I personally host my sites and apps on the Azure CDN backed by the Azure blob storage static websites infrastructure.
Over the past decade, many companies have begun exposing data and capabilities as services on the internet. These services can easily be integrated through API's exposed by the provider. Jamstack sites can leverage these api's both during the build process to generate static content and at runtime to dynamically generate content.
There are so many services available today that becomes perfectly possible to build an app without a backend at all.
- There are services to provide cross cutting concerns such as identity, authentication, content management, payments, email, monitoring, storage, etc...
- But there are also more and more domain specific services becoming available. As an example, the flemish basketball association exposes all clubs, players, game schedules, etc.. through an API as well. This data comes in quite handy when I'm building apps for basketball clubs.
If you do need custom data or logic, I recommend to follow the same convention, and expose your capabilities as API's as well. When integrating services into the UI at runtime, I recommend to provide packages with web components encapsulating the API calls, regardless if they are private or third party services. Then use a package manager during the build process to include them into the generated website. Similar for integration of data during the build process itself, each capability could expose an SDK package, with Dish pipeline sections, that can be included into the processing pipeline. This pipeline section then calls the API and renders the static HTML based on the data returned.
Exposing capabilities as API's, with accompanying components and SDK packages, ensures that the core principle of decoupling is being adhered to.
What would you like to hear about next?
Let me know in the comments what you think about my approach to building frontends, or what you would like to hear more about.