For someone who’s creating web-apps for the first time in their life, the typical tutorial on REST can be confusing. There is a lot of theory that might be difficult to understand. This tutorial aims to do the opposite. It starts with the practical application and examples, and skips the theory. There will be links to other articles towards the end, which explain the theory in detail.
Who is this for?
This tutorial is aimed towards beginners who are starting to learn web-development, and are trying to understand what are REST APIs and how to design them, or have started…
TLDR: Graphql-Mesh allows you to transform existing APIs and datasources like REST, SOAP, or even Database to GraphQL directly without rewriting any of your APIs.
Sometimes, there are REST APIs that you want to translate into GraphQL. It could possibly be for a simple BFF, or maybe we want different clients to have responses in different formats, but don’t want to rewrite the entire API.
How should we do it? One way is doing it manually. It should be really simple. But it’s tedious and repetitive. Which tells us that this should be a job best done using automation.
In this blog post, we will aim to understand how using code for server infrastructure provisioning can reduce the man-hours required by hundreds of times, and also improve uptime drastically.
Environments for a Standard Web App
Let us consider we are building a standard web application of a small / medium enterprise. We would have atleast 4 different environments —
1. Pick a feature to implement and see which part of code will it deal with. The best time to cleanup a piece of code is when you are adding a feature to that part of the code.
2. Break the code into smaller methods, rename variables to more meaningful names.
3. Is there duplication? Can we extract a common method to remove duplication of logic?
4. Simplify complex conditional statements, break loops into smaller ones.
5. Look for one of these three problems —
If you are not aware of what pair programming is, I would recommend reading about it first to really benefit from this blog.
Team practices need to be adapted when we’re working remotely. We cannot use the exact same way of working over video calls as we did when we were colocated in offices. Let’s have a look at how pair programming can be adapted to suit remote work during the Covid-19 pandemic.
How does pairing work for remote teams?
You will need to use a video calling tool like Zoom, Google Meet, or Skype to share the screen and…
AWS has its own CI/CD solution called Codepipeline. Some people are excited about it, while others want to stick to their tried and trusted solutions.
Here, I attempt to list the pros and cons of Codepipeline and whether you should use it.
When working on AWS, we have multiple IAM users to manage. Even if someone is the root user, they should generally use the IAM user for day to day account management.
As an organisation, it is also recommended that you separate resources into atleast 3 different accounts: a sandbox account for experiments, a dev account, and a prod account.
With this, it becomes a little confusing as to which account is which. For example, is account number 219066881281 my production account or dev account? What about 917733831218? (PS: These account numbers are fake).
In Terraform, you can easily destroy a resource by either running terraform destroy (with or without resource targetting), or removing the resource / changing the configuration.
When we are dealing with S3 buckets, there are multiple scenarios where we might not be able to easily destroy the bucket. Here are a few of them, and how to deal with each of them —
The Prevent Destroy flag is on
The purpose of the prevent_destroy flag is to mistakenly destroy S3 buckets that we did not really want to destroy. For example, let’s say you have the following snippet —
The modern day software developer needs to learn a new technology every 3 months. To enable this, the developer needs a hands-on, breadth first, iterative approach to upskilling in the 2020s.
Back in the Day….
20 years ago, in the year 2000, the path to building a career as an App Developer was pretty standard.
There was a lot of learning in the first 6 months to a year. The individual had to learn a framework like J2EE or .NET, …
Summary: This article argues that there is an important step when switching from a Monolith to Microservices : Creating Modules.
Microservices are the rage nowadays, and for good reason.
Martin Fowler has written these lines about Microservices on his website —
…the microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable…
…which may be written in different programming languages and use different data storage technologies.
Educator, Founder @ Interleap