Recently at work, we ran into an interesting problem (challenge?). We are running our microservice architecture on Kubernetes, and we keep all of our internal communication over gRPC. Even though we are able to scale up particular parts of our applications, we started to face some bottlenecks. After a while, we realized, that even though we have multiple instances of some parts, we have one active gRPC (HTTP/2) connections between each service, which results in a single connection between particular pods.
In the previous part of the tutorial, we've generated resource endpoints for managing skills data to be displayed on a resume page. However, the problem was that anyone who could see the page, might potentially access those endpoints and edit the data. In this post, we'll add a not-so-complicated authentication using an external provider (Github) to restrict access to those pages.
We've already created a dynamic business-card website, so what can be added now? Actually, we've connected it to the database but haven't used the feature, that makes managing data really easy and fun. If you'd like to have a neat interface to view and edit stuff from the database, then you'll love Buffalo resources.
The difference between websites and web applications is that the app does display dynamic data, while a simple site can just present some static values. So far we've developed a site because nothing can ever change there without us affecting a source code. It's time to change that and finally display something from the database.
This post is a short story about a bug that we found a couple of days ago in our backend application. The bug that originated with a simple mistake in an SQL statement, but it was the one we'd expect to be handled by the database itself. Some time ago we considered ditching MySQL for Postgres, and as a matter of fact, that switch would have saved us this time. Let's see how both products handle something we can call "casted joins".
Since we started working on our business-card website using Buffalo, we might have extended our business to serve clients from all over the world. That's great, but how can we do that if our website is in English only? We definitely need to allow users to use different languages and provide appropriate content for that.
Building a web page from scratch can feel like something complicated and time-consuming. It sure can, unless we are able to split our work into multiple smaller steps by extending the functionality with every iteration. Let's take a trip with Go Buffalo framework and build a business-card website with baby steps.
When serving web applications from your own server (or a dedicated instance in the cloud) you might want to allow an access to the users from all around the world. Giving out an IP address does not look very professional so you choose to have an awesome domain. What if you have multiple domains, though? Let's configure nginx server so that you don't have to pay extra and have everything in the same place.
Most of the applications we build need some kind of configuration that can alter its behavior. The level of logging, HTTP to run the server on, database credentials - you name it. While you can ship your app with YAML file, thanks to Docker (among others) it's more popular to use environmental variables. How exactly do we do it, though? Let's see what are our options.
Building a framework in Go is not an easy thing to do. It has little to do with the language itself, rather it's about the community approach to frameworks in general. We are about people who spend half of their time writing "if error is not nil" checks. Despite all that, a man by the name of Mark Bates chose this path and decided to create something that might revolutionize web development in Go. Let's dive into GoBuffalo, one of the most hyped Go-related things.