Don't use Faktory if you need high reliability
Just in case one of my projects needs a background job, and my company is using Faktory here and there, I spend some time studying this background job engine.
Random thoughts
Just in case one of my projects needs a background job, and my company is using Faktory here and there, I spend some time studying this background job engine.
What is news: Gobench is supporting gRPC, both unary RPC and streaming. Now you can use Gobench to benchmark servers with HTTP, MQTT, NATs, and gRPC.
I am developing a benchmark framework named Gobench forks at Veriksystems. What is special about this benchmark? Well, it supports more than just HTTP. We are having MQTT and NATS. You can also write scenario in Go. And it will be distributed.
GraphQL has been being talked a lot recently, thanks to many cool features like strong type, no more over/under fetching like REST.
IoT protocol nowadays is much about MQTT. Let’s face it. AWS IoT is about MQTT (over TCP and WebSocket). Google Cloud IoT is also MQTT and HTTP. Azure IoT is MQTT, HTTP, and well AMQP.
We at Zinno Inc has been working with Alexa for our smart home system for about a year. Believing voice control with Alexa is the key feature for home automation, we should submit to Alexa skill store.
One of the new things that Amazon IoT adding above MQTT is the shadow doc. Shadow doc provides a traditional way (aka HTTP) to get the current status of a device that connects via MQTT.
Years before I found my self little time to sit down and read; because of many excuses: I tired after a long working day, I needed time to exercise, I needed time to date, I needed time to social.
I am writing more Go services enough to just forgot the current version in production/staging. With nodejs, it is as simple as exporting from package.json.