KrakenD is exciting. Among all different features there’s one tech that’s particularly interesting and helpful. It’s possible to define an endpoint that calls several underlying services (either sequentially or concurrently) and merges the responses.

When it’s sequential calling, it even lets you use the data returned from the previous calls in the following. However, at the moment of writing (KrakenD 2.0.5) it’s limited to using JSON field values as parts of the request path only. You cannot compose bodies of following requests using this data declaratively.

Recently we’ve started working on an experimental internal project based on microservices principles. We’ve broken down our application into contexts using several event storming sessions, defined events, commands and aggregates. When it all took shape, we sat and started working on services.

Two months into development I went talking to the frontend team only to find that they would be more than happy to see a single entry point into API.

In some of our projects where we need flexible fuzzy search capabilities with weighted results we use Elasticsearch. It indexes everything you throw at it, then gives you tools to search it flexibly.

In this short article I share the approach we used to sort the weighted output additionally basing on certain criteria.

IMPORTANT UPDATE

P2P Telehealth has been rebranded as HiDoq. At the moment we have several servers working with clients in the following regions:

• Hidoq Australia
• Hidoq Global
• Hidoq Ireland
• Hidoq New Zealand
• Hidoq UK

Earlier this year together with two partners we started a small company to work on P2P Telehealth – easy to use, compliant and secure telehealth platform. It’s like Zoom or Skype, but for health providers, clinics and their patients.

Anyone with no technical background should be able to join the consultation in seconds. No new apps needed. I think we succeeded.

Today I focused on several things:

• Converted functional code into classes
• Extracted general purpose pieces like the driver and the module to prepare move sequence buffers into a library
• Built the rest of the custom code on top of it
• Made the bot go back a step
• Made an improvement to how the step is made which increased precision
• Updated calculations to take the base piece length into account. Next comes turning, and this will become handy.

Rework of the code is complete. Now it’s completely based on the timer interrupt. I must admit, it’s a huge difference in the way motion feels and is programmed. The level of control over what happens and when is tremendous. Exciting!

After a bit of experimentation I finally figured that working with servos from the main program loop is not very efficient and precise. The main issue I’ve been facing is synchronous and controlled rotation of several servos to different angles.

Short recording of the first baby steps. Woo hoo!

In my daily work I’m going back and forth between Rails and Phoenix with the healthy dose of LiveView. This change in paradigm sometimes shoots me in the leg. This post is written in the form of a self-reminder.