When it comes to senior engineers, most non-tech or some techie people start assuming that senior engineers mean they know "how to code" better than the other non-senior ones. This statement can be considered true, but it does not do justice to the real ones.
My personal belief is that senior engineers have qualities that are not limited to just "better code." In fact, in a very controversial way, I can proudly say that there are some senior engineers who code similarly to non-senior engineers, but still they are better at their jobs than the non-senior ones. Yes, code is not the only parameter to measure seniority. It is mostly about your thinking process, approach to solving the problem, and whatnot!
Thank god we are not here to understand the role of senior engineers just by throwing out some techno-philosophical words. I am going to detail a real-world problem that I solved at work, which will help you understand the title of this post.
The Problem
GitLab allows 5 users to use the free tier of their app. We have our previous website's (solutelabs.com) codebase & CI hosted on GitLab. We have our blogs hosted on Headless CMS Sanity. When there is a content change, we need to run a pipeline to get all the latest content from our headless CMS. Now, the changes are handled by our marketing and branding team and we should not/cannot give access to GitLab to them as they are non-technical users. We could have put a webhook in Sanity itself, but there are some problems if we do that, which we will not discuss in this post. We will just assume that it cannot be done.
So, the bottom line is that the marketing and branding team needs to trigger a pipeline themselves without access to a GitLab account.
Suggested Read
Why Is Next.Js 15 Revolutionizing Web App Development?
View Blog
The Rumination (lasted for 5 minutes 😇)
Rumination means thinking about a solution to a problem for longer.
The rumination and the period it lasts can explain the seniority of an engineer. When I was introduced to this problem, I simply thought - there must be some way to trigger the build from outside of the GitLab app ecosystem.
When Continuous Integration (CI) is implemented, it typically involves triggering multiple webhooks for various purposes. And it is GitLab's app (or backend) that is triggering those webhooks. Now, here it is, as my inner senior engineer wild guessed - there must be GitLab REST APIs (might be free to use, might not be) that can be available for us to do so.
I named it a wild guess, but, to be honest, this was not a wild guess. The reason is that I am a big fan of automation and have always brainstormed on the architecture of how CI platforms work. While utilizing GitHub Actions on a late Friday night, I delved into the codebase of an individual GitHub action to grasp its inner workings. Upon investigation, I found it comprised only REST APIs from GitHub and nothing fancy, not even a software SDK.
This gave me an idea about different CI platforms' architecture and not just GitHub Actions. That late Friday night, when I explored GitHub Action's code base, was fruitful after all these years.
This exploration was not out of the blue; I hate blackboxes in general. I hate when something is magic to me; I always have the urge to open things up whenever possible. I always look into my node_modules, the open-source library's codebases, and whatnot.
Suggested Read
What Is CI/CD In DevOps - Introduction To The CI/CD Pipeline
View Blog
Here, I quickly grabbed the documentation of GitLab REST APIs and figured out a few useful APIs as per our use cases.
1. Trigger pipeline API -> from which they trigger the pipeline
/api/v4/projects/{project_id}/trigger/pipeline?token={api_token}2. Fetching the latest pipeline status -> They can see the latest pipeline status and how much time has passed since running it.
/api/v4/projects/{project_id}/pipelines/latestI figured there was a way, but the challenge was that the api_token required to trigger the pipeline might get exposed to the client-side env variable, making anyone trigger the pipeline once they just got access to the app.
I leveraged the use of the /api folder in the NextJS app and exposed an API that worked only on giving some passwords pre-stored in the NextJS backend; hence, there was no need to know a fancy API key, only an easy password entering the frontend, which solved the problem for the marketing team to trigger the pipeline.
I did not just give them the flexibility to trigger the pipeline, but I also gave them a UI to show the status of the latest pipeline status as well. You can visit the repo that has been recently pushed to GitHub.
Visit here ->mohitsinhchavda/gitlab-remote-triggerrer (github.com)
Also, keep in mind that this was for an old tech stack of our website, and now we have updated our tech stack to use Incremental Static Generation (ISR) of the NextJS.
Wrapping Up
So, this was all I wanted to share. If you aim to be a senior engineer, don't just aim to code cleaner by following all the problems. Start thinking about real-world problems around you and solving them. Sometimes, it doesn't matter how simple the code of my solution given above is; what matters is that I approached the problem by taking it as a challenge and solved it by giving a minimalist solution that required the least amount of code, but it solved a ”worthy of being called” big problem for us.
Here's an example of how SoluteLabs encourages its team to come up with ways to close the gap between technical complexities and user needs.
At SoluteLabs, we offer comprehensive digital transformation services, including AI integration, UI/UX design, Cloud & DevOps. With a team of experienced professionals and a proven track record, we can help your organization develop a tailored digital transformation strategy.
