Author: Matt Tanner

When it comes to building an API, Go is an extremely popular programming language choice to build powerful RESTful APIs. The language is super lightweight, has many different libraries and frameworks available, and is easy to run. One of the frameworks supported by Go is Gin. Gin is a web framework written in Golang that offers great performance and scalability, amongst other features. According to the Gin website, “Gin features a Martini-like API, but with performance up to 40 times faster than Martini”. This tutorial will build a simple REST API using Go and Gin. The API endpoint will allow a user to retrieve a credit score rating. Of course, we won’t be linking up to any backend systems to pull a credit score but will instead use a random number generator to generate the score and return it to the user. Although simple, this tutorial will show you the basics of REST API development with Go and Gin.

API providers need to understand how their consumers are using their APIs. Usage metrics are essential because they tell you about API adoption, how your API is growing over time, and which endpoints are seeing more (or less) use. When you look at API usage metrics, you should be measuring the active users on your API in the sense that most closely aligns with your service. This informs where your organization allocates compute resources, which API endpoints you decide to develop, and which API endpoints you document.

What is an active user? At first glance, it may seem like simply tracking the number of users using an endpoint. But API users can’t be tracked in the same way as website users. Instead, you need to look at how your users access your API in the context of your product.

The technology you choose to start your project with determines what your product is capable of now and what it will be capable of in the future. Finding the right stack to build on top of is one of the biggest engineering challenges you can face. Picking a stack that allows you to build a product and get to market rapidly is great unless that same choice limits the scalability and features of a product in the future. Pick a stack that is well beyond your current and future needs, and this could lead to difficulties building the initial project you’ve set out to build. A balance must be struck between your current needs and the needs of your product and customers in the future.

When it comes to making money from your APIs, picking the right stack can help you get up and running quickly and allow for flexibility for your business and its customers. Let’s take a look at a few ways to assess which stack best fits your API monetization needs.

In this article, we will take a high-level look at the differences between an API proxy and an API gateway. When a developer publishes a public API, it’s necessary for that API to have security policies and a way to hide backend logic from API consumers.

Decoupling your API from your backend services allows you to shield your apps from backend code changes, and allows users to call your API without worrying about availability. If changes are being made to an endpoint or if a new version is released, users can continue on without interruption. Additionally, an API proxy or an API gateway can help you easily and uniformly secure your API endpoints. This can add another layer of defense and prevent attackers from infiltrating your system.

New technologies always require some planning, changes, and experimentation before they merge into an enterprise stack. GraphQL adoption has been no exception to this. Companies like Airbnb, Netflix, Shopify, and other industry giants have all taken the leap to use this promising technology. In this article, I will outline a few key considerations for creating your new service, deploying it, and monitoring the service. This assumes that you have a basic understanding of what GraphQL is, some of the key use cases, and awareness of some of the concerns in regards to adoption. With that in mind, let’s jump in.

GraphQL vs. REST

Before you begin to build your GraphQL service, it’s important to consider the reigning approach for building Web APIs: REST. A common misconception about GraphQL is that it is a replacement for REST. Thinking of the technology in this light would be very wrong. Both GraphQL and REST can be very complimentary and most enterprises will use a mixture of both approaches.

TTFHW is not the most common acronym you’ll hear in the tech and product domain. Even though it’s not extremely common, it can be argued that it is one of the most important acronyms for companies trying to scoop up and deliver value to new users.

TTFHW, or Time To First Hello World, is likely something you’ve already thought about. Many product-led enthusiasts refer to it as the customers’ “aha!” moment. This is the moment when a customer first derives value from your platform. Something many programming languages and programmer tools refer to as a “Hello World” moment. It’s a make-or-break milestone and one that you obviously want every customer to experience. TTFHW is simply the amount of time it takes to get to that “aha!” moment.