On a recent project we were asked by a client if it would be possible to host a React app using serverless technologies, but also ensure that traffic never left their VPC and corporate network.
In this post I'm going to talk about how we achieved this outcome, and how it proved to be more of a challenge than we first thought it would be.
In this post I will show how you can use tfsec to run security checks against your Terraform code, and address any issues that it finds. Furthermore, we'll use the...
Learning how to write a GraphQL server is one of the biggest challenges I've seen for those who are new to GraphQL. This is because it requires a change in mindset, especially if you are accustomed to writing REST servers. Specifically, instead of thinking in terms of implementing individual endpoints in isolation, you have to think in terms of implementing an entire GraphQL schema that can be queried in any way.
This need for flexibility can cause anxiety for some developers, especially when it comes to performance. To deal with these concerns, some developers panic and pre-emptively reduce the flexibility of their GraphQL schema to head-off anticipated issues. But in doing so, they start to negate the chief benefit of using GraphQL in the first place: being able to flexibility and efficiently access data over a network as slow and laggy as the internet. Taken to the extreme, developers can even end up in a situation where they're paying all of the additional cost of using GraphQL, but not reaping any of the benefits.
It's true that strictly speaking, the easiest way to write a GraphQL server isn't necessarily the most performant, especially in comparison to writing an equivalent REST server. This is part of the trade-off of using GraphQL. However, it's also true that the majority of the time, this performance difference won't be noticeable to the end user. Furthermore, even if it turns out that there is an actual performance problem, there are plenty of mechanisms available to deal with it, without compromising your schema.
In this post I'm going to show you an example of a common source of performance anxiety for GraphQL server developers, and how it can trick them into thinking that they're going to have to make adjustments to their schema to deal with it. I will then present an alternate approach that allows the best of both worlds - a performant solution and the simplest schema possible. In this case I'll be using Apollo Server to write the server. I'll be assuming you have some knowledge of both GraphQL and Apollo Server.
In this post, I analyse a performance problem in a serial processing project, propose a solution and demonstrate the performance improvement in a proof-of-concept application written with Golang....
In this post I am going to talk about a question that can save you a bunch of time and effort, but is sometimes neglected in the rush from problem...
NewRelic is a powerful platform that helps users monitor the performance of their services. I'll show you how to use Terraform to create a NewRelic dashboard and set up an...
In this post I will walk you through some of the complexities of developing for Bluetooth on iOS, starting with the core concepts, then moving onto my experiences building a...
TL;DR We’ve all heard that Lambdas written in Java are slow, but there's more that we developers can do to help improve Java Lambda execution times, especially from a cold start....
In this post we will discuss and explore methods of navigation flow and view construction in SwiftUI. In particular, we will explore a method for abstracting both of these activities...