When building a microservice architecture, two of the most common approaches are a common messaging queue and HTTP APIs that are exposed and consumed by each element of the project. Despite those approaches being perceived as well-known and battle-tested, the community warmly welcomed another player to the game - gRPC. This is an introduction to this way of communication, and the story has, to begin with, a date with Protocol Buffers - something that sets gRPC apart.
So far we've seen how to build a GraphQL API that serves the user with data stored in the databases. But what about making changes? With a few tweaks in the structure, we can achieve this as well. Let's take a look on things called mutations.
Building an API in GraphQL looks very easy, as you could have already seen based on two previous posts. The thing is that everything looks simple when no parameters are provided, right? Let's take a look at how to make our API just a bit more dynamic.
In the previous post, we've seen how easy it is to set up a simple GraphQL server in Golang. The problem is, that we have hardly done anything special, that would distinguish our API from one written for REST. It's time for something more advanced, that is nested objects and fetching them from different sources.
For a long time building an API (eg. for web applications) has become associated with REST. Meanwhile, less than two years ago, Facebook announced a technology they've been using for some time called GraphQL. It's an alternative way to provide data to the users, where each client can squeeze multiple queries into a single one.
Any web application that is targeted to more than one user is likely required to have some kind of authorization technique so that it can determine if given user can execute certain actions. The problem how to do this remains, despite dozens of years passed in software development world. One of the approaches, gaining much popularity recently are JSON Web Tokens. This short post shows how you can use them in your Golang application.
Having played with nginx both as a simple file server and a reverse proxy, it's time to explore another way it can easily improve your application. Using it as a load balancer can give your application a boost in the terms of availability, while not requiring that much of the configuration. Just take a look.
I've been around the language for over 18 months now and I'm still very excited about it and keep learning new things that can be done and how they can be done. But what is it that makes Go so great exactly? Let me share some thoughts as I'm flying back from my first Go conference, GoLab 2017.
It's often assumed, that if you split a web application into a back-end API and front-end static files, you should have two separate servers for them. While this might be a good idea from an architectural point of view, you might want your end users to see the product as a whole. Fortunately, with nginx you can easily set up just that by making it act as a reverse proxy.
Whenever you are building a web application, you can generally divide it into two parts: a backend API, which is hosted on some specific application server and a front-end website that consists of static resources like HTML, Java Script and CSS. But how should you serve those files to make them accessible to the end user? One of more popular solutions is use nginx.