After being at the first API the Docs conference in Amsterdam in December 2017 and having really enjoyed myself, I quickly decided to attend the second API the Docs conference in Paris, too, immediately after it’s been announced. On top of that, I submitted a last-minute talk proposal and got accepted as a speaker. What I liked most about their first edition was that it’s highly focused on its topic but a small-scale event. In a single-track conference with less than a hundred participants, there’s a strong feeling of community. The second edition fully matched these expectations. My last blog post was well-received by the organizers and the community, so naturally, I had to write one about this event, too.

Anyone who follows the news at all will have heard the story of Cambridge Analytica who collected the data of 50 million Facebook users without their knowledge and consent. A lot has been written about it, with different actors trying to give a different spin to the story, showing Facebook as either victim or accomplice to Cambridge Analytica. As a result, people might become more mindful about the ways they use Facebook, and how much data they share with the company, some even go as far as to #DeleteFacebook, but those will probably be few (we’re also not leaving, the CloudObjects Facebook page is still there). You can also expect that governments will tighten regulation on the social media giant as well as companies with a similar business model and wealth of data.

One week ago on this day, I attended the one-day, single-track “API The Docs” conference in Amsterdam. “API The Docs” is a world-wide community with regular meetups in different cities, spun off from the “Write The Docs” community of technical writers. Their Amsterdam event was the second full-day conference, and it was run in association with “Beyond Banking”, an initiative of ABN Amro, which is the second-largest bank in the Netherlands. They also provided the venue for the conference, an event and exhibition space called Circl located in the Southern business district (Zuidas) of Amsterdam. The impressive building symbolizes the circular economy by being completely built from recycled materials and served as a great backdrop for a day of interesting talks and networking opportunities.

I’m happy to announce that CloudObjects has just launched phpMAE 0.2 and a public preview version of serverless phpMAE hosting. As mentioned in “The Micro API Design Pattern”, phpMAE is our PHP-based implementation of a Micro API engine (and that’s what the name phpMAE stands for, PHP Micro API Engine). The objective of a Micro API engine is to get developers up and running with a standardized set of dependencies that empowers them to quickly build and deploy integration code without managing infrastructure. You can download phpMAE from GitHub, run it on your computer and then use phpMAE in combination with the CloudObjects CLI Tool to deploy the code to our cloud-based hosting. During the current stage hosting is free for developers!

Software deployment on the Internet started with servers. Then, there was virtualization. IaaS (infrastructure-as-a-service), the first step into cloud computing, made it possible to provision virtual servers by the hour. PaaS (platform-as-a-service) was the next step to increase abstraction between the physical machine and the developer’s code. Finally, the trend of building microservices instead of monoliths and integrating APIs and remotely-hosted services led to the current stage of cloud computing with serverless platforms, or FaaS (function-as-a-service), in which small units of code are deployed and the whole infrastructure is managed automagically by the hosting provider.

Every business or project needs to get the word out about what they do in order to get people excited, sign up and eventually pay for a product, service or solution. It follows that marketing is something that every entrepreneur needs to think about if they are aiming for success. But marketing is a complex beast and there are multiple tactics and strategies available for the marketer.

PHP is a major programming language here at CloudObjects. And RDF is the format used for describing data stored in CloudObjects Core. These two reasons are more than enough to look into how to handle RDF data in PHP. Here’s how we do it.

Any code library requires proper documentation. Our own CloudObjects PHP SDK (which, among other things, wraps the Object API) is no exception. Without a properly automated process, however, documentation quickly becomes stale and no longer remains in sync with the actual implementation. I’d like to show you the process which we set up to automatically generate and publish documentation for the SDK as this might be useful for anyone releasing a PHP SDK or library.

I’m a big fan of IndieHackers, a website run by Courtland Allen (and now owned by Stripe) that features interviews with independent developers and small businesses who tell the story of how they built and launched their products. One recent interview that stood out to me was with Gregory Schier, the Canadian developer that created Insomnia, a multi-platform desktop HTTP client for developers to test APIs. Building a company that has APIs front and center myself I was interested in both the product and its backstory. In this article I’ll first be taking Insomnia for a spin and then give a summary of Gregory’s story and his advice for aspiring indie developers and startups.

I want to follow up on our recent introduction of CloudObjects Core with a practical example in which we’re gonna add a Web API object to CloudObjects. A Web API, to clarify the terminology, is any API that can be accessed via the HTTP protocol, irrelevant of its API design paradigm. One part of fulfilling our mission of “empowering developers with APIs & more” is letting developers discover APIs and access their documentation in human and machine-readable form in our object directory, so adding your own APIs into this directory is a great idea to increase discoverability and ensure smooth integration with future products built on top of CloudObjects.

In the first article on this blog, “Hello World!”, I said that we believe that “integrating and aggregating APIs and deploying code without managing servers is the way for building software today”. It also means you end up with a lot of building blocks from different vendors. And while the providers of these building blocks promise to make building a website or app as simple as putting LEGO bricks together, managing multiple vendors and integrations becomes a pain in itself. You have to sign up for each of them, create and configure your application with custom integrations and put configuration data such as API keys in different locations of your code.

Web APIs play a very important role in today’s software development. Just like designing user interfaces or creating a great system architecture, designing APIs is a craft of its own. When running a public API program this is obvious, but even when APIs are just used internally to connect microservices or you have a proprietary mobile app talk to its backend server it won’t hurt to give this a bit of thought. Due to the importance and depth of this topic it is something that cannot be covered in a single post so we plan to regularly revisit it on this blog to share experiences and compile best practices. Consider this the first article of a series on API design. For today, we’ll start with a look at API design paradigms. I’ve identified five of them: “whatever works”, command-based (RPC), CRUD/resource-based (“RESTful”), Hypermedia-based and query-based.

In a previous post about Docker base containers in general I had described different ways of deploying code with Docker containers and how we use them at CloudObjects. Today I’d like to describe one of those base containers, specifically one for PHP applications. The container is called cloudobjects/php-app-base and it’s public if you want to try it for your own PHP apps. You can see it on the Docker Hub where it’s being built automatically and transparently in Docker’s trusted environment, and also there’s the underlying GitHub repository with the Dockerfile for this image.

We use CouchDB as a part of our storage layer for CloudObjects. CouchDB is a schema-less document-oriented database. Database entries, or documents, are JSON objects. By default, these documents are accessed through their identifiers. Unlike traditional RDBMs, NoSQL databases like CouchDB do not have a default query language (SQL) to look up entries by anything other than their primary key. The alternative proposed by CouchDB are views, which represent a map-reduce approach to querying. A map function looks at each new or modified document and emits data with a different key into a separate index for the view. Consumers of the database can now also efficiently query the database with this new key through the view. An optional reduce function can be used to further aggregate data. This article only deals with the map part.

Here at CloudObjects we are running a number of applications and microservices as part of our backend infrastructure. Each of them runs in its own Docker container. As many of them share similar technology stacks, the obvious approach here is to create a base container image and then deploy multiple containers with different source code files for each application or microservice.