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.

I still remember the birth of IaaS (infrastructure-as-a-service) when Amazon launched EC2, the “Elastic Compute Cloud”. At that time Amazon Webservices was all about APIs. You needed to make API calls for everything. There was no AWS console, you could only sign up through the web and that was all there was. If you didn’t want to use the command line to provision servers or build your own API client or integration to manage them the pretty much only available tool of choice was Elasticfox, an unofficial Firefox browser extension that provided a visual user interface to EC2.

Welcome to the CloudObjects Blog!