DEV Community: Alex Rudenko

How to Add Native Code to a Flutter App using Platform Views on iOS

Alex Rudenko — Tue, 23 Jul 2019 12:36:20 +0000

In this tutorial, we learn how to add native components to a Flutter app on iOS. For the Android guide, see the previus post of mine.

Step 1. Define a wrapper component in Flutter

The component will be used throughout your app and the communication with native code will be encapsulated within. In this tutorial, we create a WebView component as follows. Note that the code is exactly the same as for Android except for an extra branch to support iOS.

import 'dart:async';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

typedef void WebViewCreatedCallback(WebViewController controller);

class WebView extends StatefulWidget {
  const WebView({
    Key key,
    this.onWebViewCreated,
  }) : super(key: key);

  final WebViewCreatedCallback onWebViewCreated;

  @override
  State<StatefulWidget> createState() => WebViewState();
}

class WebViewState extends State<WebView> {
  @override
  Widget build(BuildContext context) {
    if (defaultTargetPlatform == TargetPlatform.android) {
      return AndroidView(
        viewType: 'webview',
        onPlatformViewCreated: _onPlatformViewCreated,
      );
    } else if (defaultTargetPlatform == TargetPlatform.iOS) {
      return UiKitView(
        viewType: 'webview',
        onPlatformViewCreated: _onPlatformViewCreated,
      );
    }
    // TODO add other platforms
    return Text(
        '$defaultTargetPlatform is not yet supported by the map view plugin');
  }

  void _onPlatformViewCreated(int id) {
    if (widget.onWebViewCreated == null) {
      return;
    }
    widget.onWebViewCreated(new WebViewController(id));
  }
}

class WebViewController {
  WebViewController(int id) {
    this._channel = new MethodChannel('webview$id');
  }

  MethodChannel _channel;

  Future<void> loadUrl(String url) async {
    return _channel.invokeMethod('loadUrl', url);
  }
}

In this code, we declare WebView as a stateful widget. The state of the widget is defined in WebViewState. In the build method we check that the platform is iOS, and create an UiKitView. viewType is needed to be able to connect the native code to this UiKitView. Once the view is created, we instantiate WebViewController and to give control over the view to the parent code.

In WebViewController we create a method channel which has a unique name for every instance of the component. Communication between native code and Flutter happens via bidirectional async method channels. In loadUrl we send a message to a channel to invoke the loadUrl method of the native component and give a URL to load.

Step 2. Define native components

Go to the ios -> Runner. This is where we place our native code. First, we add a registration call to AppDelegate.swift:

let controller = window?.rootViewController as! FlutterViewController
let webviewFactory = WebviewFactory(controller: controller)

registrar(forPlugin: "webview").register(webviewFactory, withId: "webview")

The string webview here should match the viewType used in the previous step. This code tells the app that WebViewFactory is used to create instances for this view type.

Next, we define the factory in WebViewFactory.swift:

import Foundation

public class WebviewFactory : NSObject, FlutterPlatformViewFactory {
    let controller: FlutterViewController

    init(controller: FlutterViewController) {
        self.controller = controller
    }

    public func create(
        withFrame frame: CGRect,
        viewIdentifier viewId: Int64,
        arguments args: Any?
    ) -> FlutterPlatformView {
        let channel = FlutterMethodChannel(
            name: "webview" + String(viewId),
            binaryMessenger: controller
        )
        return MyWebview(frame, viewId: viewId, channel: channel, args: args)
    }
}

The factory creates instances of MyWebview which is our native implementation of the component. We define it in MyWebview.swift:


import Foundation
import UIKit
import WebKit

public class MyWebview: NSObject, FlutterPlatformView, WKScriptMessageHandler, WKNavigationDelegate {
    let frame: CGRect
    let viewId: Int64
    let channel: FlutterMethodChannel
    let webview: WKWebView

    init(_ frame: CGRect, viewId: Int64, channel: FlutterMethodChannel, args: Any?) {
        self.frame = frame
        self.viewId = viewId
        self.channel = channel

        let config = WKWebViewConfiguration()
        let webview = WKWebView(frame: frame, configuration: config)

        self.webview = webview

        super.init()

        channel.setMethodCallHandler({
            (call: FlutterMethodCall, result: FlutterResult) -> Void in
            if (call.method == "loadUrl") {
                let url = call.arguments as! String
                webview.load(URLRequest(url: URL(string: url)!))
            }
        })
    }

    public func view() -> UIView {
        return self.webview
    }

In this class, we create the native WKWebView provided by iOS and a method channel. We use the same name for the method channel so that messages are routed to the correct Flutter instance.

We also dispatch different calls and handle loadUrl. This class is the place where you can implement additional features. For example, configure the webview for your needs.

Now the plugin is complete, and you can use it in your Flutter code.

originally published at https://60devs.com/how-to-add-native-code-to-flutter-app-using-platform-views-ios.html

How to Add Native Code to a Flutter App using Platform Views on Android

Alex Rudenko — Tue, 23 Jul 2019 12:31:22 +0000

In this tutorial, we learn how to add native components to a Flutter app on Android. For iOS the process is similar, but this tutorial does not cover it. We are going to add a native WebView component as an example, and we write code in Kotlin.

Step 1. Define a wrapper component in Flutter

The component will be used throughout your app and the communication with native code will be encapsulated within. In this tutorial, we create a WebView component as follows:

import 'dart:async';
import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';
import 'package:flutter/services.dart';

typedef void WebViewCreatedCallback(WebViewController controller);

class WebView extends StatefulWidget {
  const WebView({
    Key key,
    this.onWebViewCreated,
  }) : super(key: key);

  final WebViewCreatedCallback onWebViewCreated;

  @override
  State<StatefulWidget> createState() => WebViewState();
}

class WebViewState extends State<WebView> {
  @override
  Widget build(BuildContext context) {
    if (defaultTargetPlatform == TargetPlatform.android) {
      return AndroidView(
        viewType: 'webview',
        onPlatformViewCreated: _onPlatformViewCreated,
      );
    }
    // TODO add other platforms
    return Text(
        '$defaultTargetPlatform is not yet supported by the map view plugin');
  }

  void _onPlatformViewCreated(int id) {
    if (widget.onWebViewCreated == null) {
      return;
    }
    widget.onWebViewCreated(new WebViewController(id));
  }
}

class WebViewController {
  WebViewController(int id) {
    this._channel = new MethodChannel('webview$id');
  }

  MethodChannel _channel;

  Future<void> loadUrl(String url) async {
    return _channel.invokeMethod('loadUrl', url);
  }
}

In this code, we declare WebView as a stateful widget. The state of the widget is defined in WebViewState. In the build method we check that the platform is Android, and create an AndroidView. viewType is needed to be able to connect the native code to this AndroidView. Once the view is created, we instantiate WebViewController and to give control over the view to the parent code.

Step 2. Define native components

Go to the android -> app -> src -> main -> kotlin -> com -> yourPackageName. This is where we place our native code. First, we define a native plugin in WebViewPlugin.kt:

import io.flutter.plugin.common.PluginRegistry.Registrar

object WebViewPlugin {
    fun registerWith(registrar: Registrar) {
        registrar
                .platformViewRegistry()
                .registerViewFactory(
                        "webview", WebViewFactory(registrar.messenger()))
    }
}

The string webview here should match the viewType used in the previous step. This code tells the app that WebViewFactory is used to create instances for this view type.

Next, we define the factory in WebViewFactory.kt:

import android.content.Context
import io.flutter.plugin.common.BinaryMessenger
import io.flutter.plugin.common.StandardMessageCodec
import io.flutter.plugin.platform.PlatformView
import io.flutter.plugin.platform.PlatformViewFactory

class WebViewFactory(private val messenger: BinaryMessenger) : PlatformViewFactory(StandardMessageCodec.INSTANCE) {

    override fun create(context: Context, id: Int, o: Any?): PlatformView {
        return MyWebView(context, messenger, id)
    }
}

The factory creates instances of MyWebView which is our native implementation of the component. We define it in MyWebView.kt:

import android.content.Context
import android.view.View
import android.widget.TextView
import io.flutter.plugin.common.MethodCall
import io.flutter.plugin.common.MethodChannel
import io.flutter.plugin.common.MethodChannel.MethodCallHandler
import io.flutter.plugin.common.MethodChannel.Result
import io.flutter.plugin.common.BinaryMessenger
import io.flutter.plugin.platform.PlatformView
import android.webkit.*
import android.net.http.SslError
import android.webkit.WebChromeClient
import android.webkit.WebView
import android.graphics.Bitmap
import android.webkit.WebViewClient

class MyWebView internal constructor(context: Context, messenger: BinaryMessenger, id: Int) : PlatformView, MethodCallHandler {
    private val webView: WebView
    private val methodChannel: MethodChannel

    override fun getView(): View {
        return webView
    }

    init {
        webView = WebView(context)

        methodChannel = MethodChannel(messenger, "webview$id")
        methodChannel.setMethodCallHandler(this)
    }

    override fun onMethodCall(methodCall: MethodCall, result: MethodChannel.Result) {
        when (methodCall.method) {
            "loadUrl" -> loadUrl(methodCall, result)
            else -> result.notImplemented()
        }
    }

    private fun loadUrl(methodCall: MethodCall, result: Result) {
        val url = methodCall.arguments as String
        webView.loadUrl(url)
        result.success(null)
    }

    override fun dispose() {
      // TODO dispose actions if needed
    }
}

In this class, we create the native WebView provided by Android and a method channel. We use the same name for the method channel so that messages are routed to the correct Flutter instance.

We also dispatch different calls and handle loadUrl. This class is the place where you can implement additional features. For example, configure the webview for your needs.

Step 3. Register native code

The final step is to modify android -> app -> src -> main -> kotlin -> com -> yourPackageName -> MainActivity.kt. We add a registration call to register our plugin:

import android.os.Bundle

import io.flutter.app.FlutterActivity
import io.flutter.plugins.GeneratedPluginRegistrant

class MainActivity: FlutterActivity() {
  override fun onCreate(savedInstanceState: Bundle?) {
    super.onCreate(savedInstanceState)
    GeneratedPluginRegistrant.registerWith(this)
    WebViewPlugin.registerWith(this.registrarFor("com.yourPackageName"))
  }
}

Now the plugin is complete, and you can use it in your Flutter code.

Originally published at https://60devs.com/how-to-add-native-code-to-flutter-app-using-platform-views-android.html on 14.05.2019

My principles of choosing and managing software and hardware as a developer

Alex Rudenko — Mon, 08 Jul 2019 14:00:21 +0000

Hey! Welcome to a non-coding post where I share how I organize my software and computers. That's probably the first post of mine which is not about coding! Share your thoughts too and let's start:

1. Make use of default configuration

When I install new software or get new hardware, it's essential for me that it suits my needs out of the box. I know many people who like configuring their software or even building it from the sources. It's not for me: for example, for many years I use the default Ubuntu version without customizing anything. So since 2008, I lived through the days of Gnome, Unity, and Gnome again. I feel like it saved me much time because I didn't try to change the systems or migrate to new ones. All I did was adapting to minor changes over the years.

Therefore, it's also essential to choose the products which are suitable for you by default. Often, if you need to change the product a lot, it might not be a good fit and can cost you much time.

Also, I check upfront if the software I plan to use will be compatible and working well with the hardware I am about to buy.

2. Set up backups for all important documents

It is what I did 4 years ago: I made sure that everything in my documents folder is regularly backed up. Even if my hardware dies or gets stolen, I can access the backups anytime. There are multiple ways to set up backups: you can use Dropbox or other services. I chose a different way: I purchased a network-attached storage system from Synology, where I have two hard drives in a RAID. Synology offers a backup program which you can run on your system to backup every document automatically. My NAS is not exposed to the Internet.

Additionally, I do the following:

all code I write lives in online services such as GitHub or BitBucket as well as my work computer
I back up photos I take with my phone to Google clouds (to help them do machine learning, you know). The most important photos I back up to the NAS. Regarding the rest, I am fine if I lose it, but it's convenient to keep it at Google and enjoy automatic sync.

3. Use a password manager

I use KeePassX, which stores passwords encrypted locally. I only create passwords on my primary computer, and it gets immediately backed up to the NAS. I keep a copy on my phone so that I can access services if I need to.

4. Don't automate installation and configuration of software you currently use

I don't automate the installation or anyhow back up the configuration of most tools that I use. My reason for not doing it is that if my computer breaks and I need to set up a new one, most likely, I won't need to use all the software I installed over the years again. Often, there is a better way or a better software to solve a particular problem, so I want to discover it the next time I set up a system. Problems are getting solved every day, and bug fixes are released, and there is a good chance that whatever you would be automating today is going to be obsolete.

One example for this: NVIDIA drivers were used to be hard to set up and configure on Linux. I could have spent time automating the setup and trying to streamline it somehow, but developers of Ubuntu and NVIDIA eventually made good progress, so the drivers work out of the box.

5. There are exceptions to all the 4 rules above

The world is not perfect, and sometimes I don't use a password manager or forget to back up a document. Now and then, there is an outstanding software which I stick to for a while and which does not change often, and it makes sense to invest more time in it, such as, for example, setting up your primary editor or terminal. Nonetheless, I try to minimize the time I spend on this.

So to summarize, I store my data in multiple places, so the chance of all them being destroyed is lower. I minimize the amount of time I dedicate to configuring and tweaking my software. Instead, I focus on finding software which works for me out of the box. I benefit from switching to newer and better tools over time because I am not heavily invested in my current toolset. Moreover, if I need to recover my setup, it usually takes very little time.

originally published in my blog at https://alex-rudenko.com

Create Beautiful Screencasts from Your Terminal

Alex Rudenko — Sun, 02 Dec 2018 12:01:31 +0000

I wanted to showcase my CLI apps and didn't know a solution. I imagined that I could record my screen as a video and convert to a GIF file so that you can embed them to GitHub or elsewhere. After googling for some time, I found a better approach which produces SVGs instead of GIFs, and it's effortless to use.

Install asciinema

This tool allows you to record your terminal session. It also has a website where you can upload your recordings and where everyone can see them https://asciinema.org/. I recommend creating an account there.

npm i asciinema -g

Unfortunately, the recorded sessions require a player to play them so they cannot be embedded in any website. For example, you cannot insert it to Github's README.

Install svg-term-cli

This is a useful tool which can convert sessions recorded using asciinema to SVG:

npm i svg-term-cli -g

How to record

I use it with the max idle time of 2 seconds. This will start a recording:

asciinema rec -i 2

After you run this, do whatever you wanted to show in the terminal. Press Ctrl + D to stop recording.

If you upload the sessions to asciicinema.org, create an SVG like this:

svg-term --cast=YOUR_CAST_ID --out demo.svg --window

You can view demo.svg in a web browser after that.

If you store the recording locally, create an SVG as follows:

cat path-to-your-cast-file | svg-term --out demo.svg --window

Embedding

Now you can embed the SVG files almost anywhere. Here is an example from my newsletter-cli project:

<p align="center">
  <img src="https://raw.githubusercontent.com/OrKoN/newsletter-cli/master/demo.svg?sanitize=true" width="572" alt="newsletter cli demo">
</p>

And here is how it looks like: see on Github

P.S. Interestingly, dev.to uses some image proxy which converts animated SVGs to a static image, so it does not seem possible to embed such SVGs into the content. But it seems to work for the cover image!

originally published at https://60devs.com/create-beautiful-screencasts-from-your-terminal.html

Getting Started with Web Push Notifications

Alex Rudenko — Mon, 09 Apr 2018 19:14:43 +0000

I have heard about Web push notifications and Service Workers many times, but I have never implemented them until the last week for Just Comments. So I decided to share my notes about this technology.

First of all, there are plenty of articles and useful documentation about Web push notifications so I won't add something new to it. I will try to summarize what I feel one needs to understand and know to get started quickly and implement a basic version of Web Push notifications.

Let's start with some key facts:

#1 Push notifications rely on multiple separate browser APIs

The entire feature of Push Notifications involves Push API and Notifications API which can be used separately. Also, it relies on Service Workers because only they can run in the background to be able to receive push notifications even if the user closed the sending website.

#2 Not all browsers support Push Notifications (yet)

Currently, IE && Opera Mini doesn't support Service Workers and Push API and, additionally, iOS Safari, Chrome for Android, Samsung Browser and UC browser for Android don't support Web Notifications API.

It means that you need to detect if the browser supports required APIs or not when you implement push notifications.

Big Diagram of How This Works

I created a simple diagram to wrap my head around different APIs and concepts. It connects various pieces via a sequence of actions/relationships between them.

So all starts with some JavaScript code on your Web page which registers (1) a service worker. The service worker provides (2) a service worker registration object which, in turn, gives access (3) to an instance of Push Manager. The push manager can provide (4) us a Push Subscription if the user allows. This subscription object can be sent to your backend (5). On the server, you can use the subscription to send a message (6) to the user's browser. The service worker receives (7) the message, but it is not automatically shown to the user. The service worker parses the message and can decide what to do with it. Normally, the worker displays a Notification (8) using the Notification API.

The Coding Part

As I mentioned in the key facts, not all browsers support the APIs, so we need to check if the user’s browsers support service workers:

function supportsPushNotifications() {
  return 'serviceWorker' in navigator && 'PushManager' in window;
}

supportsPushNotifications() === true // if the browser supports needed APIs

After we check that we can use Service Workers, we can start with the first step and register a service worker:

navigator
  .serviceWorker
  .register('/sw.js')
  .then(swRegistration => {
    // TODO step 2 & 3 here
  })
  .catch(err => {
    console.log('serviceWorker.register failed', err);
  });

This code fetches sw.js at the root of your website. The register function returns a promise. Therefore, we handle it with .then for a successful case and .catch if something goes wrong.

Now, we can implement the step 2 & 3 which requires the swRegistration:

const applicationServerKey = '';
swRegistration
  .pushManager
  .getSubscription()
  .then(subscription => {
    const isSubscribed = !(subscription === null);
    if (!isSubscribed) {
      return swRegistration.pushManager
        .subscribe({
          userVisibleOnly: true,
          applicationServerKey,
        })
        .then(sendSubscriptionToServer);
    }
    sendSubscriptionToServer(subscription);
  })
  .catch(err => {
    console.log('getSubscription failed', err);
  });

Don't worry about applicationServerKey for now. applicationServerKey allows associating the subscription with your server. I will explain how to obtain this key later.

So what happens here: we call the pushManager.getSubscription method which returns a subscription if the user has already allowed push notifications and null otherwise. If we already have a subscription, we can send it to the backend. If not, we call pushManager.subscribe to ask the user to allow push notifications.

Now, for the step 5, you can use any method you like to send the subscription object to your server. I recommend stringifying it first with JSON.stringify(subscription).

For sending a message from your server to the client, I recommend using the web-push module:

const webpush = require('web-push');

const vapidKeys = {
  publicKey: '',
  privateKey: '',
};

webpush.setVapidDetails(
  'mailto:your@email',
  vapidKeys.publicKey,
  vapidKeys.privateKey
);

webpush.sendNotification(
  JSON.parse(subscription),
  JSON.stringify({
    title: 'Title',
    icon: 'https://your-site.com/assets/push-icon.png',
    body: 'Body',
    url: 'https://your-site.com/url-to-open',
  })
)

And now in steps 7 & 8, we circle back to sw.js, the service worker code responsible for receiving and displaying a push message:

self.addEventListener('push', function(event) {
  const message = JSON.parse(event.data.text());
  const title = message.title;
  const url = message.url;
  const options = {
    body: message.body,
    icon: message.icon,
    badge: message.badge,
    data: url,
  };
  event.waitUntil(self.registration.showNotification(title, options));
});

self.addEventListener('notificationclick', function(event) {
  event.notification.close();
  event.waitUntil(clients.openWindow(event.notification.data));
});

Here, two event listeners are defined. With the push listener, we parse the message and invoke the showNotification method to display a notification. On notificationclick we close the notification and navigate to the URL sent via the push message.

Generating Keys

You can use the web-push library to generate keys. The key generation needs to be done once. Both the frontend and the backend use the same public key, and the backend only uses the private key:

const webpush = require('web-push');
const vapidKeys = webpush.generateVAPIDKeys();
console.log(vapidKeys);

You should specify the keys in the previous code snippets, where needed.

Conclusion

I find the APIs for Push Notifications to be quite simple and straightforward. Nevertheless, it takes quite some time, in the beginning, to wrap your head around all concepts and moving parts.

I hope you find these notes useful and you'll come back to them once you need to implement push notifications. And if this time comes, please don't ask for permissions as soon as the web page loads: it's annoying, and most people would block it.

Thanks for reading!

Feature proposal: peer review of posts before publishing

Alex Rudenko — Sat, 24 Mar 2018 12:20:18 +0000

I am working on a new post slowly. And I always feel like something that I write might not be clear enough or fail to address important questions. Therefore, I thought that it would be cool if dev.to offered a possibility to ask for a peer review before the post goes public. I think this could be quite helpful and would increase the usefulness of posts.

And what do you think?

How do you handle client timeouts?

Alex Rudenko — Tue, 20 Feb 2018 19:24:24 +0000

You have an endpoint which does some valuable computations, and it's supposed to answer within say 3000 ms. Therefore, the client has 3000 ms as the timeout setting for the request. For whatever reason, some % of requests started to take 6000ms. What happens now is that execution continues after the client disconnects. The result is then just discarded.

The question is: how do you deal with it (if at all) using your current technology? Do you abort the computations and how do you do it?

JSX on the Backend?!

Alex Rudenko — Thu, 01 Feb 2018 15:22:08 +0000

Hi!

Recently I had an idea how to improve the development experience when creating NodeJS servers (in particular, with express). But first I would like to explain some problems I see with barebones express apps:

1) lack of API documentation. You need to learn/integrate Swagger or API Blueprint to get proper API docs
2) lack of automatic input/output validation. With JavaScript, it's a bit hard to control if everything is properly typed. You need to write validation yourself or employ some validator libs or JSON schema validators.
3) low discoverability. No easy way to generate client code with types and validation.

What I thought would be cool is to have a standard format to define all aspects of a server with HTTP API. This format should be simple and not entirely new. So I thought that JSX is excellent for this. With JSX a typical server looks like this:

<Service
  id="hello-world-service"
  port={3000}
  version="0.1.0"
  contact="orkon"
  tags={['node', 'service']}
  endpoint="http://dev.server.at.home"
>
  <Middleware use={require('./middleware/logger')} />
  <Group name="Hello" description="All routes related to saying Hello">
    <Route
      description={'Generates a message in the format "Hello :who!"'}
      path="/hello/:who"
      method="get"
      handler={require('./handlers/getHello')}>
      <Request>
        <PathParameter name="who" type="string" />
      </Request>
      <Response schema={require('./schemas/getHello.res.json')} />
    </Route>
  </Group>
</Service>

const server = getExpressServer(compile(__dirname + '/definition.jsx'));

server.listen(3000, () => {
  console.log('server started');
});

The cool things I see about it:

easy to read (especially if you are familiar with JSX/React)
easier to compose different APIs
connects implementation with documentation
allows generating input/output validators thanks to JSON Schema
allows generating proper API docs
allows discovering how to invoke the service
hides the underlying framework (it can be express, koa, etc.)
behind the JSX it is just plain JS classes/objects, so the use of JSX is optional

Project URL: https://github.com/OrKoN/api-express

Do you think it's a good idea?

Adding comments to your Jekyll blog

Alex Rudenko — Tue, 30 Jan 2018 16:38:53 +0000

Jekyll is a Ruby-based engine which helps you to create static websites and blogs. It's one of the most popular systems out there which comes with tons of plugins and examples. One of the advantages is that it is supported out-of-the-box by Github Pages where you get the hosting for static websites for free, including the possibility to have a custom domain. In this post, I will show you an easy way to add a comments widget to your static website based on Jekyll using Just Comments. By default Jekyll recommends to use Disqus but, in my opinion, Just Comments is much a better option because its client-side bundle is less bulky and it does not focus on monetizing via ads.

Creating a new blog with Jekyll

Skip this section if you already have a blog with Jekyll. Though, creating a new blog is easy:

jekyll new my-awesome-site

Change the directory to my-awesome-site and run the following command which starts a local server with the generated website at http://localhost:4000

bundle exec jekyll serve

Adding comments to Jekyll blog

Now when we have at least a basic blog, we can add comments so that your visitors can comment on your content.

First, create an account at Just Comments by logging in via Github or Facebook. You will see your API key that the system has automatically generated.

Now we need to modify the blog template and integrate the widget into our blog. You do this by customizing the existing theme of your blog. For example, to customize the default theme called minima, create the file _includes/head.html in your favorite editor. Place the following content in the file:

<head>
  <meta charset="utf-8">
  <meta http-equiv="X-UA-Compatible" content="IE=edge">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  {% seo %}
  <link rel="stylesheet" href="{{ "/assets/main.css" | relative_url }}">
  <link rel="alternate" type="application/rss+xml"
    title="{{ site.title | escape }}" href="{{ "/feed.xml" | relative_url }}">
  {% if jekyll.environment == 'production' and site.google_analytics %}
    {% include google-analytics.html %}
  {% endif %}
  <!-- START OF RELEVANT PART -->
  <script async src="https://just-comments.com/w.js"></script>
  <!-- END OF RELEVANT PART -->
</head>

By adding the script tag, we embed the widget provided by Just Comments which will power our comments.

Second, place the container element for the comments where you want it to be. For this, we need to customize the post template by creating the file ./_layouts/post.html with the following content Replace YOUR_API_KEY with the actual API key for your Just Comments account.

--------
layout: default
--------
<article class="post h-entry" itemscope itemtype="http://schema.org/BlogPosting">

  <header class="post-header">
    <h1 class="post-title p-name" itemprop="name headline">{{ page.title | escape }}</h1>
    <p class="post-meta">
      <time class="dt-published" datetime="{{ page.date | date_to_xmlschema }}" itemprop="datePublished">
        {% assign date_format = site.minima.date_format | default: "%b %-d, %Y" %}
        {{ page.date | date: date_format }}
      </time>
      {% if page.author %}
        • <span itemprop="author" itemscope itemtype="http://schema.org/Person">
        <span class="p-author h-card" itemprop="name">{{ page.author }}</span>
        </span>
      {% endif %}</p>
  </header>

  <div class="post-content e-content" itemprop="articleBody">
    {{ content }}
  </div>

  <!-- START OF RELEVANT PART -->
  <div 
    class="just-comments"
    data-allowguests="true"
    data-apikey="YOUR_API_KEY">
  </div>
  <!-- END OF RELEVANT PART -->

  <a class="u-url" href="{{ page.url | relative_url }}" hidden></a>
</article>

The result looks something like this:

Do you have a blog?

Alex Rudenko — Sat, 13 Jan 2018 19:19:25 +0000

Hi,

I'd like to discuss blogging and hear your experience. Also, I want to find some blogs to subscribe to :-)

1) Do you have a blog? Please share it if you do, and if you don't, why?

2) Do you enjoy blogging? How often do you write? How many time does it consume for you? How many times did you start and stop blogging?

3) Has blogging paid off for you? Have you got freelance contracts or job thanks to your blog?

4) How do you host the blog? Which services do you use? What are your plans for the next make-over?

5) Do you follow other developer blogs? How? RSS, Twitter, dev.to?

Add comments to your GatsbyJS blog within two minutes

Alex Rudenko — Thu, 04 Jan 2018 15:01:09 +0000

Static sites are great! They are easy to publish and maintain. You can scale a static website easily for millions of users. And hosting usually is quite cheap. Another advantage is the convenience of local development and the possibility to preview any change before publishing. One of the challenges of static websites is adding dynamic content to the site. In this post, I will show you an easy way to add a comments widget to a static website based on GatsbyJS using Just Comments.

Creating a new blog with GatsbyJS’ blog starter

Skip this section if you already have a blog with Gatsby. For those who don’t have one, let’s start with installing GatsbyJS:

npm install --global gatsby-cli

Create a new blog with the name “blog-with-comments”:

gatsby new blog-with-comments

Change the directory to blog-with-comments and start GatsbyJS in development mode. This will spin up a development server, and you will be able to see the blog at http://localhost:8000

gatsby develop

Adding comments to GatsbyJS blog

Now when we have a basic blog we can add comments so that your visitors can comment on your content.

First, create an account at Just Comments by logging in via Github or Facebook. You will see an API key created for you once you log in.

Account page at Just Comments

Now we need to modify the blog template and integrate the widget into our blog. Open the file src/templates/blog-post.js in your favorite editor. Change the <Helmet> tag in the following way:

<Helmet title={`${post.frontmatter.title} | ${siteTitle}`}>
  <script src="https://just-comments.com/w.js" type="text/javascript" defer="true"></script>
</Helmet>

By adding the script tag, we embed the widget provided by Just Comments which will power our comments.

Second, place the container element for the comments where you want it to be. I add it right after the <Bio /> tag in the same file src/templates/blog-post.js. Replace YOUR_API_KEY with the actual API key for your Just Comments account.

<div
  className="just-comments"
  data-allowguests="true"
  data-apikey="YOUR_API_KEY"
  style={{
   marginBottom: rhythm(1),
   marginTop: rhythm(-1),
  }}
>
</div>

The end result looks something like this:

Hello World comment with GatsbyJS and Just Comments

About Just Comments

Just Comments is a service offering a comment system. It’s not entirely free, but it’s almost free for small websites which don’t get millions of visitors. Just Comments charges you for a so-called comment pageview, and one comment pageview costs as little as $0.00001, or $10 for 1,000,000 pageviews. Read more about Just Comments’ pricing and possible integrations at https://just-comments.com/

Synchronization of concurrent HTTP requests in NodeJS

Alex Rudenko — Tue, 02 Jan 2018 15:31:02 +0000

As the follow-up to my previous post "Making Better HTTP APIs", I wrote a simple NodeJS server which demonstrates how to implement synchronization of concurrent requests so that certain parts of business logic are not executed twice.

I used the example from the previous post, a Payment API, and wrote a simple server which follows POST/PUT pattern for resource creation but does not handle concurrent PUT requests correctly (yet). First, let's take a look at the basic implementation and, afterwards, let's extend the server to synchronize concurrent requests.

The server has two handlers POST /payments and PUT /payments/id.

app.post('/payments', (req, res) => {
  const paymentId = nextPaymentId++;
  const context = `request(post) #${nextRequestId++}`;
  handle(() => createPayment(context, paymentId), res);
});

app.put('/payments/:id', (req, res) => {
  const context = `request(put) #${nextRequestId++}`;
  const paymentId = req.params.id;
  handle(() => conductPayment(context, paymentId), res);
});

Both handlers define the context variable which includes the request ID. The context is useful for grouping log messages produced by the same request. Additionally, the POST /payments handler generates a new payment id. After that, both handlers delegate the execution to the handle function which invokes the correct business logic function and handles the HTTP response.

The handle function is quite simple too. Note that error handling can be improved by using extended error classes. The implication is that the business function either returns an object to be sent to the client or throws an error:

async function handle(fn, res) {
  try {
    const result = await fn();
    if (result) return res.status(200).json(result);
    res.status(204).end();
  } catch (err) {
    res.status(409).json({
      error: err.message,
    });
  }
}

Now let's examine the business logic. The createPayment function does nothing more than storing the payment id with the indication that's an empty one. The conductPayment is more complex than createPayment:

async function conductPayment(context, paymentId) {
  const payment = await getPayment(context, paymentId);
  if (!payment) {
    throw new Error('Payment does not exist');
  }
  if (payment.state === 'PROCESSING') {
    throw new Error('Payment is in progress. Try again later.');
  }
  if (payment.state === 'PAID') {
    return payment;
  }
  if (payment.state === 'EMPTY') {
    await processPayment(context, paymentId);
  }
  throw new Error('Payment is in bad state');
}

This function retrieves the payment object first and then examines the state of the payment. If the payment is not paid and not being processed at the moment, the function invokes the processPayment method. As it is a lengthy operation in the real world and typically involves a call to a 3rd-party service, it can take a while. I have simulated this using setTimeout. The execution of processPayment takes about 3 seconds.

Let's summarize what the server is capable of, at the moment:

It can handle concurrent POST /payments requests. Empty payments stored in the database have no external side effects, and we can clean them up later.
It can handle only sequential PUT /payments/id requests for the same ID.

The point #2 may not be evident from the first glance, but if we examine the code for the conductPayment function, we notice that there is a time gap between the await getPayment and await processPayment. Between those two calls, a concurrent request can arrive and read the same payment state. Thus, a concurrent request can start a parallel (and a duplicate) payment process.

Synchronization of concurrent HTTP requests

To avoid problems with concurrent requests we just need to make sure that no request for the same payment ID can start while there is another request in the code section between await getPayment and await processPayment. There are several ways to achieve it:
1) Queuing. We could ensure that instead of executing conductPayment function immediately the server puts a message to a queue specific for the corresponding payment. Another process (a worker) would fetch the messages for a payment ID one at a time, thus, eliminating the problem of concurrent execution. This approach is a good and scalable solution with one drawback: it makes the architecture more complicated with several processes to manage and a message broker to maintain.
2) Locking. We could leverage either optimistic or pessimistic locking strategy. With pessimistic locking, we could use the database or something else, for example, Redis to ensure that no concurrent request can enter the conductPayment while there is another request in progress. With optimistic locking, we could check if the payment state is still EMPTY while trying to change its state to PROCESSING (in an atomic way). If this fails, we could throw an Error and don't send the payment to the 3rd party.

Since it is not an article about locking or queuing, I show how the pessimistic locking strategy could look in the code.

app.put('/payments/:id', (req, res) => {
  const context = `request(put) #${nextRequestId++}`;
  const paymentId = req.params.id;
  handleWithLock(() => conductPayment(context, paymentId), res);
});

Here, the handleWithLock function is exactly like handle but it ensures that only one instance of the business logic can be running at a time. This is how one could implement it:

async function handleWithLock(context, lockId, fn, res) {
  try {
    const lockState = await lock(context, lockId); // per paymentId
    if (lockState === 'locked') throw new Error('Resource is locked.');
    const result = await fn();
    if (result) {
      return res.status(200).json(result);
    }
    res.status(204).end();
  } catch (err) {
    res.status(409).json({
      error: err.message,
    });
  } finally {
    await unlock(context, lockId);
  }
}

It is essential that the lock function is such that only one process can acquire the lock. Also, it is vital that the lock is released if the Node process crashes (or that the lock expires after some time). In this simple example, I implemented basic in-memory locks. For the production-ready implementations which are supposed to work for a cluster of Node processes, something like PostgreSQL Advisory locks or Redlock can be used. Once the processing finishes, the lock is released using the unlock function.

In this implementation, the handleWithLock function throws an error if the resource is locked. Alternatively, the server could wait till the resource is free again using a Spinlock. Below you can the simple server in action.

The full server code can be found here: gist.

If I missed some of the ways to implement the synchronization or you spot a mistake in the code, please let me know and follow me on Twitter.

Originally published in my blog at 60devs.