Discover how Terraform IAC setup simplifies cloud infrastructure management, with a focus on Identity Aware Proxy (IAP) configuration on Google Cloud Platform (GCP). Learn from real-world challenges and solutions to streamline your cloud environment and automate processes.
I’ve been developing JavaScript through all of the major existential changes we’ve had. Browser wars? I remember those. Trying to make a complex application before Firebug? Oh yeah, tell me about it. Having to roll my own AJAX request by hand? Vividly remember.
Something that I experienced in all of my large JS projects before the last few years was an eventual point of no return, a metaphorical event horizon, beyond which the amount of time it took to build the code locally as well as on the CI/CD system was just simply too long.
All projects start fine, but as they grow and evolve and change over time, the amount of build time seems to creep up until it becomes inimical to deploying and testing changes in any reasonable time frame. Further, it becomes very difficult to onboard new developers as any change they make is not isolated, and must take into account all of the other code in the app. Granted, frameworks and libraries like React do help to some extent, but there are no clean-cut boundaries on the source code with different features, it always had to be by convention.
It was during a project a few years ago that I finally put my foot down and decided that something needed to be done. Researching how other architects were doing it, I came across JavaScript monorepos. I was familiar with the concept of monorepos from my research on how Google structures their code base (they have to repos, one for YouTube and one for everything else, no joke), but had never thought to apply that same principle to JavaScript. So I dove in head first, made a lot of mistakes, iterated, and finally got to a place where I feel comfortable sharing my lessons learned.
This blog post is not an extensive study, but it is enough to get you interested in a way to solve two common problems we all have (i.e. sluggish build times and inability to effectively onboard new devs due to lack of feature separation), and give you enough of a context around how I approached the problem to determine how you should proceed.
In every software application I’ve ever worked on, no matter the industry or maturity of the team or number of weeks in a sprint, there have been three questions that always come up: What is the best way to center a
? Should we use tabs or spaces? How should we implement complex workflows?
It was with that third question in mind that I stumbled upon a link in HackerNews a few weeks back on Temporal.io announcing that its .NET SDK is now in alpha.
If you aren’t in the know, Temporal is a library that lets you describe workflows as code. It’s available in multiple languages, but the Python flavor is the most popular.
So, I took a leap of faith, tried out the Temporal .NET SDK, and decided to recap my thoughts for you all as a blog. I’ll walk through, at a high level, what the Temporal approach is, the implications of workflows at the different zones of enterprise architecture, and where I see Temporal being useful in a large organization’s software strategy.
There is such a rich, user-driven ecosystem around React that it can be difficult to discern which frameworks, if any, should be used to develop enterprise-grade applications. This blog post dives into the most popular ones and analyzes which are most suitable for that specific use case.
Before diving in, please remember: the decision of which one is the right one for a given organization or application is very context-specific, so diligent consideration is required to ensure an optimal outcome.
Welcome to the fourth and final installment of Creating an FHIR API with GCP. So far, we’ve covered a lot!
We discussed the differences between Google and Azure, landing on GCP as the best option for FHIR in Part 1. We began our implementation in Part 2, creating both the BigQuery resources and your FHIR repository resources. And finally, in Part 3, we tackled authentication methods and populating data in our FHIR repository.
This time, we’ll wrap everything up with a nice little bow. First, we’ll finish our implementation, and then, I’ll share the limitation I found – for the sake of transparency. Let’s dive in.
