DEV Community: Joost Jansky

Image Uploads with Blogody

Joost Jansky — Thu, 30 Sep 2021 21:36:33 +0000

I am really excited to announce a new integrated image upload feature today! You can start adding your local images the same way as public images — with zero configuration. All images you see in this article have been added that way.

Uploading Images

Here is a small demo that shows how to upload images in the editor. The new function is included in the side-menu that you can reach over the plus sign.

With this new feature, there is a small breaking change that you’ll get quickly accustomed with. The image icon (first icon in the figure below) was previously used for image links but it is now used for uploading images. The image link feature is still available under a new icon (second icon in the figure below) which better depicts the link nature.

I have been asked why image uploads was not part of the initial release and the answer is twofold. First, many people already have their images stored in the cloud and in this case it’s easier to just add a public link to the already existing image. This prevents image duplication and allows to include what people are already used to.

The second reason is that an image upload feature needs an image store and I wanted to take the time to find the best solution for Blogody. The chosen solution abstracts storage management away, so that you don’t need to think about the image store at all — everything is handled for you in the background.

Hosting images with Blogody

That’s right, when you upload an image it gets hosted on the Blogody platform. You can upload up to 500 images on the Free Plan and up to 10.000 images on the Pro Plan. Many media blog posts have one feature image and more image heavy posts typically have less than 5 images per article. That translates to more than 500 posts on the free and 2.000 posts on the pro tier.

Note that you can always include an unlimited number of image links , so that you can fully utilize the cloud storage that you booked elsewhere.

While this is plenty for many use cases, it’s probably not enough if you plan a dedicated photo blog. Once you reach one of the limits, you’ll get notified the next time you try to upload a new image:

Blogody image URLs and privacy

When you upload an image, the full image data is compressed and transferred to the platform storage. The editor immediately displays a preview image and transitions to the stored image once the upload is completed. The final image URL follows the following pattern:

https://assets.blogody.com/image/FrcZODKj5JCZM/your-image.png

The fixed part is followed by a random 13 character unique identifier. The image name is taken from the selected filename and slugified to improve search engine results. Thus, image links are designed to fulfill the following properties.

Links live on blogody.com for excellent domain authority.
Use a small identifier to get short URLs.
Optimized for search engines through the asset and image keywords and further improved by the slugified name.
Hard to discover if you don’t know the link.

The last property is important to give your image moderate privacy. Of course, once you publish your article, the link is public and everyone who can read your article can also access your image. Nonetheless, it’s hard to guess an image link _ before _ your article is published.

Search engine Optimization (SEO)

As described before, image links are automatically generated, so there is nothing for you to configure. However, you can improve search engine results by giving your images descriptive names. That no only helps search engines, it’s also a good idea when it comes to organizing images on your local computer.

Avoid giving images a generic name such as image1.jpg, image2.png, instead create the name from a short description such as: blogody-image-upload-demo.gif. This would result in the following URL:

https://assets.blogody.com/image/Az3BKFJt6EWCV/blogody-image-upload-demo.gif

You’ll get the idea: Use the image name to tell something about its content.

Image lifecycle on Blogody

As we saw earlier, images are uploaded to the platform whenever you add an image to your post or page. But what happens if you delete an image in the editor? It may surprise you that it stays on the platform and is still available. It’s been designed that way so you don’t need to upload the same image a second time if needed.

Internally, every uploaded image is connected to a post or page. That means all images associated with a post are deleted when you delete the post. The same is the case when you delete an entire project.

The described image lifecycle ensures that we don’t pile up images that are not needed anymore, but also ensures images are uploaded only when needed.

What’s next?

The new image upload feature is just the beginning of more image related functions in Blogody. It’s an important feature, because it opens the door for automatic image optimizations and cool image manipulations. Stay tuned for the next episode of working with images in Blogody.

This post was originally published at Blogody News on September 30, 2021.

How to work with images in Blogody

Joost Jansky — Fri, 17 Sep 2021 19:31:11 +0000

Images are currently not hosted on Blogody, which means they need to be stored on external cloud providers. This is exactly what many users are used to as they already store their images in the cloud and are not interested in moving them somewhere else.

You simply add a public link of your image and it gets embedded in your article. However, if you want to add an image that’s only locally available on your computer, you can’t just upload it to Blogody. You must upload it to your cloud storage first.

I am currently working on a new feature that will allow uploading images directly to Blogody. This will open exciting new possibilities for image transformations, optimizations and SEO.

This article focuses on how to best work with images in Blogody today and I’d like to start with the easiest way to add images by using the integrated Unsplash image library.

Add free Unsplash images

An Unsplash widget has been integrated into the Blogody editor that you can reach over the side-menu. Unsplash provides a stunning library of free images that are hosted on their own CDN for fast image loading speeds. See how easily you can embed new images:

The keyword search makes it easy to find images for almost any topic that you can think of. It’s really a professional tool - and once you watch out for the image attribution line at even the most reputable newspapers worldwide, you’ll see that many of them use exactly the same image library for their top news stories. You are definitely in good company!

Adding images with public URLs

While Unsplash gives you access to a wide variety of images, you may also want to to add images of your own. A screenshot you made, an image from your camera or one that you purchased from another image library such as istockphoto.

If these images are already accessible over a public URL (e.g. https://.../image.png), you can embed those right here in Blogody. There are a couple of different ways to do it — choose the method that feels most suitable for you.

Copy & Paste Image Link

If you have an public image link copied to your clipboard, you can add it over the side-menu by clicking the image icon, pasting the link and pressing enter. Here is an example with the following link: https://picsum.photos/seed/picsum/750/500 from another interesting image service that you can use to test it.

Drag & Drop images

Let’s say you have a website where your public image is already published and you want to embed an image from that site into a new article that you author in Blogody. In this case, I like to open another browser window and simply drag and drop the image to Blogody. See how it works in the following screencast.

Notice the different cursors? You can only drop the image when you see a cursor popping up when you hover your dragged image.

A really cool feature that you’ll love once you know how to use it is the so called gap cursor.

Drag & drop between content blocks

The gap cursor is the one that shows a horizontal line and it allows you to to insert images in between content blocks. While the above image is dropped on a regular cursor, here is an example that uses the gap cursor. Watch how to insert the image between the title and the paragraph although there is no empty line in between.

Copy & Paste images directly

If a website lets you select an image, you can usually copy the image directly (without copying the image link). All methods presented here also work within the Blogody editor. So I can showcase it directly here.

Select, copy and paste images in Blogody

Pro Tip: Use Ctrl + c and Ctrl + v to copy/paste for a faster alternative to using the above shown right-click context menus.

The direct copy/paste feature is not exclusive to images. You can actually copy/paste entire articles — including images — from other content editors or websites directly into Blogody.

Image Cloud Providers

All methods shown above have one thing in common: your image is already publicly available. A screenshot that you make on your computer or mobile, unless automatically synced with your cloud store, is usually not publicly accessible. Even if your images are already stored in the cloud, access restrictions are usually in place, so that it cannot be accessed publicly. Most providers allow you to generate public image URLs or create a public image folder.

Just in case you do not yet have your images in the cloud or have trouble making them publicly accessible, I am going to show the general workflow with one image provider that I use. There are many other options available, so please take some time before deciding which one you want to settle with. Here are some high level criteria you may want to consider:

reliability and reputation of the provider
speed and distribution of CDN (make sure images reside on a CDN)
costs (may not be easy to calculate)

Let’s start by making a screenshot, save it to the local disk and upload it to Cloudinary, the image provider that I chose for this demo.

Cloudinary image service

I am going to make a screenshot of my GitHub contribution graph, not very exciting but enough to demonstrate uploading images to Cloudinary. So the steps are as follows:

make a screenshot and save it to local disk (not shown)
upload the image to Cloudinary
copy public image link into Blogody

Thus, there is an extra step compared to the previous methods: uploading the image to the cloud provider. In addition to the public URL, Cloudinary gives you a fast CDN and a rich set of transformation tools. That in itself might be worth checking out.

Final notes

Congrats for following through this guide about working with images in Blogody 🎉. The most important take-away is that your images must be publicly available before you can add them to your posts or pages in Blogody.

As mentioned above, a new image upload feature is in the pipeline and it will make adding local images much easier. Nonetheless, hosting images with an image cloud provider may still be of interest to you as it can be a great way to store, organize and enhance your images.

Anything you want to share with me about your experience when it comes to working with images? Just use the Feedback button in Blogody and shoot me a message.

This post was originally published at Blogody News on September 17, 2021.

How to export your Blogody blogs

Joost Jansky — Thu, 26 Aug 2021 21:31:29 +0000

Blogody is different than most other service platforms in that it obsessively cares about your content rights. The slogan “You own your own words” has been well chosen to reflect the commitment to give you absolutely full control over you data.

This promise applies to your published content, and equally important, it means that I do everything so that you can access and reuse your content just as you like. No barriers and no vendor lock-ins. That’s why I am delighted to announce a new export feature today.

Blogody export feature

This feature is now available on all plans, including the Free Plan. To test it out, just go to Settings -> Export and press the Export button. This will generate a JSON file and initiate a file download in your browser.

The export works on a per-project basis, which means that the file contains all the data associated with the currently active project. To export another project, just switch to that project and repeat the steps outlined above.

What data is exported?

In short, all the data that you created in Blogody, from settings to posts and pages. The JSON key fields represent the different categories. The file is structured as follows:

{
   blogody: { ... },
   settings: { ... },
   tags: [ ... ],
   authors: [ ... ],
   posts: [ ... ],
   pages: [ ... ],
}

The first blogody section contains some meta data about the export, mainly the project name, exporter version and timestamp. The other sections contain the actual data that you created in Blogody.

Why JSON?

I have chosen JSON as the export format for the following reasons:

it’s an open industry standard that is technology agnostic,
it’s human readable (in contrast to a binary file),
it’s lightweight and produces smaller file sizes than other formats.

These properties make it a perfect choice for Blogody. That said, I do recognize that you may want to work with other formats. That’s, of course, possible by converting the JSON to your desired format. I’ll discuss one of these possible conversions further below.

Your sensitive data remains protected

For security reasons, your API tokens are not included in the export file. Access to your tokens will always remain in the platform interface in order to protect you from accidental proliferation of secrets.

Note that your Google Measurement ID is included in the file. Everyone who visits your site can see this ID, that’s why it is not considered sensitive information.

Blogody API Export

If you are a developer and want to access Blogody programmatically, we have you covered as well. This feature is currently available for all users on the Pro Plan.

All the data that is exported into the above mentioned JSON file, can also be fetched directly from the API. You can either directly introspect and use the GraphQL API or use the Blogody API Client.

As exporting data is such a common use case, I’ve also build an open-source package @blogody/export that you can use to produce different output formats. Currently it supports generating a JSON file containing all data.

To showcase the power of the API and because some users requested an easy method to generate Markdown, the exporter lets you convert your posts and pages into Markdown as an alternative to HTML.

Conclusions

The new export feature — although small — is another milestone in delivering data sovereignty to all users. When you create your articles with Blogody, your data remains under your full control. Making it easy for you to access your data, so that you can do everything with it as you like, continues to be one of Blogody’s top priorities.

This post was originally published at Blogody News on August 26, 2021.

Google Analytics + Blogody

Joost Jansky — Thu, 26 Aug 2021 21:19:45 +0000

A new Google Analytics integration feature has been added to Blogody today. Just log on to your Blogody account and you’ll find the new integration under Settings > Analytics. That’s the beauty of Software as a Service: no need to worry about updating or installing anything — new features are instantly available to you.

Google Analytics is the most widely used web analytics service on the web. The new Blogody integration allows you to track page views, user scroll, outbound clicks and other user engagements. The only prerequisite is a free Google Analytics account. The following six, easy-to-follow steps show how to create a new Google measurement ID and use it in Blogody to start tracking your site.

Note that you can track different Blogody blogs individually with different measurement IDs.

Step 1: Navigate to your Analytics Dashboard

I assume that you have already created a Google Account and are able to log on to your Google Analytics dashboard. For your Blogody blog, you’ll typically want to create a new analytics view. This is done by creating a new account (not to be confused with your Google Analytics account that you earlier logged on to).

Step 2: Create a new account

Click on the gear icon in the lower left corner of your dashboard which opens the Admin section. This is the place where you create a new account.

After clicking the Create Account button, you’ll see a new setup view, where you need to give your account a new name:

That’s the only information required on this page, but it’s interesting to spend a minute to review the Account Data Sharing settings. The settings do not influence your traffic measurement, but they do influence what data Google is allowed to share with others (including its own services).

Best privacy is achieved by deactivating all checkboxes in the section entitled account data sharing settings.

Click the Next button when your are done on this page.

Step 3: Create a new property

As long as you do not need to use different data sharing settings, you can have one account for all your web sites. You can separate your sites through *properties *as an account can contain one or more properties. Thus, your *property name *should represent the website or blog that you want to measure.

Optionally, you can set your timezone and local currency. Advanced settings are only for legacy options and can be ignored. Click Next to get to the next view where you are asked to provide your business information. This section does not need to be filled out and can be left empty. Just make sure to click the Create button at the end and accept the terms.

Step 4: Create a data stream

The Google set up flow redirects you to the Data Streams section which is part of your newly created property. To start collecting data for your blog, you must choose the web platform:

Fill in the blog URL which can be either your blogody.com domain (e.g. of the form https://subdomain.blogody.com) or your custom domain, if you configured one in Blogody.

The stream name serves a stream identifier and can be chosen arbitrarily. It’s a good idea is to take the subdomain for your stream name. Finally, hit the *Create stream *button.

Step 5: Disable history events

As you can see, a measurement ID has been created. That is the token you need to add to your blog in the Blogody platform. Before we do so, you must deactivate history event detection, otherwise you will get incorrect measurement results.

Click on the gear icon and a side menu opens. The history events options is hidden under advanced settings:

Deselect Page changes based on browser history events *and press Save.*

Blogody is build on NextJS which has a pushState in place for state management purposes. This push populates the history stack and would cause an additional page view fired if you leave the history event option toggled on.

Step 6: Add your measurement ID to Blogody

Finally, you can connect the generated measurement ID to your blog. Copy the ID to your clipboard, in the above example it would be G-ER92JRD0S5.

Log into your Blogody account, choose the blog project you want to start tracking and add the measurment ID under Settings > Analytics > Google Analytics as shown below.

Now everything is set up and you can start monitoring your analytics data 🎉

What’s next?

Are you looking for another integration or favor another analytics provider? Send me a message via the Feedback button in Blogody and let me know!

This post was originally published at Blogody News on August 18, 2021.

Blogody API Client 🔥

Joost Jansky — Thu, 26 Aug 2021 21:08:08 +0000

The Blogody API Client makes pulling data from headless Blogody a breeze. It serves two major purposes: easy data fetching from Blogody into your JavaScript/TypeScript projects and demonstrating the use of the Blogody GraphQL interface.

I am excited to release the Blogody API Client today on a free open-source license. It is for developers who want to programmatically fetch data from Blogody. The API client is a tiny, isomorphic TypeScript package that communicates with Blogody over it’s built-in GraphQL interface.

Note that there will be other export mechanisms coming to Blogody soon, that don’t require any programming skills. However, if you like to play around with code, you can use this client to backup your published articles, feed other systems or even make your own front-end theme. There are so many possibilities!

You need to be on the Blogody Pro Plan in order to be able to use the API

Prerequisites

I assume that you are familiar with Javascript/TypeScript and know how to write code that can be executed with NodeJS or in the browser. First you need to install the client from npm:

yarn add @blogody/api-client

This will download the package from npm and add the client to your package.json file.

Example Usage

Using the package and fetching data is dead simple. After importing the BlogodyAPI class, you simply instantiate it with your API key. You can then call the async functions like api.settings() or api.posts() to fetch the data.

import { BlogodyAPI } from '@blogody/api-client'

const api = new BlogodyAPI({ key: 'YOUR BLOGODY API ACCESS KEY' })

// make an API calls
const settings = await api.settings()
const posts = await api.posts()

console.log(posts)

There are many more functions available, so you can fetch authors and tags as well. As the client is written in TypeScript all available functions and options are shown to you when you hover in an editor that supports intelisense.

Where to find the API key?

You need to generate your key in Blogody under Settings -> Developers:

Substitute YOUR BLOGODY API ACCESS KEY in the above code snippet with the newly generated key.

What’s next?

Let me know if you have created something cool with it and I’ll be more than happy to share with the world.

This post was originally published at Blogody News on August 11, 2021.

On-demand Static Regeneration: How Blogody serves multi-zone blog sites

Joost Jansky — Sun, 16 May 2021 15:38:00 +0000

Never heard of On-demand Static Regeneration, or OSR? No wonder! It's a new acronym that we invented for this article in order to describe an exciting new evolution of how we can generate and publish blazing fast static web sites on the web.

There is currently a lot of heated debate about new ways of building Jamstack sites, with new approaches that are called beyond Jamstack, hybrid web development or hybrid serverless + static.

In this article, I am introducing a new addition to the existing hybrid approaches, that I call On-demand Static Regeneration (OSR).

On-demand Static Regeneration

OSR is based on Incremental Static Regeneration (ISR) that was invented by NextJS. Consider a web page that has not been statically built. With ISR, the first visitor sees a fallback page, for example a skeleton of the real site. The cool thing about ISR is that this first request triggers a static regeneration , which means all subsequent requests receive a fully built static site.

On-demand Static Regeneration is an extension to that process, in that the first request is not made by a visitor, it is automatically triggered by a web hook. We'll see later in this article, that there are always natural events that can be used as a trigger.

In effect, every visitor to your site always receives a static built, blazing fast, up-to-date site.

Before going into more details, let's take a step back and put everything into context.

Jamstack & Static Site Generation

The modern way to build websites that deliver blazing fast performance is based on the so called Jamstack architecture. It's main conceptional principles can be summarized as follows:

Decouple the front-end from the back-end.
Build as much as possible up-front through static site generation (SSG).
Publish to the content-delivery-network (CDN), so it serves your content as pre-built assets.

This approach is fundamentally different from a traditional web server, where web sites are rendered on every page request (SSR). A page that is SSR rendered cannot be put on a fast CDN edge.

That's why static site generators (SSG) have become so popular: pre-built content can be distributed globally through a CDN and serve pages from edge gateways closest to where you are requesting the site. This allows for a much faster user experience and has a positive effect on Google page rankings.

Atomic & Immutable Deployments

While the previously outlined Jamstack principles do not say anything about the deployment process, most CDN providers use the method of atomic deployments similar to Git commits. This means the entire site (code, assets, and configuration) is updated together at the same time.

Atomic deployments are immutable with sealed content and guaranteed integrity. Every atomic deployment gets an identifier that's never going to change. Any update will therefore produce a new deployment, similar to state-driven development where any change produces a new state in your application.

Why would you want atomic and immutable deployments? It allows you instantly rollback your site to a previous state without the need to re-build your site. For example, when you discover a mistake on your site after deployment, be it a typo or mixed-up brand color, you can instantly revert back to your any of your previous deploys. It's as easy as a git reset.

Static Sites with Dynamic Content

While pure static sites have their use cases, most web sites need some app-like features, that is, dynamic changes during runtime. A simple example for such a dynamic feature would be the number of likes of an article. Of course, you can statically re-build your site on a pre-defined schedule, but it's much nicer if the user giving a like, instantly sees it updated on the website.

Dynamic runtime features of this kind are possible even with SSG, namely by utilizing client-side JavaScript code. When a user clicks the like button, it fires an event to a backend-API which updates the number of likes in the database. The client subsequently re-fetches the data to be displayed on the web site.

While your deployment stays immutable as such, the content presented to the user (including the number of likes) is not defined by the unique deployment identifier anymore. It's total state now also depends upon the current state of your database.

In this contrived example, this is probably exactly what you want: Even when reverting to a previous deployment, you certainly wish the site to show the latest number of likes. However, the more app-like content you introduce into your site, the more it looses the property pf immutability.

If your web site uses app-like features with client-side dynamic content, atomic and immutable deployments do not guarantee an immutable web site.

The take-away from these examples is that the total state of an app-like static web site is governed by both your deployment state and the dynamic back-end states resulting in a combined state that cannot be controlled by a unique identifier. As such, supercharged Jamstack sites break that model of immutability to the degree of integrated app-like features.

Static Site Generation Drawbacks

When you read about all the benefits of the Jamstack and static site generators, its drawbacks are easily overlooked. One of the very early criticisms has been missing dynamic features, but this limitation is easily overcome with supercharging your site with JavaScript + APIs, although it does mean you need to loosen up the property of immutability as we saw earlier.

Another drawback of pure static site builders is the time it takes to build an entire web site. While this is certainly not a problem for a handful of pages, it becomes near impossible to re-build a web site with thousands of pages, especially if paired with image optimizations.

GatsbyJS' answer to this problem is called Incremental Builds, the idea being that you only re-build sites that changed since last deployment. While the idea sounds simple enough, it's a non-trivial task to assess possible dependencies between your pages and the GatsbyJS incremental build feature turned out very flaky (I was among the first users, so I hope it has improved by now). In principle, atomic deployments can be retained with this technique.

Apart from the stability issues that may be overcome in the future, incremental builds have another, more severe drawback: It doesn't give you any benefit when you build your site for the first time. Depending on your site, it can take many hours to complete. Just imagine, you'll find a bug in between that initial build process. Only subsequent builds can leverage the previous build process.

With all the recent advances of pure static site builders one challenge still remains: Building large web sites with many pages and heavy assets (images, videos, etc.) for the first time is an extremely time consuming process.

Incremental Static Regeneration

While incremental builds need a first static build, NextJS came up with another clever idea. Incremental Static Regeneration (ISR) extends the power of static sites with traditional server-side rendering (SSR).

Instead of starting with a full static build, you start with a handful, critical static pages. This gives you more control over the initial build times.

Whenever a user requests a pre-build static page, it'll receive a super fast static web site. But what happens, if the page has not been pre-build? In this case NextJS will use SSR to render the page for you, but in the background it will fire a static-site generation of the same page, so all subsequent visits to the same page will result in serving a static site again. Note that it is only the very first user that triggers the regeneration and that all subsequent visitors will see the static page.

This approach is called hybrid, because you (nearly) get the performance benefits of pure static site builders combined with the power of fully dynamic SSR sites.

Distributed Persistent Rendering

Recently, Cassidy Williams (Netlify) has criticized the ISR approach in article entitled Incremental Static Regeneration: Its Benefits and Its Flaws. While she acknowledges the benefits of ISR, the main argument against it is that ISR breaks the model of immutable deployments.

If you read the argument carefully, you'll find out that it does not go against the core idea of ISR, it simply points towards the difficulty of purging the cache when you loose the property of immutable deployments.

While I agree that this is a difficult problem to solve, I do think this can be overcome and I am pretty sure Netlify has something up in their sleeve that is soon to be announced. My bet is that the newly introduced concept of Distributed Persistent Rendering (DPR) that Matt Billmann talked about in Smashing Magazine just a few days ago, plays a fundamental role in tackling those challenges.

On-demand Static Regeneration

How does On-demand Static Regeneration fit into this landscape? It solves the following two challenges:

All visitors always get a super-fast statically built site.
There are no up-front static built times, deploys complete within seconds.

Too good to be true, what's the catch? First and foremost your deploys loose the property of immutability. Formally, immutability still exists for a single deployment, but as your deployment only consists of skeleton pages, its benefits have become only of minor importance.

Thus, the state of your web site is governed mainly by the state of your database, which holds the content from which the static pages are generated on-demand.

Let's take a look into how OSR achieves near zero deploy times. The skeleton pages do not contain much content, that's why a deploy can be so fast. The burden on generating static sites has been split into many small pieces (pages) and spread over a larger time-span. In contrast to ISR, regeneration does not occur on first visitor request, for OSR it occurs on _ creation time. _

Creation time is the first event when your content is ready to be shown to the world. For a blog article, it is the time when you hit the publish button and that's when OSR sends an automatic first request to your new or updated page, effectively regenerating your static site.

If you sum up all the regeneration times of all the web pages of a web site it should equal the build times of a static site generator that builds all sites in a single build step. However, due to slicing your page into smaller units (i.e. pages) and spread the build process over time (i.e. creation times), you easily overcome the static build walls present in traditional static site builders.

Multi-Zone On-demand Static Regeneration

While OSR has come immediately to my mind when I first learned about ISR, there was still one technical challenge that I was not able to overcome easily.

For Blogody, the new SaaS blogging platform I am currently creating, I need a multi-zone set-up, also known as a multi-host or multi-tenant architecture. Users of this platform will receive a dedicated sub-domain for every blog they are creating.

For example, one user may have a blog on https://eager-einstein.blogody.com, another user on https://vibrant-williams.blogody.com. Thus, blog pages are organized on different subdomains. As user's can create new blogs all the time, those subdomains are not known up-front.

The problem is that NextJS static site generation functions do not capture the subdomains, or host information. While you can use OSR techniques to regenerate sites, I couldn't find a way to fetch data based on the varying subdomains. Of course, you could make a new deployment for every new subdomain created in the back-end, but this would let the number of deployments explode: not a scalable solution.

Luckily, NextJS made rewrites more flexible in the latest 10.2 release. I didn't notice the power of these additions until Anthony Corcutt demonstrated in an open-source example, how the host information can be mapped into paths with rewrites.

Once your static build functions can grab the subdomain info, combining it with OSR is easy.

Summary

By integrating the latest hybrid approaches of building modern web sites into an event driven content workflow, and thanks to the more flexible rewrite capabilities of NextJS, it is now possible to deliver on-demand static regeneration on multi-zone sites.

The benefits are striking: Always up-to-date, flaring fast static sites that can be served globally from the CDN edge.

Interested to learn more about Blogody? Just sign-up to get notified.

Building a Rich-Text Editor for Modern Publishers

Joost Jansky — Fri, 30 Apr 2021 21:13:47 +0000

An inside look into the making of a flexible Rich-Text editor that will be shipped as an integral part of Blogody - the new blogging platform I am building. It's been a bumpy path to choose the editor technology best suited for modern publishers. Sneak preview into the final result...

If you are like most people in this digital age, you use text editors every day and more likely every other minute. Just a quick message to your friend, an email to your colleague or a document for your boss: most electronic text is written with an editor.

The ubiquity of editors may lead you to believe that you are dealing with fairly simple technology, but that's far from reality. The illusion of a smooth, natural feeling editor experience can only be created by an extremely advanced piece of technology that takes all possible user interactions into account while remaining extremely fast and amazingly responsive.

Photo by Domenico Loia / Unsplash

This is even more true for web editors, which need to deal with different browser technologies, alleviate their quirks, compensate slow network speeds and silently master all state and user interaction intricacies.

Modern writers and publishers demand an editor that produces clean, semantically meaningful documents, that let them focus on writing and article composition. The best editors of this trade are the ones that are not overly rigid but still use some constraints that don't feel constraining for that specific use case. These editors artfully bridge the gap between unambiguous and rigid Markdown editors and full-fledged WYSIWYG editors.

Rich-text editors for the web

Picking the right editor technology for the web is not easy. As the browser understands JavaScript natively, the editor should be written in that language or in a framework like React that uses JavaScript under the hood. While there are a number of open-source editor frameworks available, it still surprises me how much work you need to put into building a great an meaningful editor in 2021.

For Blogody, I required primitive building blocks to be included by the framework and the ability to customize the editor to match exactly the main target group: modern content publishers and writers.

Photo by Marcella Marcella / Unsplash

I started by looking at the König editor from Ghost because it is available open-source. It uses Mobiledoc in connection with EmberJS. There is also a React Mobiledoc variant that I intended to use, but the König editor turned out to be too tightly coupled to EmberJS and the Ghost's NodeJS Admin interface. I figured, that carving it out would require more work than starting anew. Starting from scratch also gives me more freedom to choose a better technology stack from the get-go.

As Blogody is built with React, a more sensible choice would be to look for a native React editor framework. That's how I got to know Slate which was recommended to me by one of the full-stack developers at Republik, a renown Swiss online newspaper. Slate looked very promising, with clear principles, a vibrant open-source community and outstanding React integration. Inspired by the success stories from the Republik team, I spent more than one month building a new editor based on Slate.

While I still think Slate has the best React interface, it turned out to be lacking in some unexpected ways: when you need to construct sensible boundaries for primitive elements, you don't get much tooling. For example, if you want to ensure a picture element is always followed by a paragraph, you have do define that yourself in a so called normalizer function. While this is possible, you'll soon find out that you need to develop a content schema from scratch, not something easily done over a weekend. What turned out to be even more surprising for me: pasting long documents would freeze the UI for more than seven seconds on a fast desktop computer. That's when I literally lost patience with Slate.

If you ever need to pick an editor framework for one of your own projects, the following advice would have saved me a lot of time:

Before you decide for a technology, make some simple end-user tests with demanding test data. For an editor, copy & paste large amounts of text, write text with high speeds, etc. and see if it the technology can still impress you when stressed.

Entering ProseMirror

With these findings, I found myself back on square zero. Is a slow editor the price for getting seamless React integration? Are there alternatives out there which I didn't come across yet?

While looking further around, I stumbled upon an article about ProseMirror, another highly acclaimed editor framework used in the digital news room of the New Your Times. Open-sourced with a more traditional yet helpful forum community, thoroughly maintained by the creator and master mind. The project is supported by some well-known companies, so it captured my attention. First end-user tests showed stunning performance characteristics. The above mentioned example that took over seven seconds in Slate would complete in 150 milliseconds in ProseMirror - which immediately electrified me.

There was just one problem with ProseMirror. How could I possibly integrate ProseMirror into the Blogody React app? All ProseMirror-React boilerplate implementations I found looked really complicated and I hardly understood what they were doing: Communicating state between React and ProseMirror neither seemed to be straight forward nor easy.

With some help from people of the the ProseMirror forum community I started with trying to make a simple React bridge. Firsts steps were really difficult and I was constantly thinking of dropping out from that experiment. How much time would I need to get even simple things working, like integrating a simple paragraph React component?

While I learned a lot about all the ProseMirror lego pieces and the well designed interfaces that you can hook into, I had almost abandoned ProseMirror when I was suddenly struck by a sparkling idea:

Let ProseMirror handle primitive elements like paragraphs, figures, etc. with its native JavaScript framework and use React only for interactive overlay elements, such as hover-bars or drop-down menus.

With this clear conceptional distinction, I was able to make progress much faster and secure ProseMirror's nice performance characteristics while being able to integrate the editor into the main React app.

Looking back after another month, I am convinced that this was finally the right choice. ProseMirror is extremely efficient in handling the basic editor elements, it is easily extended with a plugin approach and ensures document integrity with a flexible schema design system. Furthermore it allows me to amend it with complex React overlay components through my custom built React bridge.

Itching to see some demo results? Here we go.

Hover toolbar

I have always been a fan of contextual toolbars that offer exactly the editing choices that make sense at this very moment. Just select some text and an inline formatting toolbar opens:

Side menu

A side menu lets you insert block level content, such as horizontal lines or images. A plus button will show up on every new line as you can see below:

Keyboard Shortcuts

One of the early design goals for the Blogody editor has been to make the keyboard a first class input method. While every action can be invoked with your mouse, the keyboard is an equally good alternative.

Ctrl + b toggles the selection bold.
Ctrl + i toggles the selection italic.
Ctrl + backtick toggles the selection inline code.
Ctrl Shift + 1...3 changes the text-block to heading at a level.
Ctrl Shift + 8 wraps the selection in an ordered list.
Ctrl Shift + 9 wraps the selection in a bullet list.

Input Rules

You can also use Markdown inspired input rules. The side-menu can always be opened by pressing / and you can move the current selection with your arrow keys, confirm with Enter or leave with Esc.

The following screen-cast demonstrates how easy it is to structure your text without leaving the keyboard:

# followed by a space, to start the line as a heading.
## followed by a space, to start the line a sub-heading.
### followed by a space, to make the line a sub-sub-heading.
- or * followed by a space, to create a bullet list.
1. followed by a space, to create an ordered list.
> followed by a space, to create a quote.
3 backticks: to create a code block.

Unsplash Widget

More complex features are also possible with the ProseMirror React bridge. I have partnered with Unsplash to be able to integrate a royalty-free image picker into the Blogody editor:

Summary

Blogody's richt-text editor is ideally suited for the modern web and will help writers and publishers focus on producing stunning content for their audience. Powered by ProseMirror under the hood, the editor is extremely stable and fast. With the newly developed React bridge for Blogody, even complex widgets like the Unsplash image picker are easily integrated and you can expect more eye-catching features coming in future Blogody releases.

Do you want early access to Blogody, the brand new blogging platform that I am creating? Just sign-up on the new Blogody landing page and be among the first to get notified!

This post was originally published at Jamify.org on April 30, 2021.

Blogody - Tune into the melody of a new blogging platform

Joost Jansky — Sat, 13 Mar 2021 17:07:20 +0000

It's official now. The new blogging platform that I am creating is called Blogody. Learn how I came up with that name and what might help you in creating great names for your own product ideas.

When I announced creating a new blogging platform early this year, the name for the new platform was still up in the air. Coming up with a sticky name that gives you an idea about the product's intend is not that easy.

Want to get early access to Blogody? Just sign-up on the new Blogody landing page and be the first to get notified.

You can pay thousands of dollars for a professional marketing firm just to come up with a single product name. Is it worth that money? Probably yes. Do you need to pay that much? Probably not.

How to find the best product name?

If you ever searched for a good name for a product idea or website, you may have experienced that feeling of unlimited possibilities that make it so hard to pick exactly the right one.

Photo by Kristian Strand / Unsplash

This can be a limiting thought, and that's why I started with a little mind hack:

There is no single best name. You don't pick the best, you just pick the one that best fits your criteria.

While I do think _ Blogody _ is just the perfect name after all, I also know there are hundreds of other names that would fit equally good. With this golden rule, I deliberately shift my focus from the only one to the one that best fits my search criteria.

A trustworthy top level domain name

As the blogging platform needs a dedicated domain name, I want the name to be available on one of the most credible top level domains. You can make your own research about domain credibility, but to cut things short, the number one is still .com. It's also the one most people would search for, if they had forgotten the full domain name.

Photo by jesus luna71 / Unsplash

With the explosion of websites I know it's hard to find a free .com address as so many combinations are already taken. On the other hand, it also helps me eliminating possible choices, which leads to my second rule of thumb:

The name must be available for the .com top level domain. This likely means the name must be an artificial name, because common dictionary words are usually taken already.

Okay, making rules is fun, but how does that bring me closer to a name? I need some name ideas first in order to be able to test if they are available on the .com domain.

Brainstorm for name snippet

As the platform is about creating blogs, it would be cool if the product name includes "blog" in it.

Photo by David Maier / Unsplash

This is the point where I write down a word list with words related to "blog":

blog
write
publish
text
...

A keyword search is also a good tactic at this point. As I know this will be only one part of the final word, I want to go with the most obvious word that is also the shortest possible. Like for .com before, blog sticks out both in terms of being to the point and in terms of shortness. This rule can be summarized as follows:

Find a short word that characterizes your product. Use it as a first step in composing the final name.

Fixing the maximum character length

I would always prefer a shorter name over a longer one, at least if the short one is also easy to memorize. Looking at big tech company names, such as Google, Amazon or Twitter a name with a maximum of 7 characters would be ideal.

Photo by Anne Nygård / Unsplash

I have seen great long names too, but let's be a bit ambitious here:

The final name should be 7 characters or less. No one likes to type long names.

With 4 characters already taken, we are only left with 3 remaining characters. You can do the math, with 26 possible charterers of the English alphabet, you have limited your possibilities to 26 to the power of 3 = 17.576 combinations. Not millions, but still quite a lot of possibilities.

Choose sensible character constraints

Among the 3 possible characters, I want at least one vowel, preferably one that is already in "blog", which would be an "o". Why? because vowel repetition usually leads to nice sounding words.

Photo by Kelly Sikkema / Unsplash

This choice reduces the number of possibilities to 678.

Narrow your possibilities with some meaningful character constraints.

While you can now write a computer program that generates all 678 words and then limit the ones for which there is a ".com" domain available, I started to make a new word list with ones that came to my mind immediately

blogost
blogrod
blogido
...

I usually type those directly in a domain search system, to see if they are available. This last step can be a bit frustrating, because most choices were taken already... until I finally got a satisfactory hit with

blogody.com

Google Search on Blogody

The name is great, but what other websites exist with the same name? I do not want other high ranking blogging platforms to collide with that name.

It turns out that when you type "Blogody" into a Google search, there is not one with an exact match:

This is great, because it is not occupied with similar content.

Falling in love with a name

While the described strategy of choosing a name seems quite technical, there is still a lot of creativity involved when testing the different variants. The system mostly helps in narrowing your possible choices but still leaves you with a large amount of names to choose from.

Photo by Alex Block / Unsplash

So, what makes _ Blogody _ the best name of all the variants that I considered? First and foremost, I like the sound of the the name. It rimes with Melody, Rhapsody and a lot of other melodic words.

It is short, easy to pronounce and remember, gives hindsight to the product value and is available on the highest ranking top level domain: Lovely!

Names are likely overrated

After the initial excitement it's important to touch base again. After all, the best name does not make a good product. So, it's important to focus on the product again, such that it fills the great sounding name with a resonating product.

Interested to learn more about Blogody? Just sign-up to get notified.

This post was originally published at jamify.org on March 13, 2021.

Creating a new blogging platform

Joost Jansky — Sat, 09 Jan 2021 23:30:13 +0000

I am going to create a new blogging platform in 2021! It will allow publishing articles with Jamstack benefits built in: namely extremely secure and blazing fast sites.

Want to get early access to Blogody? Just sign-up on the new Blogody landing page and be the first to get notified.

No code or development skills needed. For publishers who want to focus on writing and care about their content ownership.

About year ago, I got fascinated by the Jamstack approach of building blogs and websites. Just pick a headless content management system (CMS) of your liking, turn it into a static site and serve it globally from a content delivery network (CDN edge). Publishing content this way is more secure, extremely flexible and produces super fast sites with low maintenance costs.

This approach inspired building the Jamify static site generator based on NextJS, which rapidly transforms your content from a headless Ghost CMS into a flaring fast site.

This site can be globally served from a CDN provider such as Vercel or Netlify. I got really nice feedback from both contributors and users , so I am truly excited to support and improve the open-source Jamify tools.

As a web creator and developer, I always envision something better and I realize that the Jamify tools appeal mostly to developers and tech-savvy people. That does not come as a surprise. In order to appreciate the benefits of the Jamstack, you must bring an understanding of how the web works. Furthermore, you must be comfortable with using git(hub), setting up developer tools, installing packages and compiling code. It got me thinking:

How can the Jamstack benefits for content publishing be made available to a wider audience?

After trying many different platforms, I am convinced that a new, independent blogging platform must be invented in order to bring the Jamstack benefits to all article publishers.

Existing blogging platforms

When it comes to blogging platforms, WordPress is by far the most popular content management system holding 60% of the market share. This translates to a stunning 33% share of all the websites online. With popularity comes a lot of complexity most people don't need.

It may sound paradoxical, but the most popular system is most likely a system that does not fit your needs the best way possible.

Why? Because, a widely used system tends to grow in complexity and must try to find the least common denominator.

Admittedly, I am not the first one to realize this opportunity and that's why you can find many other blogging systems, each with it's own benefits and drawbacks.

However, as the Jamstack is a relatively new approach and still mostly targeting developers, there is potential for a new blogging platform in 2021 that integrates those benefits and at the same time hides the complexities from the end users.

The benefits of a new platform

With so many choices available, establishing a new blogging system is completely naïve. Yet, I will just do it for the fun of it! So, I am going to share my vision with you here. The new blogging platform should stand out in the following four areas:

CDN performance : Producing the fastest sites on the planet.
Ease of use : Intuitive design focused on writing.
Own your articles : Don't pay with your content, pay a small platform fee instead.
Syndication : Made dead simple.

In other words, the new system should produce optimized, blazing fast sites similar to next-cms-ghost, but not require any developer skills or tools. The system should be as easy to use as Medium, but without giving away your publication rights or other meta data to third parties.

Syndication will not be part of the first release, but will be an important long term goal: as syndication is most crucial for making your content discoverable on the web, it should be better supported here than elsewhere.

A minimalistic system

The most important and difficult part is to start out really small, yet with a useful system that can be easily extended. I already have a number of useful React components scattered around various projects that I can easily tap into, but I do know the complexities involved.

For a project like this, it's important not to get intimidated by existing systems and the set of features they now offer. I truly believe that the tools for building a SaaS application in 2021 are so much more effective than the legacy tools used in Wordpess and alike (if you ever tried to install Wordpress on your own computer, this may resonate with you). Which brings me to the tech stack.

The core technologies the blogging platform will be based upon are:

NextJS for the platform (an exceptional React framework)
Tailwind CSS for styling
Slate for the editor component
PostgreSQL for the database

The platform will be hosted on Vercel as it supports Next.js perfectly. While the platform itself will not be open-source, I expect to open-source key components and make them available on Github.

Pricing

To cover operating costs and sustain future development, I will ask for a small platform fee. The starter plan will be offered for $3/month and a pro plan with more capabilities will cost $5/month.

Once available, early adopters will be promoted to the pro plan at no additional costs. Thus, there are two incentives for being among the first users: pro capabilities at a low, all time price of $3/month as well as some additional influence on feature prioritizations.

The Release date...

... is not yet fixed, but I expect first light in Q4 2021. Given that I will start the platform as a side project, it is an ambitious but realistic goal. By the way, the name is already fixed but I will not reveal it until later this year!

Feedback

If you want to discuss the new system with me or just be among the first people to be notified, drop me a line on twitter: @jamifyjs. I am soooooo excited...

This post was originally published at jamify.org on January 9, 2021.

Gatsby or Next?

Joost Jansky — Tue, 15 Dec 2020 00:04:49 +0000

This year has seen overwhelming advances in static site builders which makes choosing the right system harder. Most comparisons on the web are outdated. That's why we take a fresh look at Gatsby versus NextJS. Take advantage of the lessons we learned in 2020 and make your own choice!

The first Jamify Blog starter was built on Gatsby. At the beginning of 2020, this seemed like a safe bet for a static site builder: A highly acclaimed React framework with a large ecosystem and vibrant open-source community. Looking back, this wasn't a bad choice: we still love the the Gatsby Jamify Blog system with it's plugins and certainly continue to support them. Read the Getting started with Jamify tutorial to learn more about Jamify.

Many comparisons between Gatsby and Next.js at the time were also making clear recommendations: if you need a static site builder go with Gatsby, if you need on-demand server rendering and serverless functions go with Next.js. With this distinction, a blog would typically better built with Gatsby whereas an e-commerce site with a lot of product changes would better fit to Next.js. Easy!

This simple decision making became more difficult nine months ago, when Next.js released Version 9.3 that introduced an hybrid approach. Hybrid means that you can choose between server side rendering (SSR) and static site generation (SSG) on a per page basis. Over night, Gatsby's SSG feature became available in Next.js and the above distinction fell apart.

Suddenly, Next.js was able to do what Gatsby was doing, but at the same time providing many more possibilities with SSR and serverless. Would it be worth switching to Next.js for a blog site that mainly uses SSG?

The case for Gatsby

In March 2020, when Next.js Version 9.3 was released, I did not pay too much attention to it. Of course, Next was now also capable of SSG, but Gatsby is certainly more experienced in its core SSG feature, I presumed.

Above all, you do not choose a framework based on one feature alone. Gatsby's main promises seemed still intact:

Blazing fast sites out-of-the box
Tools for image optimization
A plugin API that enables component shadowing
An integrated GraphQL layer for structured data fetching

Adding to these key Gatsby features are an integrated cache that can be used to make developer life easier and many third-party plugins to choose from that already solve a lot of common use cases.

At the time, Next.js could not compete in any of these areas. Thus, I was holding strongly to Gatsby. Of course, there were some annoyances with the GraphQL layer such as foreign-key linking issues popping up more often than expected. Also, component shadowing is a concept our users had difficulties grasping. But hey, you don't expect a perfect world. At least not as a developer!

Gatsby loosing ground

One of the biggest pain points with Gatsby has always been build times. The reasons for it is also one of its acclaimed features: image optimization. As Gatsby is doing these optimizations during SSG, every image you add to your site will increase build times.

For a blog with many images, these optimizations are absolutely essential for a fast loading site, but it never seemed right to do this during SSG. Image optimizations should be completely decoupled from site generations as you could do this as soon as you add a new image to your content management system, typically way ahead of building your site.

Gatsby is trying to cure these issues with two medicines: (1) utilizing a cache and (2) with incremental builds. The first medicine only works for sub-sequent builds which is a huge drawback and the second has two other downsides: it only works when deploying to Gatsby Cloud and – unfortunately – it turned out to be notoriously unstable.

You may argue that as image optimizations should be better done elsewhere, therefore it is not a Gatsby issue. This may be true, but wasn't Gatsby promising to make developer life easier with some awesome image optimization plugins?

When faith falls apart

While the described pain points could be solved with external solutions, a much more devastating Gatsby performance issue popped up in May 2020 that Gatsby wasn't able to solve _ until today . With Google changing its page speed rating system in _Lighthouse version 6.0, speed scores plunged from formerly given 100 points to mediocre 50 for many sites using images.

This problem erodes Gatsby's core promise which is still advertised as of today: Create blazing fast websites!

Nothing can hurt you more than not delivering to your core value proposition , but the real disaster for Gatsby is its inability to restore out-of-the box fast sites after more than six months.

Sadly, the reason for this is not a lack of willingness, it points towards fundamental design issues of the framework that are hard to rectify. You can read through the issue yourself to get a feeling about the depth of the problem. It is a combination of insufficient bundle size optimizations, deficiencies of the gatsby-image plugin and a conceptional weakness of trying to do everything with SSG.

Next 10 to the rescue

With Gatsby struggling to deliver its core promises and seemingly busy to commercialize its product generate cash for its investors, I was starting to take a closer look at Next.js.

To my surprise, Next was producing smaller bundle sizes out-of-the box in all of my SSG test cases. Unfortunately, images were not addressed at all early October, however, some rumors were spread that something great is coming out with Next 10. What could it be?

I attended the Next Conference on October 27th 2020 and the timing for a brand new built in image component with automatic image optimization couldn't be better. This combination of a React component with a serverless function for image optimization showcases the conceptional advantages of the hybrid approach.

Rather than quenching everything into SSG, make solutions with the tool that best fits your use case!

I am hard to be convinced

While excited about the new possibilities with Next, I was still not fully convinced to start a new version of the Jamify Blog starter with Next.js.

What am I going to do with all the nice plugins that are delivered with the starter?
What about the GraphQL tools that come for free with Gatsby, will this be hard with Next,js?
What about component shadowing? Will a Next version be easily extendible?

I am glad that the spark of the Next conference prevailed the nagging questions above. Sometimes, it's better to simply try things out and conclude after.

In this spirit, I initiated next-cms-ghost with a clear goal: A Next.js variant of the Jamify Blog starter that includes all features of the Gatsby version. So users can choose what ever they like best.

This goal was successfully reached on December 5th, 2020, in less than 4 weeks and with very pleasant results – not only with respect to Lighthouse v6 scores.

Less is more

First of all, the developer experience with Next.js is superb. It does a lot of the heavy lifting for you, but generally tries to stay out of your way as much as possible. At the same time it gives you great support for fundamental concepts such as TypeScript.

To this end, it also doesn't trick you into something you actually don't need. A great example is the GraphQL layer that Gatsby has been really proud of. It is great if you need it, but you don't always do! The data layer of next-cms-ghost relies entirely on REST interfaces that are far less complex, easier to maintain and play much nicer with TypeScript.

Use GraphQL only when over- and under-fetching is a real problem that you need to solve, but never presume your use case needs to be optimized in that way.

While there is some discussion about a plugin API in Next, it is quite unclear whether this will ever materialize. Thus, I took a practical approach and integrated all functionality that are in separate plugins directly into the Next.js Jamify Starter and made sure that you can enable/disable each feature with configuration options.

While I am generally more in favour of the plugin approach, there are some advantages of this integration: no need to install or uninstall packages. Everything can be switch on or off not only in the config but also with environment variables. No plugins also leads to lesser maintenance work as the need to sync dependencies between many packages quickly becomes a burden. Overall not a bad solution after all.

Conclusions

While I may sound overly critical about Gatsby, I want to stress that it is still one of the best static site generators out there and I am sure that some of the downsides described here, will be tackled in 2021.

I hear from the core team that they are working on serverless and new image plugins. They now also support a file based routing system, obviously inspired by Next.js. Interestingly, they also do not actively advertise the GraphQL feature anymore.

So, if you invested heavily in Gatsby, you may still want to stay with them. Nonetheless, my preference for Next.js is obvious.

My forecast is that Gatsby will not be able to level up with Next.js in 2021, because they have fallen behind not only in features. Gatsby has become too complex to make the fundamental changes it needs.

All this reminds me of the transient nature of software frameworks in general. The following graph from the StackOverflow survey on Backend framworks illustrates this beautifully.

It looks like every framework has it's time until it is superseded by something newer, better, fancier. Let's wait and see what the future brings and always remind yourself that...

...frameworks come and go, but what seems to prevail is JavaScript!

With this closing remark, I wish you a happy New Year 2021!

Do you want early access to Blogody, the brand new blogging platform that I am creating? Just sign-up on the new Blogody landing page and be among the first to get notified!

This post was originally published at jamify.org on December 15, 2020.

Running a professional blog for free

Joost Jansky — Wed, 15 Jul 2020 15:09:21 +0000

Ever wanted to run a blog site with zero costs? This tutorial explains how to do this in minutes with Jamify! If you follow along with the instructions in this tutorial, you'll have your own zero-cost setup by the end of this article featuring professional class speed, availability and security.

If you ever deployed a blog or website to the public internet, you know that running a live site usually incurs operational costs. For example, a managed blog site hosted on Ghost.org starts at $29/month.

You can considerably cut down such expenses by using a self-hosted solution, but a publicly reachable server is not free. A self-hosted solution typically costs around $5/month. Even a relatively inexpensive solution that was described in the Ghost CMS on Hetzner Cloud tutorial here on Jamify.org cost you at least $3/month.

As Jamify sites are static sites they can be deployed to a global CDN and do not require traditional servers. CDN deployments are extremely cost efficient, therefore you can benefit from the free tiers of Netlify or other providers and run your live site at no costs on a global CDN.

However, up until recently, you still needed at least a self-hosted Ghost CMS installation on a public server. Why? Because not all images were included in your Gatsby bundle, so they had to be served from your Ghost CMS! That's why you had to make sure your CMS is publicly reachable and available 24/7, depleting all the cost benefits of the static site approach.

With the new Jamify plugin gatsby-rehype-inline-images you can now integrate all images into your static site bundle, so you do not need the CMS for serving images anymore. This opens up the possibility to deploy your blog from localhost for free.

Ghost CMS on localhost

Besides costs, being able to run your headless Ghost CMS on localhost has a couple of notable advantages:

Easier setup as all production concerns fall away.
No need to worry about security (firewalls, proxies, ports, authentication, SSL certificates, etc.).
You can build your Jamify website offline and achieve fast build times that are not limited by network bandwidth (unless your blog incorporates external images).

Of course, a local CMS installation also has some limitations and cannot cover all use cases:

Authoring articles with teams is not possible (no public access).
Member functions (e.g. newsletter subscription and distribution) cannot be used (no publicly available backend).

Even if you need a public Ghost CMS installation at some point in time, a localhost installation is still the number one choice in a lot of testing scenarios.

Local CMS install

Let's start with installing a Ghost CMS on your local machine. The following instructions have been tested on a Linux system running on Fedora, but should work on other Linux flavours too, including MacOS.

If you are using Windows it is recommended to install the Windows Subsystem for Linux (WSL 2) and use Ubuntu 20.04 LTS.

Prerequisites

To install Ghost locally make sure you install Node.js, the package manager yarn and the ghost-cli. Even if Node.js is already installed, check that you have a recent version:

$ node -v
v12.18.2

Node comes bundled with the package manager npm. Make use of it right away and install yarn and the ghost-cli with it:

$ sudo npm -g install yarn ghost-cli@latest

Install Ghost

With the needed tools available, you can now create a new directory and install Ghost CMS in it:

$ mkdir ghost-local
$ cd ghost-local

Use the previously installed ghost-cli for performing the actual install:

[ghost-local]$ ghost install local

It may take a minute to download and install all files. After a successful install, you can visit the CMS under http://localhost:2368/ghost/ and complete the setup process in three steps:

For a local install, you can safely enter a bogus email address and skip the staff user invite as you won't be able to work in teams anyway. After completing the final step, you should be brought to the Ghost Admin dashboard.

Create API keys

The initial setup is now complete. You can make further customizations in the admin interface, but this is not required at this point in time.

In other tutorials on Jamify.org you may read the recommendation to turn on headless mode. For a local installation this is not needed as the installation will never be available publicly, so you can skip this step.

In order to be able to connect to your Ghost instance with Jamify later, you need to generate a content API key. Go to Integrations -> Add custom integration

and click Create in order to generate a new key:

Starting and Stopping

The installation routine automatically starts the local Ghost server. You can stop it with the following command:

[ghost-local]$ ghost stop

You will also have to re-start your server after every reboot:

[ghost-local]$ ghost start

If you want to check whether or not Ghost is currently running you can use this handy command:

$ ghost ls

Keep the current Ghost server running if you want to follow along with this tutorial.

Importing Content

If you are already running another Ghost instance, you may want to import your content to your local installation. The easiest way is to use the import/export functionality under the Labs section.

Unfortunately, images must be transferred manually. So, in addition to the above import/export for the textual content, copy all images in directory content/images/ from the source to the target Ghost instance.

Local Jamify install

With a local CMS install it also makes sense to generate your static site locally, in fact, you won't be able to build your site with a cloud provider because your localhost CMS is unreachable for them. Let's download the Jamify starter:

$ git clone https://github.com/styxlab/gatsby-starter-try-ghost.git jamify-starter

and change into the work directory:

$ cd jamify-starter

Adding Keys

The Jamify starter must be told to source in the CMS content from you Ghost CMS on localhost. For that, create a new file called .ghost.json in your work directory and copy the previously generated content API keys in it:

{
  "development": {
    "apiUrl": "http://localhost:2368",
    "contentApiKey": "2a087eea8fc3c9a3e7392625c0"
  },
  "production": {
    "apiUrl": "http://localhost:2368",
    "contentApiKey": "2a087eea8fc3c9a3e7392625c0"
  }
}

You must replace the contentApiKey with your own!

Remove members plugin

The Jamify starter includes some plugins for convenience, one of which is the gatsby-theme-ghost-members plugin. As discussed earlier, the members plugin needs a public backend which currently must be a Ghost CMS, therefore the subscription flow won't work with a CMS on localhost. That's why you should remove this plugin:

[jamify-starter]$ yarn remove gatsby-theme-ghost-members

and also exclude it in your gatsby-config.js:

// gatsby-config.js

plugins: [

    //{
    // resolve: `gatsby-theme-ghost-members`,
    //},

]

Add plugin for inline images

While feature and all meta images are included in the static bundle by default, all inline images within posts or pages are only included if you add the new gatsby-rehype-inline-images plugin:

[jamify-starter]$ yarn add gatsby-rehype-inline-images

This is a sub-plugin of the gatsby-transformer-rehype plugin and must be placed into your gatsby-config.js as follows:

// gatsby-config.js

plugins: [

    {
        resolve: `gatsby-transformer-rehype`,
        options: {
            filter: node => (
                node.internal.type === `GhostPost` ||
                node.internal.type === `GhostPage`
            ),
            plugins: [
                {
                    resolve: `gatsby-rehype-ghost-links`,
                },
                {
                    resolve: `gatsby-rehype-prismjs`,
                },
                {
                    resolve: `gatsby-rehype-inline-images`,
                },
            ],
        },
    },

]

Including this plugin may result in longer build times as all inline images must be downloaded. However, as you are downloading them from localhost you are not limited by network bandwidth.

The gatsby-rehype-inline-images plugin also processes images, so they are lazy loaded and fade in with a nice blur-up effect known from Medium. See the plugin readme to learn more about the options this plugin provides.

Smoke test

You can now start your first test build with

[jamify-starter]$ yarn develop

and see if the build succeeds. Check the results on http://localhost:8000/. Now, add a new article in your Ghost CMS on localhost and press the Publish button. After that re-build your project again with:

[jamify-starter]$ yarn develop

and verify that the new article comes through:

Build your static site

While the development command is great for testing, you need to issue the build command to generate an optimized bundle that can be deployed to a CDN:

[jamify-starter]$ yarn build

Check that your site looks as expected by starting the build server:

[jamify-starter]$ gatsby serve

and visit your site at http://localhost:9000/.

Deploy to Netlify

Now its time to deploy your site to a global content delivery network (CDN). This step has been described in more detail in the getting started tutorial.

Here, I just repeat the simple steps. Once you have the Netlify CLI tool installed you can login

$ sudo npm -g install netlify-cli

[jamify-starter]$ netlify login

and deploy the previously build bundle from the public/ folder.

[jamify-starter]$ netlify deploy --prod

Answer the upcomimg questions as follows:

and you should see you site manually published on Netlify

under https://eager-golick-336605.netlify.app or another unique subdomain.

Although optional, many people want to deploy their blog on a custom domain. You can either purchase a new domain on Netlify or bring your own. This does not come for free and a custom domain name will cost you about $1,5/month.

Congrats! 🎉 Believe it or not, your site is now running on a flaring fast CDN with zero operational cost. Plus, your site is even SSL secured and enjoys all the Jamstack security benefits.

Continuous Deployment

In another tutorial article, I showed how you can setup a continuous deployment pipeline, where a content change in your CMS triggers a site re-build which is then automatically propagated to your live site on the global CDN.

This setup heavily relies on online cloud services: your CMS must have a public endpoint that triggers a webhook on Gatsby Cloud which deploys the build to Netlify. With a CMS on localhost, this setup won't work anymore.

Webhooks on localhost

With a neat webhook open-source project from Adnan Hajdarević you can create a similar pipeline on localhost too. There are different methods available for installing this Golang program, here I choose to download the the webhook-linux-amd64.tar.gz binary package, unpack the file and copy the executable in /usr/bin/ folder of my machine to make it globally available.

The webhook program consumes a hooks.json definition file and spins-up a server on localhost. We need to define two actions:

Build the jamify-starter with yarn build
Deploy the build package with netlify deploy --prod

which can be combined in one script file called build-and-deploy.sh that you should place in your work jamify-starter directory.

#!/bin/sh

yarn clean
yarn build
netlify deploy --prod

Make this file executable with:

[jamify-starter]$ chmod +x build-and-deploy.sh

You can now create the hooks.json in the same directory:

[
  {
    "id": "jamify-webhook",
    "execute-command": "./build-and-deploy.sh",
    "command-working-directory": "/home/styxlab/jamify-starter"
  }
]

The working directory must be an absolute path, please change it to your own needs. You can now spin-up the webhook server:

[jamify-starter]$ webhook -hooks hooks.json -verbose -port 7000

You can now test this new hook by triggering the webhook with

$ curl -X POST http://0.0.0.0:7000/hooks/jamify-webhook

Connect to CMS

You can add this webhook easily to your CMS on localhost, so it get's triggered whenever you make changes to your content:

Test your pipeline

Let's make a simple content change. For this test, I change the title of the first post and also exchange the feature image with another one from Unsplash. Make sure to hit the Update button after making these changes.

After the build has completed, your live site should then be automatically updated with the new content changes.

Summary

If you do not need member functions and mostly write your articles yourself, the described setup may be exactly what you need for running an up-to-date, super-fast, SSL-secured, shell-proof public blog site with 99.99% uptime at zero costs 🥳.

While this article focuses on the operating costs of a live blog site, it is worth mentioning that this solution makes blogging not only more affordable, it also makes blogging more accessible : The install process is much simpler, so that it is feasible for people who feel discouraged by traditional self-hosting solutions.

Furthermore, taking a public CMS server out of the equation will certainly reduce complexity, ongoing maintenance efforts and let your mind put at easy: without a server, you cannot be hacked.

Do you want early access to Blogody, the brand new blogging platform that I am creating? Just sign-up on the new Blogody landing page and be among the first to get notified!

This post was originally published at jamify.org on July 15, 2020.

Newsletter marketing with Jamify

Joost Jansky — Sun, 05 Jul 2020 08:11:55 +0000

Learn how to initiate, organize and maintain newsletter marketing campaigns with Jamify! It may surprise you that membership subscriptions on your static site are readily possible. Best of all, you can manage members in your Ghost CMS. Start creating professional newsletter campaigns today!

A newsletter is still a popular and effective way to connect to your audience and establish trusted relations with your readers. The Ghost team continues to invest heavily into membership functions that you can also use with Jamify in order to initiate, organize and maintain professional newsletter campaigns.

It is still widely believed that statically built sites cannot provide dynamic functionality such as newsletter subscriptions. Totally wrong! Jamify utilizes the static site builder Gatsby which creates static sites that can be built with app like features.

The Jamify starter therefore integrates a new membership plugin that allows for your users to freely subscribe to your site thereby acquiring membership status in your Ghost CMS. The CMS handles sending out an email invite and adding members to your membership dashboards.

Subscription Flow with Jamify

Let's see how this works for a user visiting your Jamify site. There are two places where your users can subscribe to your site. The most prominent one is the Subscribe button at the top right corner. This option is is present on all pages:

Pressing Subscribe opens a new modal overlay window:

The only information asked for is an email address - it can't get any simpler. Let's choose to provide one and press Subscribe:

You should now see the green success message. The screen stays up until a user hits the cross button at the top right corner or the browser's back button.

Pro tip: You can also press the ESC key on your keyboard to exit the overlay window.

In addition to the modal subscription window, a subscribe section is also shown at the end of every post:

This is the perfect place for asking your users to subscribe. After your visitors enjoyed reading your article, they get the opportunity to subscribe to your site in order to stay informed when you publish a new post.

Pressing the Submit button terminates the flow on your site and the user receives an email in order to confirm the subscription.

Your Jamify site first registers the user's email address in your Ghost CMS which then takes care of handling the confirmation process.

User confirmation

A typical email that your users receive in their inbox looks as follows:

This opt-in method follows best practices and ensures that subscribing to your site is an active decision. Your user needs to click this button in order to freely sign-up to your site. There is also a direct link at the bottom of every mail which can be used instead of clicking the button.

When you inspect the subscription link you'll see that it refers to your Ghost CMS backend.

Even though users subscribe to your backend, a success message is forwarded and opens your front-end page:

That way users are kept on your main site while the hard work is performed in the background! This last step completes the user's subscription flow.

Note that a user can always unsubscribe by pressing a link that is sent with every email. Now, it's your turn to feed your users with a newsletter or other email marketing material.

Members dashboard

All users who successfully subscribed to your site show up in the membership dashboard of your CMS:

This is the place where you can manage your members. You can manage each member individually, add labels and notes and also control if a user will receive newsletters:

Preview Newsletter

With your Ghost CMS you can now automatically send full articles as an email version to your members. Before doing that, you should make sure you are satisfied with the end result and send a test email to yourself.

From your post view, open your right settings pane and choose Email newsletter. This opens a new dialog as shown below:

Note that you must configure Mailgun in order to be able to use the email newsletter feature. For further instructions, look at the configuration section below.

The Preview in browser function is a really great feature as it gives you a visual presentation of the outcome on both the desktop and on mobile devices:

Once you are fully satisfied with both the desktop and the mobile results, use the Send test email button to get the result into your own inbox. This is how the desktop version looks in my inbox:

It's reassuring to see that the emailed version looks exactly like the desktop preview version.

It's really confusing that Ghost uses your SMTP configuration for sending you test emails, but requires a Mailgun setup in order to be able to use the newsletter functionality.

Personalize Newsletters

It would be strange to receive an email containing a full blog article without a small greeting or introductory message. This is where email cards enter the game:

An email card can be placed anywhere in your post and is only shown in the email output, but not in the actual post (yes, this also works with Jamify 😉).

While email cards are great, they still feel a bit limited. For example, you cannot place any messages in front of the article, the earliest place is below the feature image.

Furthermore, email cards only support basic text formatting. Wouldn't it be great to place an image of your signature in your note or be able to change the typography so it looks like a handwritten note? As members functions are still beta in Ghost, it' probably a bit early to ask for those features.

Newsletter Campaigns

You have written and reviewed your article, discussed it with your peers, added a personalized note with email cards and tested the newsletter result in the preview windows.

What do you need to do in order to send out the newsletter to your subscribed members?

First, you should check the newsletter subscription status of your members. By default, all members are signed up to your newsletters, but are there users you want to exclude? Have you excluded users that should receive the newsletter this time?

Well, the final step needed is right before hitting the Publish button, by selecting the Send by email switch:

Want to send a newsletter after the post has been published? No problem: Just set your post into draft status, turn the email switch on and re-publish. Best of all: Your Jamify front-end page is not interrupted by this action!

It would be great to have a function that allows sending only to those users that did not receive the newsletter earlier. It's important to be extra cautions here: if you happen to send out the same newsletter twice, it's a sure way to land in the spam folder or get unsubscribed forever!

Teaser Newsletters

In my view, sending the full post as an email is a bit bloated. Many people I spoke to also prefer to send an excerpt with a link to the full post instead of a full article. You want to inform your readers with a newsletter, but you also want to channel your users back to your blog site.

Ghost's newsletter flow does not support this use case, however, you can make a reduced teaser version of your post as a second post – literally a ghost post 😂. There is just one complication. In order to send out the newsletter, you must publish it first. In an automated workflow, publishing your article triggers a webhook which then leads to the publication of your secondary ghost post: Ouch!

Excluding Posts in Jamify

You need a way to publish a post in your back-end that can be excluded in your Jamify front-end. With the flexibility you have with Jamify, this is readily possible. First, you need to mark the post for exclusion. You can use an internal tag for that purpose. Internal tags in Ghost start with a hash. So, in your CMS admin interface, create a new internal tag with name #hidden as follows:

Note that you need to switch to the Internal tags category in order to see the tag after creation. You will assign this tag to your newsletter post later.

Now, you need to tell your Jamify starter that it should not generate pages for posts that contain the tag #hidden. This can be easily achieved with setting a configuration option in siteConfig.js:

// siteConfig.js
module.exports = {
  siteUrl: `https://www.jamify.org`,

  // Exclude post or pages (default: do not exclude)
  excludePostsOrPages: (node => node.tags.find(tag => tag.name === `#hidden`) !== undefined),
}

The excludePostOrPage option takes a Javascript function as input, so you gain full control over the exclusion process. Depending on the context, the node variable will be populated with all fields present on posts or pages, which gives you a vast range of possibilities.

In the above example, we exclude posts based on a simple tag, but you can use more advanced pattern matching algorithms and work with a combination of fields.

We use internal tags in this example, but the excludePostOrPage function works with regular tags too.

In order for these changes to take effect, you need to re-build your site. With an automated set-up all you need to do is pushing the change to Github.

As the idea of the teaser is to channel your user's back to your site, make sure the new post is published and accessible to the world, before sending out the newsletter.

Creating the Teaser

The teaser newsletter should be simple and give a glimpse into the topic of a newly published article. Start by making a dedicated draft post, which could start with a greeting, again utilizing email cards:

and followed by the start of the article:

Now, it's super important that you don't forget to assign the hidden tag to this newsletter teaser post before pressing the Publish button:

Again, you should make use of the Preview in browser functions and send yourself the newsletter for review before hitting the big Publish button.

CMS Configuration

In order to be able to use the newsletter features in your Ghost CMS, you must go to the Labs section and activate the Enable members and the Allow free member signup switches:

It's quite new that you can also configure the reply email that is sent with the newsletter email:

Finally, you must configure Mailgun, otherwise the newsletter sending function is disabled:

Mailgun is currently the only option for distributing newsletters. Hopefully Ghost will provide more options after the beta phase.

Redirects

All links within your newsletter email point back to your Ghost CMS which is not visible to the public, so they will appear to be broken. It's therefore extremely important that those links get redirected to your live site.

If you installed your Ghost CMS as described in our self-hosting tutorial Ghost CMS on Hetzner Cloud you are done and you can skip this section. Otherwise, you need to upload the following redirects.json file to your Ghost CMS:

[
  {
    "from": "^\/(?!content\/images\/|members\/|unsubscribe\/|p\/)(.*)",
    "to": "https://www.your-blog.org/$1",
    "permanent": true
  }
]

Basically this file instructs the Ghost CMS server to permanently redirect all endpoints to your static site, except the ones starting with either /content/images, /members or /unsubscribe.

Summary

A flaring fast static Jamify site that you can push to the edges of a CDN is capable of providing your visitors with a dynamic user experience. The new membership plugin that is integrated into the Jamify starter enables a membership subscription flow that is not different from a traditional Ghost setup.

This means: no loss in dynamic user experience, but a big gain in site performance, security and developer flexibility!

As a site owner it is important that you can utilize the members function in your headless Ghost CMS, so no other tool is needed and everything can be done right where you write your articles. While the members dashboard is cool, the newsletter sending in Ghost feels too tightly coupled to the article publishing workflow which makes it difficult to launch independent newsletter campaigns.

Nevertheless, you can create hidden posts that never show on your blog site solely for the purpose of generatingnewsletters. This is a great alternative until Ghost supports more flexible newsletter features and gives you a lot of freedom for starting independent newsletter campaigns!

Do you want early access to Blogody, the brand new blogging platform that I am creating? Just sign-up on the new Blogody landing page and be among the first to get notified!

DEV Community: Joost Jansky

Image Uploads with Blogody

Uploading Images

Hosting images with Blogody

Blogody image URLs and privacy

Search engine Optimization (SEO)

Image lifecycle on Blogody

What’s next?

How to work with images in Blogody

Add free Unsplash images

Adding images with public URLs

Copy & Paste Image Link

Drag & Drop images

Drag & drop between content blocks

Copy & Paste images directly

Image Cloud Providers

Cloudinary image service

Final notes

How to export your Blogody blogs

Blogody export feature

What data is exported?

Why JSON?

Your sensitive data remains protected

Blogody API Export

Conclusions

Google Analytics + Blogody

Step 1: Navigate to your Analytics Dashboard

Step 2: Create a new account

Step 3: Create a new property

Step 4: Create a data stream

Step 5: Disable history events

Step 6: Add your measurement ID to Blogody

What’s next?

Blogody API Client 🔥

Prerequisites

Example Usage

Where to find the API key?

What’s next?

On-demand Static Regeneration: How Blogody serves multi-zone blog sites

On-demand Static Regeneration

Jamstack & Static Site Generation

Atomic & Immutable Deployments

Static Sites with Dynamic Content

Static Site Generation Drawbacks

Incremental Static Regeneration

Distributed Persistent Rendering

On-demand Static Regeneration

Multi-Zone On-demand Static Regeneration

Summary

Further Reading

Building a Rich-Text Editor for Modern Publishers

Rich-text editors for the web

Entering ProseMirror

Hover toolbar

Side menu

Keyboard Shortcuts

Input Rules

Unsplash Widget

Summary

Blogody - Tune into the melody of a new blogging platform

How to find the best product name?

A trustworthy top level domain name

Brainstorm for name snippet

Fixing the maximum character length

Choose sensible character constraints

Google Search on Blogody

Falling in love with a name

Names are likely overrated

Creating a new blogging platform

Existing blogging platforms

The benefits of a new platform

A minimalistic system

Pricing

The Release date...

Feedback

Gatsby or Next?

The case for Gatsby

Gatsby loosing ground

When faith falls apart

Next 10 to the rescue