This is a guideline describing the technical strategy of Netlife Design AS moving forward from 2019 into the future. It aims at suggesting a stable and standardized path for all new projects in order to structure the way we work and improve our efficiency, our flexibility, our quality, our ability to maintain and the expertise we offer.
- We develop open source code and share whatever we can
- We follow the principles in the JAMstack, separating the frontend from the backend
- Our frontend applications are user oriented, written using the React framework
- We use headless CMS's solutions when we can (preferably Sanity, Craft or Enonic)
- Technical partners have 100% responsibility for the backend if any exist
- If other frontend technologies is pre-determined we deliver design or HTML/CSS/JS
Netlife believe in taking small steps for a better world. A consequence of the strategy is decoupling systems. What that really means is separating the different parts into individual components. We make it cheaper and simpler for our customers to replace one part of their solution. To replace us...
Netlife does not want to create lock-in situations where customers cannot afford to make the right decisions. We should deserve our customers. We want customers to turn to us because they want to improve or solve problems. We want to enable a fair world where we have to prove ourselves worthy to keep customers trust over time.
In any strategy there are considerations which limits the freedom and deciding power we can allow ourselves. There are areas which tech control fully and holly where we can, and should, own the domain and all the decisions within it. There are other areas where we share the domain with other stakeholders, and we need to share decisions. And lastly there are domains where we clearly do not own the domain, even if we work within it, and can only influence or suggest certain strategic goals. We need to be considerate to the people we work with, and respect that there are several sides to any coin.
A strategy can never be a perfect fit for every solution. Constraints and requirements can overrule a strategy where there is good cause. For this reason the rules and guidelines provided in this document needs to be general enough to support common use cases, open enough to inspire creativity and concrete enough to be of value.
The most typical scenario where the strategy does not align well with the requirement is a heavy content driven project where the customer want to be able to make major changes to the templates/view and/or control where content-blocks are placed in the view. Identifying and challenging this would be key to see if the suggested architecture and strategy is the best fit or not.
Nothing lasts. Similar to code and documentation a strategy begins to deteriorate as soon as its written. Everything will eventually change. Therefore there will never be a final version of this strategy, there will be only a current one waiting to be improved in order to fit the larger and current picture of the world as it might be.
As such it encourages everyone to opinionate, improve and suggest changes to this document. It's not supposed to be owned by one single entity, it is by nature a shared commodity in which we all align to and, as far as possible, agree on.
Rome was not built in a day. A strategy cannot be expected to be fruitful immediately. We must iteratively and slowly transition wherever we can. Our motivation should be to getting a small step closer every single day. But tech cannot do it alone as we are not separate from the rest of Netlife. We need the entire organisation to believe what we believe, our partners to align with our guidelines and hope to convince new and existing customers to embrace the brand new world.
There exists movements in the community which align well with the direction we are leaning internally. We are struggling with a certain set of repetative challenges like handovers, partners and missmatch between design and implementation. Aligning with the general directions and decisions proposed in this strategy would alleviate some of that pain, but needs to be done in a considerate and respectful manner to those afflicted by them.
Autonomy-, decoupling-, RESTful-, microservice-, DomainDrivenDesign- and abandonment of monolithic architecture- trends has been growing for quite a while, decoupling web applications (presentation separated from the backend) follows that same pattern. The maturing of SPA applications, Node/npm, GitHub, SEO requirements, SaaS cloud models and enriched tooling enable a new direction.
Headless options for new and existing CMS platforms are game changing. There are technical improvements which certainly can improve development experiences and delivery quality, however these are minor improvements compared to what headless offers to the table. And the list of platforms that are taking the headless approach is constantly growing (headlesscms.org).
One cannot for certain confirm that the term JAMstack originated from Mathias Biilmann at Netlify, but one can trace most of its push back to Netlify at least.
What the JAMstack (wtf?) propose is a high focus on the front end builds, eluding server-side functions as much as possible. The three major elements are:
Javascript on the client-side handling communication requests and responses. Although not limited to, front-end SPA frameworks like React fits this model well.
Server-side processes, including database handling, are accessed by JS-driven HTTP(s) calls. JAMstack is by default API and technology agnostic, communicating with all external sources over HTTP, caring about the data and structure only.
This term Markup again relate to an agnostic attitude towards creating or rendering sites users can actually see. This declaratively suggests using build tools and encourage the use of static site generator techniques.
One can argue wheather a true MVC (Model-view-controller) pattern can be achieved in web development, but the concepts of separating database logic (M), presentation logic (V) and application logic (c) are neatly built into how most web framework best-practice examples are structured.
Following the JAMstack path would as such enable the use of CDNs (or ADNs) hosting of static applications fully SEO optimized with high-availability and performance. Git-centric continuous deployment strategies through pushing changes. And it reduces security concerns greatly with removing the attack vectors of traditionally coupled systems (it does not remove it completely mind you). The proposed architecture would also fit in nicely with serverless BaaS function paradigms.
Every shift in direction come with benefits and disadvantages. It is important to understand and know about what these are so that we may face the consequences well prepared and in agreement. Hence the following sections outline how different areas are affected in a more direct manner. The benefits are greater than the drawbacks in a heuristic perspective, which is why the chapters are positively named.
The overall Netlife strategy aims at moving towards delivering more product and service oriented solutions. What that means is delivering more data-oriented applications as a supplement to our historically strong content-oriented application projects. The consequences of this could be to deliver web-applications with a whole range of different backends, including custom developed backends. Today most of our projects are content driven, often powered by a CMS. The strategy suggests a supplementary shift in that focus.
What service/product systems have in common is that they are highly interactive, are feature driven and where the datamodel and structure is often inherited from, or dependent on, external or existing systems. These schenarios typically have a separated frontend and backend. A great way to gain experience for coming projects would be to use these kinds of structures and architectures in areas with less risk. The proposed technical strategy aligns with our wanted market position and projects, proposed in our Netlife strategy.
There are disadvantages on the customer side. One is an increased setup cost for full stack applications which includes both a frontend and a backend. In a JAMstack architecture most customers without technical inhouse resources would find making big changes to templates or the presentation of content more difficult without expert help. Content and text by itself should not be a problem, but the ability to add a new page template and present that on their website is not done purely from the CMS, which is a disadvantage for semi advanced users.
It might even be the case that two separate solutions could possibly be delivered from two different companies. Contracts and formal support structures may have to be redefined or improved.
Benefits worth mentioning would be licensing and price. Most of the ecosystem (depending on platform of choice) offer very reasonable pricing models for quite extensive tooling and tech setup. It includes none of the drawbacks some architectures and stacks have on SEO. It enables a customer to choose, and replace, the frontend and backend seperately. Arguably the cost of an eventual migration will be significantly lower and easier to manage (or contain rather).
Due to separation of concern, it is safe to assume that once in place the JAMstack architecture will be a cheap and reliable solution. However, existing or already implemented CMS platforms could challenge, and even prevent, the optimal architecture for a given set of customers. There are legacy systems out there (we have even created many), and we need to transition slowly, if at all, depending on the customer. Hybrid solutions may be good alternatives to combine the best of both worlds.
A clear separation between the frontend and backend should make it easier to identify responsibility. Estimation and status for separate deliveries should also easier to understand and report on as the exchange currency is data, through defined endpoints. Is should improve collaboration and mandate in a more concise way than previously.
The most important beneficial effect however would be ownership and simplicity. No longer should uncertainty of handover and re-implementation of functional prototypes be an issue. Either Netlife deliver prototypes (typically in Figma or HTML) or the full frontend application.
The most important drawback would be that one side of a messy partnership needs to let go of a part of the solution, in other words release control of some of the revenue stream. If the parties are working in collaboration on the frontend, one side needs to let the other handle all of it or none of it.
Not everyone is as comfortable with this way of developing applications. A starting hurdle is to be expected as previous development styles, or habit. There will be a defining change in how we utilize a CMS, and how we would work in a scenario where we deliver both the backend and frontend. Some people may be exteremely skilled in how to setup a project in a spesific CMS and might now have to reinvent the most efficient way set up projects.
We would be required to work the same way, through the same architecture and the same methodology regardless of which parts of the stack we take responsibility for delivering.
Netlife will deliver the entire frontend of a solution, HTML/CSS prototypes or nothing at all. Gone are the days of developing an application which in the end is torn apart, cut to pieces and reimplemented into any given CMS templating engine. There should be no double implemenentation costs.
It will also be simpler to define and explain which CMS we could develop and configure internally, which we would always use a partner for the backend and which we won't support at all.
We will all be working on the same set of frontend technologies therefore the steep learning curve to understand and master every CMS specific templating engines would be greatly reduced. We should be highly effective and flexible in moving from one solution to the next in our roles as frontend developers.
When working with a defined subset of technologies and a set architecture we would specialize in them to a greater extent. It would also be natural to believe that fractions would form in terms of pure frontend, fullstack or CMS/backend developers would emerge. Some would want to be involved in several of these groups, some in perhaps only one of them which would ultimately help us becoming even more specialized. It opens a door where we increasingly would be able to share and contribute to the ecosystem. It might even prove to give us a unique standing in the technical community or if nothing else aquire high confidence and experience in what we are doing. Becoming masters of the art so to speak.
Another benefit would be simplicity in finding new talent in certain technologies. The cost and time of training and onboarding would be reduced, and new people would be able to create value earlier than before since the landscape one needs to master is smaller and more defined. The actual recruitment process would also be more direct and concise as we know exactly what kind of talent we are looking for, and provide transparent information of the technologies we are working with.
The amount of stuff we need to maintain and know decreases significantly because the sum of variations decrease over time. We can also streamline the tools and functions required to monitor, surveil and ensure high availability. It enables "one" standard way of deployment and a standard way to handle persistance.
Another benefit would be on the side of testing. Even if we can allow a multiture of tools to perform testing, the separation of front/back-end would standarize the way we test communication and build integrations.
Even if the strategy propose a clear path moving forward, there should be plenty of room to explore and innovate. The proposed strategy focuses mainly on a direction and does not eliminate new paths or future expansion of technology in the future. The industry evolve and changes daily, and we need to keep up. As our strategy must evolve as must our technical solutions.
Betting on a future of headless CMS, JAMstack architecture and high performing applications would long term put Netlife firmly on the map as technologists. Even if vendors, platforms and technologies go out of favor, we would be better able to adapt in an unknown future.
In the end we enable a more fair world where we have to prove ourselves worthy to keep the trust of our customers. And there is nothing in our technical strategy which does not align closely with the overlying Netlife strategy.
This section covers a more detailed look into some important domains to shed some light into spesific handling of these evaluating many stakeholders and perspectives.
As far as the customer goes, Netlife should be seen as a platform independent partner.
The domain of CMS does not really belong to tech. The choice of CMS platform should not be based on technical preference, although it most certainly should depend on technical requirements which can direct the choice. All CMS platforms have strengths and weaknesses. Some waknesses are too big, or so far from our strategy, that they are ruled out. But in the end the choice should be made based on the requirement of the administering users of our customer and the features we need to support.
Refusing to work with a certain CMS platform if the architecture aligns with our strategy, is simply put a folly on our part. We should not, and cannot dictate this choice, but we should provide honest and well meaning advice. There is just too much opportunity at stake, in a demanding market, to turn our back based on technical preference.
That is not to say we are to say yes to deliver anything on any platform, but we should be able to provide our customers excellent frontend web applications whenever we can, unless we explicitly have chosen not to.
This is a domain we share with others. As technologists we are merely translators of design, and we need to establish how to collaborate with others to achieve the best result should work. We want others to contribute with their expertise as efficiently as possible. We aim at being an extension of their work and complement others strengths.
Hence the technologies, frameworks and tools we utilize needs to consider collaboration. The same goes for choices of implementation style. We can suggest improvements and tools, and if successful we will sufficiently train and help others to be as efficient as possible when conducting their job, just as we would expect them to view our challenges and efforts.
- General
- Platforms
- JAMstack Sites Showcase
- Static Site Generators
- CMS
- API
- Serverless
- Videos
- Tutorials / Articles
- Podcasts
---
- JAMstack
- JAMstack resources - Videos and articles about JAMstack.
- the New Dynamic - Frikking awesome library of examples, tools and services.
- GitHub Pages - Website hosting from your GitHub repo.
- Netlify - All-in-one platform for automating modern web projects.
- ZEIT Now - All-in-one serverless platform for modern web apps with config-free tools and workflows.
- React - Built on Gatsby.
- Squoosh.app - Hosted on Netlify, demonstrates advanced features from a modern Web Application.
- Hopper - Built on Gatsby and hosted on Netlify.
- VSCode Power User Course - PWA built on Gatsby and hosted on Netlify.
- CloudyCam - PWA built on Next.js and hosted on Zeit Now v2 Serverless platform.
- Gatsby - Blazing-fast static site generator for React.
- Next.js - Lightweight framework for static and server-rendered applications.
- Metalsmith - An extremely simple, pluggable static site generator.
- eleventy - A simpler static site generator transforming various template files into HTML.
For a more complete list see StaticGen.
-
Contentful - Content infrastructure for digital teams.
-
NetlifyCMS - open source Git-based CMS.
-
Sanity - Headless CMS and Content API.
-
Headless Craft CMS - Element API and CraftQL alternatives introduction.
-
Headless Enonic XP - Graphql powered CMS API with Enonic.
-
Headlesss Hybrid Episerver CMS - headless decoupled CMS backend for frontend web development in Episerver.
- Auth0 - Single sign on and token based authentication.
- Netlify Identity - Brings a full suite of authentication functionality
- Disqus - Global comment system that improves discussion on websites and connects conversations across the web.
- Facebook Comments - The comments plugin lets people comment on content on your site using their Facebook account.
- Utterances - A lightweight comments widget built on GitHub issues. Use GitHub issues for blog comments, wiki pages and more.
- Netlify Forms - Built-in form handling on building time by parsing HTML files directly at deploy time.
- Flatmarket - Flatmarket is a free, open source e-commerce platform for static websites.
- GoCommerce - A headless e-commerce for JAMstack sites.
- Snipcart - A powerful shopping cart platform for developers.
- Moltin - eCommerce API for developers.
- Trolley - A shopping cart designed for the JAMstack.
- Algolia - The most reliable platform for building search into your business.
- Lunr - Search made simple (on frontend).
- CloudSh - Powerful search with a few lines of JavaScript.
- GraphQL - Query language for APIs and a runtime for fulfilling those queries with your existing data.
- MongoDB - Document-based distributed database for the cloud.
- Elastic - The ELK stack for infinite searching at scale.
- Netlify Functions - Netlify lets you deploy Lambda functions without an AWS account, and with function management handled directly within Netlify.
- Amazon Lambda - Lets you run code without provisioning or managing servers.
- Microsoft Azure
- Azure Functions - Serverless compute service that enables you to run code on-demand without having to explicitly provision or manage infrastructure.
- Azure Logic Apps - Simplifies building automated scalable workflows that integrate apps and data across cloud services and on-premises systems.
- Google Cloud
- App Engine - Serverless application that completely abstracts away infrastructure so you focus only on code.
- Cloud Functions - Serverless environment to build and connect cloud services.
- Cloud Datastore - Highly-scalable NoSQL database with automatic sharding and replication.
- Cloud Storage - Geo-redundant object storage for high QPS needs.
- Cloud Pub/Sub - Geo-redundant real-time messaging for all message sizes and velocities.
- Apigee - Enterprise API management for multi-cloud environments.
- Endpoints - API management apps built on Google Cloud.
- Cloud Dataflow - Serverless stream and batch data processing service.
- BigQuery - Serverless data warehousing services that help you to deploy advanced cloud data warehousing solutions for your enterprise.
- Cloud ML Engine - Serverless machine learning services that automatically scales built on custom Google hardware (Tensor Processing Units).
- Serverless - Toolkit for deploying and operating serverless architectures.
- Cloudinary - Serverless media (images/videos) management platform. Provides SDKs in every popular language and media widgets for JAMstack to make it easy to manage media, CDN, storage, transformations, and more.
For a more complete list see Awesome Serverless.
-
The New Front-end Stack. JavaScript, APIs and Markup - Matt Biilmann.
-
Rise of the JAMstack - Mathias Biillman.
-
Git-based or API-driven CMS - Chris Macrae.
-
JAMstack Tutorial - Full site using Netlify & Hugo - freeCodeCamp.org.
-
Gatsby JS Crash Course - Traversy Media.
-
How We Got Here and The Future of the Web - Kyle Mathews.
- Ghost on the JAMstack
- Getting Started with Gatsby and Cockpit — Part 1 of 2
- Creating Static E-commerce site with GatsbyJs
- For Static Sites, There’s No Excuse Not to Use a CDN
- E-commerce front-end for Vue.js, Nuxt.js and Snipcart
- Building Paul The Octopus
- JAMstack and Netlify: Do We really need another buzzword?
- The JAMstack Startup Landscape
- How I built my blog using Gatsby and Netlify
- Developer's Guide to Headless E-Commerce
- Handling Static Forms, Auth & Serverless Functions with Gatsby on Netlify
- JAMstack for Clients: Benefits, Static Site CMS, & Limitations
- Exploring Netlify CMS, a React & Git-Based Content Management System
- JAMstack PWA — Let’s Build a Polling App. with Gatsby.js, Firebase, and Styled-components Pt. 1
- Dynamic Static Sites with Netlify and iOS Shortcuts; Use Netlify Functions, a Gulp build process and iOS Shortcuts to publish dynamic content to your static site
- Gatsby for Apps
- Turning the Static Dynamic
- Going JAMstack with Netlify and Nuxt
- Getting Started With Gridsome
- The Complete Beginner's Guide to Deploying Your First Static Website to IPFS
- A Broad Discussion on JAMstack & E-Commerce (Podcast & Transcript)
Shoutout to Vilson Vieira (automata) for an awesome resource collection