k6 – API performance testing tool

k6 is a developer centric open source load and performance regression testing tool for testing the performance of your cloud native backend infrastructure: APIs, microservices, serverless, containers and websites. It’s built to integrate well into your development workflow and CI/CD automation pipelines.

This is one of the better tools that I’ve seen in a long time. Not only it does its job great, but it integrates brilliantly with your development and testing pipelines.

You can either build your tests from scratch, or you can convert import them from your existing tools. For example, Postman collections, environments, and tests can be converted to k6 with postman-to-k6. Here’s a blog post to get you started on that path.

Side note: if you hit the “EACCES: permission denied, mkdir ‘/usr/local/lib/node_modules/postman-to-k6/vendor’” durin the postman-to-k6 installation, then simply append “–unsafe-perm=true –allow-root” to the “npm install” command, as suggested in this GitHub thread.

k6 provides excellent functionality for extending your basic performance tests with additional checks, metrics, and thresholds. You can even keep using your existing Postman tests within k6.

There’s also a variety of output formats, ranging from CSV and JSON, all the way to InfluxDB with Grafana charts.

Install Postman on Fedora 31

Postman is a great tool for building and testing APIs. Unfortunately, however, it doesn’t come packaged as an RPM, so there’s some trickery involved in installing it on Fedora.

This blog post was very useful, with some minor corrections. Here’s what I had to do:

  • Download Postman from the site.
  • Move the archive to somewhere global: mv Postman-linux-x64-7.16.1.tar.gz /opt/
  • Extract the archive: tar xzvf Postman-linux-x64-7.16.1.tar.gz
  • Remove the archive: rm Postman-linux-x64-7.16.1.tar.gz
  • Check which directories are in the path: echo $PATH
  • Create a symbolic link in one of path directories: sudo ln -s /opt/Postman/Postman /usr/local/bin/postman
  • Create the desktop file: touch ~/.local/share/applications/postman.desktop
  • Edit the file with the content below.
[Desktop Entry]
Name=Postman
GenericName=API Client
X-GNOME-FullName=Postman API Client
Comment=Make and view REST API calls and responses
Keywords=api;
Exec=/usr/local/bin/postman
Terminal=false
Type=Application
Icon=/opt/Postman/app/resources/app/assets/icon.png
Categories=Development;Utilities;

Now you can run Postman both via the command line (postman) and from the Gnome/Mate menu. You’ll find it under Applications->Programming.

Top 20 APIs You Should Know In AI and Machine Learning

If you are playing around with the artificial intelligence and machine learning, have a look at this list of “Top 20 APIs You Should Know In AI and Machine Learning“. These are nicely organized by subject as well:

Machine Learning and Prediction APIs

APIs for Face Detection and Face Recognition

Text Analysis and Natural Language Processing APIs

Notes to Myself on Software Engineering

I came across these “Notes to Myself on Software Engineering“, with which I agree wholeheartedly. Some of these I’ve learned “the hard way”. For most of these, I wish I knew them earlier. They would make my life a lot easier. Here a few to get you started, but make sure to read the whole list, as many of these apply to other areas of IT and life in general.

It’s okay to say no — just because someone asks for a feature doesn’t mean you should do it. Every feature has a cost that goes beyond the initial implementation: maintenance cost, documentation cost, and cognitive cost for your users. Always ask: Should we really do this? Often, the answer is simply no.

Invest in continuous integration and aim for full unit test coverage. Make sure you are in an environment where you can code with confidence; if that isn’t the case, start by focusing on building the right infrastructure.

Simple things should be simple, complex things should be possible. Don’t increase the cognitive load of common use cases for the sake of niche use cases, even minimally.

Because code is communication, naming matters — whether naming a project or a variable. Names reflect how you think about a problem. Avoid overly generic names (x, variable, parameter), avoid OverlyLongAndSpecificNamingPatterns, avoid terms that can create unnecessary friction (master, slave), and make sure you are consistent in your naming choices. Naming consistency means both internal naming consistency (don’t call “dim” what is called “axis” in other places) and consistency with established conventions for the problem domain. Before settling on a name, make sure to look up existing names used by domain experts (or other APIs).

Career progress is not how many people you manage, it is how much of an impact you make: the differential between a world with and without your work.

Software development is teamwork; it is about relationships as much as it is about technical ability. Be a good teammate. As you go on your way, stay in touch with people.

When we find ourselves in a conflict, it’s a good idea to pause to acknowledge our shared values and our shared goals, and remind ourselves that we are, almost certainly, on the same side.

API Platform – REST and GraphQL framework to build modern API-driven projects

API Platform is a framework for building API-driven projects. I came across this via this blog post that covers the recent release of v2.4. The list of features and components is quite extensive:

  • Read and write support for MongoDB
  • Read support for Elasticsearch
  • Message queues support via a number of brokers, including Amazon SQS
  • Server Push support for HTTP/2
  • Full compatibility with OpenAPI v3 (Swagger)
  • Automated admin interface and project documentation
  • A variety of components from the Symfony framework

I’m pretty sure that I’ll be taking this for a spin in the nearest future!