My first project at agap2 IT gave me the opportunity to get a taste of what the Google Cloud Platform has to offer for businesses and those interested in modern web app development in the cloud.”
The client that I first worked with when I joined Agap2 is a Google Cloud Premier Partner who specializes in - among other services - application development, machine learning and big data & analytics on the Google Cloud Platform (GCP). For me, having developed for the web for several years in the past (although not in the past two), it was still a challenge to adapt to a very different approach to architecture, deployment and some modern technologies.
I joined as a Backend Software Engineer, initially working mostly with Python on Google App Engine (GAE). My first client project involved a medical application, which at the time was in a Proof of Concept state, and I was tasked with bringing it to a production-ready level, mainly focusing on writing automated tests, while also deeply cleaning up and re-structuring the code. My teammates worked hard to achieve the same for the Polymer frontend.
Side note: Working with GAE was easy, for the most part - but it does not come without some limitations and head-scratching. For instance, we had trouble sharing Python code between services, and after exhausting options such as symlinks (GAE ignores them), the not-so-elegant solution was to simply copy the code around (automated) and check it in to source control.
Afterwards, I got assigned to a project that was just starting - a client (who provides welfare equipment) needed a specialized web portal for user-, order-, product- and other data management. The portal had to be linked to their existing on-premises systems, on top of which the client’s team started creating a REST API, closely collaborating with us throughout the entire project.
At this point, I was getting comfortable with (parts of) the enormous GCP landscape, but then, new challenges faced me in the form of technologies, most of which I haven’t used before. The portal is hosted on Firebase - Google’s convenient mobile- and web app development platform - where the Angular frontend connects to Firestore - Google’s fully managed, scalable, high performance NoSQL document database - with several event-driven Cloud Functions (Node.js + TypeScript) serving as the backend. We eventually extended this backend with many more HTTP Functions, which became the portal’s API.
Side note: Allowing the SPA to read (or even write) data directly from / to Firestore feels dangerous and a bit of an anti-pattern to me. After all, it’s a document database, meaning there’s no schema, and the code executing on the client browser can (by default) write any data structure it wants. This can be mitigated somewhat with Firestore Security Rules, but that can get ugly and complicated easily. I did write many such rules though, to make sure users with certain roles and properties are siloed, and cannot read / write data that’s off limits to them. These can also be tested quite well with Google’s “security rule simulator” libraries, which I used for writing countless test cases. In the end, as the portal grew, we decided it’s safer to write well-defined data structures to the DB only through an API (with rigorous checks), while still getting the benefits of real-time updates by allowing direct reads.
The project has been a success. For a new, potential big client, I was tasked with developing a Proof of Concept app - to be used on mobile - within a limited budget that gave me roughly 10 full workdays (spread out over time) to deliver. The goal was to implement an app that takes a photo of a “component” (wind turbine parts) and identifies it using pre-trained Machine Learning models on Google’s Vision API. It also had to support OCR (text recognition) as well as QR- and barcode recognition.
I was a solo developer on this project, working with a colleague who trained the ML models based on the many photos received from the client. Utilizing my newly gained knowledge from the previous project, I set up an Angular app with a “webcam” library, and a simple backend using (HTTP) Cloud Functions for Firebase. It turned out that Google’s QR- and barcode recognition offering can be used only in native mobile apps, so I had to improvise and use third-party libraries for this. In the end, the app worked quite well once you signed in using Firebase Authentication, and this short “Phase 1” project became a success, enabling deeper collaboration with the client in the future.
I also worked for a while on a project that centered more around Big Data and Google’s BigQuery. I implemented a REST service (written in Kotlin, yet another new-to-me language) that aggregated and processed several sources of data from the data lake, first directly, then later by pushing the aggregated data to Firestore for better latency. It proved to be quite a challenge to migrate more than 30 million entries from BigQuery to Firestore, given its usage limits - which I solved by multithreading and batching, among other tricks, to finally make the batch run under 2 hours.
All in all, working with the client for about a year was very exciting and an enriching experience, and I’m grateful for all the new things I’ve learned while working and collaborating on interesting projects.
I would encourage anyone to look into GCP as a platform for their web app needs. Google’s cloud offerings are growing still (Cloud Run is fairly recent). It does come with its own quirks though, which can sometimes cause frustration or require workarounds - but what doesn’t?
Ádám Bodorkós