Forem: Tijs Martens

How we used Notion as a CMS for our blog.

Tijs Martens — Wed, 19 Jan 2022 08:52:40 +0000

A couple of months ago, Notion announced that they released a public API that everybody can use to consume their own Notion workspace.

We were intrigued, and wanted to see how we could benefit from this new feature.

Since we started with Rodi, we struggled with the optimisation of our landingspage. We still believe that “Rodi” is a great name for our cycling app, but we are not the only ones that like this name and there are other companies who share this name. As a consequence, ranking high on google isn’t that easy.

One way to improve the SEO of a website is adding a blog. This gives google more context on what the product is that you’re promoting and if the blog posts are good, some people might link back to your website/ blog.

Getting started

So what were the requirements that we set for ourselves

Use an intuitive editor to write content
Publishing and un-publishing an article, should not require any changes to the code
Support markup and richt text formatting (titles, lists, links, code-blocks ....)
SEO-friendly url’s

After reading the docs of the Notion api, we decided that Notion could do the trick and we went to work.

Notion setup

The first thing we needed to do was creating a Notion database

We added the following columns

Name - the title of the blog.
Status - is not used in the code, but it’s handy to keep track of what’s the current status of an article in Notion.
Published - checking the checkbox will immediately publish that article.
Intro - a little description on what the article will touch.
Url - the author of the blog can choose what the slug of the url will be. (rodi.app/blog/[Url])

Hacking everything together

Our landing page is built using Next.js. I’ll not go into the details of the code and only cover some high level topics. But with the code snippets that are shown, you should be able to get an idea of what it takes to build a Notion powered blog. If you want to see all the code, you can check the pull request that added this blog to the website.

You can always find a “get started” and more details in the Notion docs.

Get all the published articles

First we want to get an overview of all the published articles.

To be able to fetch items from our database, we need to share our database with our integration:

When this is done, we can start coding:

export const getBlog = async () => {
  const response = await notion.databases.query({
    database_id: process.env.notion_database_id,
  });

  const published = response.results.filter((blogPost) => {
    return blogPost.properties.Published.checkbox;
  });

  return published;
};

This is everything we need to fetch all our articles and filter the articles out that are not published yet.

Get de content of an article

Because we want to be able to find an article, based on the custom url. We need to fetch all the articles and it’s properties first.

When we have all the posts, we can look for the one that matches with the current url.

Now we can use the id of this article to fetch the content of a page. Note that there is a maximum of 100 blocks. This is a limitation set by the Notion API.

You’ll see that this is not the most performant/ideal solution imaginable, but given the requirements and technical limitations, it’s the best we can do.

For us, this was not that big of an issue as we can use “Incremental Static Regeneration” from Next.js. Next will cache the response and will serve our blog within a blink of an eye. (Learn more how we implemented Incremental Static Regeneration in this pull request)

export const getPage = async (url: string) => {
  const allPosts = await getBlog();

  const blogId = allPosts.find(
    (blog) => blog.properties.Url.rich_text[0].plain_text === url
  )?.id;

  const page = await notion.pages.retrieve({ page_id: blogId });
  const title = page.properties.Name.title[0].plain_text;
  const intro = page.properties.Intro.rich_text[0].plain_text;

  const response = await notion.blocks.children.list({
    block_id: blogId,
    page_size: 100,
  });

  return {
    title,
    intro,
    content: response.results,
  };
};

Display the content

A Notion page consists out of lists of “blocks”, every block has a “type” that indicates if it’s normal text or if it’s a different type of component.

We can loop over all these blocks and render the appropriate React component.

If there is a type that’s not supported, nothing will be rendered.

const blogContent = useMemo(() => {
  return blog?.content?.map((block) => {
    switch (block.type) {
      case "paragraph":
        return (
          <Paragraph key={block.id}>
            {block.paragraph.text.map((text) => {
              if (text.href) {
                return (
                  <A key={text.text.content} href={text.href}>
                    {text.text.content}
                  </A>
                );
              }
              return text.text.content;
            })}
          </Paragraph>
        );

      case "heading_1":
        return <H2 key={block.id}>{block.heading_1.text[0]?.plain_text}</H2>;

      case "heading_2":
        return <H3 key={block.id}>{block.heading_2.text[0]?.plain_text}</H3>;

      case "bulleted_list_item":
        return <ListItem block={block} key={block.id} />;

      case "image":
        return (
          <ImageContainer key={block.id}>
            <StyledImage
              src={block.image.file.url}
              layout="fill"
              objectFit="contain"
            />
          </ImageContainer>
        );

      case "code":
        return (
          <CodeBlock
            key={block.id}
            text={block.code.text[0].plain_text}
            language={block.code.language}
          />
        );

      default:
        return null;
    }
  });
}, [blog]);

Wrapping up

We set ourselves the following requirements

We can decide what content is and isn’t shown using the checkboxes

✅ Use an intuitive editor to write content

Notion is my favourite tool to write because of it’s ease of use.

✅ Publishing and un-publishing an article, should not require any changes to the code

Publishing and un-publishing is done by checking a checkbox in the Notion database, it’s a breeze.

✅ Support markup and richt text formatting (titles, lists, links, code-blocks ....)

For now titles, lists, links and code blocks are supported, if in the future this is not enough, We can easily add support for other components such as quotes.

✅ SEO-friendly url’s

We can fully customise the url’s to strategically use important keywords to further improve our SEO.

Demo

Managing what articles are shown

Managing the article

Does my business need a PWA or a native app?

Tijs Martens — Fri, 23 Jul 2021 13:02:14 +0000

A lot of companies or organizations might come up with an idea that they think has to be materialized as a native application. Well, I'm here to challenge that. While you should totally go after your crazy idea, a native application might not always be the right solution.

PWAs

Let me introduce PWAs, otherwise known as progressive web applications. A PWA is a website or web application that uses some modern web technologies. These technologies enable web applications to implement some features which were only available to native mobile applications. They combine some of the best features of mobile applications and web technologies.

Which tool will guide you to success?

Still not sure if you need a PWA or a native app for your next big thing?

TLDR;

Why you should go for a PWA and harness the power of websites

Discoverability, & Shareability

One of the things we take for granted on the web are hyperlinks. Every web page has an inherent link, making them about as shareable as they come.

The web heavily depends on search engines. By applying some basic SEO (Search Engine Optimization) principles, people who have never heard of your site might land on it.

This makes PWAs the best option for ecommerce and content-heavy platforms because people will often search for a product or piece of content and not for your site or app specifically.

Data from Google shows that on average a user spends a lot more time on mobile apps than in browsers. And the biggest chunk of "app-time" is consumed by only a few apps. Unfortunately, it's really hard to play with the big boys at this time.

On the other hand, an average Android user visits over 100 different websites during a month. Long story short, the chance that your idea will be discovered in an organic way is much larger on the web than with native apps.

Multichannel

In traditional native app development you have to develop your app for every operating system. Luckily some progress has been made over the last years and apps for similar types of devices (phones, desktops) can be created from a single codebase.

But as of today, there is no real solution that makes it possible to create a native app that will work flawlessly on all types of devices from one codebase.

If you need a platform that needs to be accessed from multipele types of devices (iOS, Android, macOS, Windows, ... or any other device with a screen and internet connection), PWA's are definitely the way to go.

A PWA is "just a website" with some added features. But this website should be able to run on all types of devices. From the latest and greatest foldable device to your old flip-phone with a basic browser.

When your product is to be used on both desktop and mobile, a PWA might be the ticket.

Speed of development & validation

It seems that there are an infinite number of tools that can optimize the workflow of web developers. This often results in faster development on web than on mobile.

One of the things I love when I come back to web development is how easy it is to share new features. Deploy separate from the core website and just create a link, I.E. https://dev.yourdomain.new-feature.com. You can share this link with your team or client, and they can test the entire PWA with the new feature via this link.

If everything looks good and everybody is satisfied, you can merge the new feature, and it will be online in literal seconds. When the speed of development, and rapid, repeated user testing is of the essence, you might want to give PWAs a second look.

App stores

When creating a web project and you feel it's ready to launch, the only thing that's left to do is press the publish button and you're live. This is unfortunately not the case for native apps, as the only way of distributing your app is via the numerous app stores. While you can definitely benefit from the reach these platforms have, they have some downsides to them as well:

Time delay

You need to create developer accounts for Apple and Google. These are not free and need to be approved in some cases; a process that'll take a couple of days minimum.

Once you have your account, you will have to create an app store listing: this includes a comprehensive summary of the app and visuals for all types of devices.

After submitting, Apple and Google will take a few days to validate the listing and manually test your app to check if you don't violate their terms.

If everything goes well, this will cost you about one week. If Apple has some feedback and doesn't approve your app straight away, this process will start over, and you will lose more time.

Apple and Google guidelines

In some use cases, your app will never be approved or will be taken down when the store operators change their mind.

Some people have created apps to inform people about the current state of the pandemic. They went through the entire process and saw their app get approved. A couple of days later they received a notification from Apple and Google with the message that any and all apps that have something to do with the pandemic will be taken down. There was nothing these developers could do to get their app back online again. In that sense, you're subjected to the whims of the app stores.

30% rule

Apple takes 30% off of every sale you make on the app store. Furthermore, if your app just so happen to have "in-app purchases", Apple will also take 30% of that revenue. Because of this, Spotify and Epic Games have had multiple lawsuits with Apple. Google has also caught similar backlash over the same practice, hence they've recently announced to drop the service fee to 15%. Definitely something to keep in mind.

Updates

Every time you want to update your app, the stores have to review said update. When it gets approved, it will become available in the stores for the user to download, obviously. But that means you have to rely on your users to keep your app updated. So if your first launch on the app store is riddled with bugs, things could get painful.

Low entry barrier

I like PWAs a lot because of their almost non-existent barrier to entry. There's virtually no installation process. Just click a link and you're good to go.

If you want to test a feature from an app you need to download the entire app first(I know, this sounds obvious). but this is a big barrier. In 2020 the average conversion rate in the iOS app store was 34% and on the Google Play Store it was only 26%. These conversion rates highly depend on the app category, naturally. But the fact remains that app stores themselves can create friction for your users.

Installing a native app also takes up precious space on your phone. Many people with cheaper or older phones struggle with this storage restriction. That's another win for PWAs; even if your phone has barely any space left, you can still access them no problem.

Where PWAs fall short and native apps take over.

User experience

While you can create great experiences on the web, native apps just feel "snappier" in comparison. Animations and gestures are often smoother and just work better with native apps.

For developers, native apps are better suited if pixel perfect design is what you're after. It's really cool that a PWA can be used on almost every device, from a smart fridge to a smart watch. But that also means that your user interface has to be responsive beyond what's practical.

Native apps also make use of device specific components. A toggle switch is a great example of this. This component is the same in all the apps the user has, he knows exactly how it looks and how it works.

(Re)-engagement

Once a native app is installed on a device, you have more options to nudge your users.

There always is an app icon that reminds the user your app exists. You can also use badges. You know, the red dot in the upper right corner of the icon, signalling you've got a notification or something.

Another powerful tool to re-engage users are push notifications. With targeted and personalized push notifications you can get the users back to your app in no time.

The features mentioned above are also available on Android for PWA's. But they don't exist on iOS. If your project could benefit from these re-engagement features, a native application might be a better approach.

Device features

Native applications have much better access to system and device features of your phone:

Battery info
Brightness info
Access to calendar
Access to contacts
Access to files
Access to sensors
Access to your camera

Some of these features are available to modern Android devices for PWAs, but saying they're reliable would be a stretch

With a native app, you also have more control over the camera, and the performance of the GPS sensor is often times a bit better.

If your project requires one of the above features, a PWA is often not an option, making a native application the only way to go.

Conclusion

Be it due to some preconceived notion, but many people think native applications are the correct choice regardless. But as we discussed earlier, for some use cases it makes much more sense to implement your idea as a PWA. Some benefits such as shareability and speed can definitely give you an edge. Then again, if providing a stellar user experience and having re-engagement tactics at your disposal is more your jam, a native application might be more suited for the job.

Why you should create a PWA for your side-project

Tijs Martens — Mon, 24 May 2021 09:29:33 +0000

Introduction

We, (web-)developers, often have some small ideas for fun projects. Most of these ideas are not startup worthy but are just for the sake of learning something new or just having fun. One of the advantages of creating these is that you're building a strong portfolio with a "I am a creator" vibe.

Well, with a little more effort, you can upgrade these projects to look a lot more professional when sharing them on your socials.

Why do we create these side projects

I really like to create small and fun projects, not everything we make needs to have 1000 daily users to be developed. Sometimes we just have a little idea or something that's bothering us and by creating a small tool, we can solve that.

Another reason why I like to make small projects is to explore new technologies. It's hard to try something new in production software.

Creating side projects and proof-of-concepts are also a great way to develop a personal brand. By having small, non significant, projects on your portfolio you show that you have a hand's-on mentality. Which I believe a lot of companies want.

What is a PWA

You could write an entire thesis on what a PWA is and isn't. (whoops, maybe I did exactly that 😅). But in it's essence a PWA is just a regular website which makes use of modern web technologies to provide a user experience which is close to that of a native application.

It's an attempt to bridge the gap between native applications and web applications. It's taking the strongest points from both worlds and combines them.

You have the reach of the web. People can find your project from a search engine and it has an easy to access URL.
You have similar capabilities as a native application. A PWA can still provide some functionality when offline and it can also re-engage users with push-notification.

Many people would consider a PWA as a website which can be installed on a device. The lighthouse audit which is embedded in the Chrome dev-tools confirms this. So how do you make a regular website installable?

How to make a PWA installable.

Your website has to fullfill these 3 requirements

Register a service worker
Register a manifest.json
Be served over HTTPS

1. Service worker

According to the lighthouse audit, a PWA should register a service worker which has the "start_url" in it's scope. There is no requirement based on what the functionality of the service worker should be. To make the site installable, there should just be a service worker, it's totally fine if this web worker has no functionality.

So it's fine if it looks like this:

self.addEventListener("install", (evt) => {
 console.log('service worker installed')
});

self.addEventListener("activate", (evt) => {
  console.log('service worker activated')
});

This service worker should be registered in the startup file of your project. For me (in Svelte.js) that's







```jsx
if ('serviceWorker' in navigator) {
  navigator.serviceWorker.register('/service-worker.js');
}

And that's it! Now your website registers a service worker.

You can do al lot of cool things to improve the performance of your web app with a service worker. But that's outside the scope of this article.

2. Manifest.json

The manifest.json file is a file which provides some extra metadata about the website to the device. There are a lot of tools which can help you with generating the correct assets and the manifest file itself

I like to use this one: https://www.dunplab.it/web-app-manifest-generator

According the the MDN docs, a manifest should at least include the following properties

{
  "name": "Spotify album browser",
  "short_name": "Spotify album browser",
  "start_url": "/"
  "description": "A progressive web application that suggests albums based on the preferences and listening history of the user",
  "background_color": "#191414",
    "theme_color": "#1db954",
  "display": "standalone",
  "icons": [
        ...
    {
    "src": "images/icons/apple-icon-152x152-dunplab-manifest-4531.png",
    "type": "image/png",
    "sizes": "152x152"
   },
        ...
  ],
}

you should link to this file in the head-tag of your website:

<head>
    ...
    <link rel="manifest" href="/manifest.json" />
    ...
</head>

3. HTTPS

This one might be the easiest. It's 2020, serving a website without HTTPS is just not acceptable anymore. There are many platforms where you can host your side projects for free with https (Vercel, Netlify, ...). I like to use Vercel for it CI/CD features, but most likely other platforms can do the same.

So that's it! that's all! That wasn't to bad huh? For this effort your website, or should I call it PWA? is installable as a standalone experience on al modern devices. Most browsers (not Safari) will even prompt the user to install it.

Why should I create a PWA for my side project.

There are many reasons why you should add these 3 simple steps to your next side project.

Engagement: A PWA can be accessed from a URL just like a regular website. There is a really low barrier to test your little prototype/ tool. If you would've created a native app, this barrier is way bigger.
It looks hella good on screenshots/ screencasts. The little project you will make will look and feel like a native app. Without having to deal with the hassle of actually creating a native app. When you share your app in a video or just as screenshots, they look a lot better/ more professional than when you share screenshots of a web-browser.
Showing excellence: Progressive web applications are kinda new (debatable) in the world of web-development. Showing that you know what it is and know how to implement is, shows that you are actively following the latest trends within web development. This could be a crucial factor when you're trying to land your next job.

An Example

A couple weeks ago I struggled with finding new music on Spotify. For some reason, the Spotify recommendation engine kept on suggesting the same albums over and over again. Coincidentally at that time I wanted to try out Svelte.

I did some research and I found out that Spotify has a great API which is really easy to use.

So I had a plan. Create a good looking, personalized, album suggesting PWA.

After two weekends of developing and getting to know Svelte I had my PWA up and running. I recorded a screencast and shared it on my LinkedIn. It didn't explode or went viral. But yet, more people then expected gave it a try and I received a lot of feedback. One week later, I shared my project on reddit.

In both cases, I didn't have that many likes or upvotes. But a lot of the people that saw my post actually gave it a try. Which is in the end the goal.

You can give this little project a try at https://album-browser.vercel.app/.