Goal-oriented API

In the previous article Production rule systems were employed to define behavior of frontend UI. In this one I'll show how to use Hierarchical Task Networks (HTN) to define dynamic behavior of an API (or in other words workflows). Find out more about HTN in this free Game AI Pro chapter Exploring HTN Planners through Example.
So what is wrong (or missing) in most API definitions nowadays whether it is some contract defined via Java interface or REST API described via Swagger? They define operations but lack definition of workflows or how with the help of the operations provided achieve your goal. Find below how this might be done.

Rule based system applied to frontend tasks

Production rule systems have been used to define and reason about behavior of some system. A good introductory material can be found in Drools  - rules engine from JBoss - documentation, chapter on Artificial intelligence.
I was wondering what could happen if such approach was applied to manage the behavior of user interface. As a basis I took redux async example, you can find out more about it at redux documentation on async stuff.
We'll make a simple idealized or data-oriented production system, there is an assumption that any triggered conditions should be executed: the consequent actions will update the agent's knowledge, removing or adding data to the working memory - in our case changing the store in terms of redux. The system stops processing when no rules can be executed anymore.

For instance, given some state A user through UI can change it to B, then planner applies rules till no more rules are true and final result is being rendered to the browser.

The full source code is available.

Django and Websockets. Setup for production

Django Channels is promising but not ready yet. This technology hasn't been included in Django 1.10 (see Django 1.10 release notes) as was promised earlier. Another reason is that daphne is not a reliable replacement at the moment for a bullet proof uwsgi or gunicorn.
A typical way to approach websockets is to use socket.io running inside a NodeJS. But having uwsgi this is not necessary as uwsgi offers websockets. It rather a low-level solution, in order to omit boilerplate it is advisory to use django-websocket-redis. Its setup can be a tricky thing especially if you targeting scalable solution for production. I've been using this approach in 2 projects in production and gathered minimal django application with websockets on board with production ready configuration. See details below. Full source code is available.

Live Streaming & JS

Presentation on Live Streaming & JS is now available by link. Held on IT Weekend Kharkiv. Shows the usage of Media Source Extensions, nginx-rtmp-module, MPEG-DASH and OBS.

Try it out

• docker run -p 8080:8080 -p 1935:1935 adolgarev/nginxrtmp
• start OBS and specify RTMP URL rtmp://localhost/myapp and Stream key mystream
• Goto http://localhost:8080/dash.js/baseline.html

The result

The easiest way to use letsencrypt with jwilder/nginx-proxy

At jwilder/nginx-proxy issue can you add Let's Encrypt one can find discussion on how to add letsencrypt support for popular nginx-proxy for docker.
The easy way to do this that works for a while on our production environment is docker-letsencrypt-nginx-proxy-companion. Features follow.

1. Automatic creation/renewal of Let's Encrypt certificates using original nginx-proxy container.
2. Support creation of Multi-Domain (SAN) Certificates.
3. Automatically creation of a Strong Diffie-Hellman Group (for having an A+ Rate on the Qualsys SSL Server Test).
4. Work with all versions of docker.

Docker: lessons learned so far

Presentation on docker internals is available by link. Held on SoftServe DevOps workshop.

WildFly Swarm JSF example

WildFly Swarm now has a generator. Thus generating a pom.xml for JSF application bundled into one jar file has become super easy. See example below