How Blackbird Revolutionized Microservices Development for Maximum Efficiency
What I Should’ve Done Instead: Enter Blackbird
So How Did Blackbird Help?
What Else Can You Do in Blackbird?
Who Is It For?
Looking Forward- What I’d Like to See Next
Feedback
Project: To create a Microservice based Demo Application
I’m in charge of solution engineering for two of our products at Ambassador and I set off to create a microservices application a few months ago because I wanted to build something from scratch that I could use to demo our fleet of products (Telepresence and Edge Stack). I envisioned creating something that was approachable to our prospects but clearly showed the value in a real-world business use case. I landed on creating a simple banking app to demonstrate security, authentication, and rate limiting could easily be applied (with Edge Stack API Gateway). Also, as I rolled out new features, they could be tested before going through the commit process with Telepresence.
I created an API spec with the basic routes I thought I would need and got to work. The first issue I encountered dealt with my backend API. I had created all of the paths off my API spec, but I realized that I hadn't fully fleshed out the paths. I needed to add additional sub-paths for features I intended to implement in the initial release.
My API quickly became unwieldy, and while it handled the core functionalities, the file turned into a disorganized mess. Functions, handlers, operations, and routes were all located in the same file. While I stayed focused during the build, I spent an embarrassing amount of time afterward refactoring the massive
api.goOnce I refactored the backend and connected it to a simple Postgres database, I began working on the frontend. With almost no frontend experience, I chose Expo after some research to quickly get something up for the initial release, knowing I could change it later.
Learning React Native was slow, and I hit another issue: The way I had configured my backend API didn’t exactly work with the way that I needed my frontend to work. While I added some cool features, my backend was designed for frontend needs, not how it would use them.
After countless back-and-forth adjustments, I finally got the frontend working with the backend, despite constant unintended consequences. It took three times longer than expected, but in the end, the demo worked. However, it was far from the most efficient process.
I eventually got all of the features in my frontend to work with the backend after jumping back and forth about a billion times. It took three times longer than expected, but in the end, the demo worked. However, it was far from the most efficient process.
So why am I making this blog?
What I Should’ve Done Instead: Enter Blackbird
It was about halfway through my project that I heard rumblings about Blackbird being ready for beta testing (our new API development tool). I knew that we were creating it, but since I had been responsible for our other products, I hadn't paid much attention to it.
I honestly wish I had looked at it while I was creating my demo, because it would have saved me countless hours.
The two issues that I mentioned were centered around two things. The first one being that I had created an API spec before-hand, and I unsurprisingly had to expound on the details when building the actual API. This meant that my API spec no longer matched what I had built, and from that point on it was a ping pong match between my frontend and my backend.
The second issue was that even though I had fleshed out my backend, there were things I didn’t know how to handle until I encountered them on the frontend, which only made the ping pong match more intense.
So How Did Blackbird Help?
Blackbird kept me honest. It enables parallel development, advanced API mocking capabilities, Instant API testing and debugging, and, as a cherry on top, a persistent deployment that is completely self contained.
Blackbird (you can access directly here Blackbird Access) lets you either bring your own API spec or generate one using AI. Using that spec it will instantly spin up a mock server with a public URL allowing you to constantly validate your api spec with what you have built either on the frontend or backend. I say it ‘keeps you honest’ because it acts as the official starting point (by generating the scaffold code based off of your spec) and finish line while keeping those really cool features at bay.
Project Organization & Time Saved
Remember how I said my original backend API was functional but really messy? When Blackbird generates the scaffolding, it generates an entire project folder on your local machine that's already organized. Now it did take me a second to get familiar with the project file structure, but after I did it was an unbelievable time save. It was already set up for a production level application, it had written the boilerplate code for my handlers, routes, services, helpers, basically everything I needed except the business logic and database connection.
Run Code Locally
Now, let's say I am building out my frontend application using my persistent mock that's been deployed by Blackbird and I want to test the business logic that I have created in my backend. Blackbird lets you run the backend code on your local machine (using some black magic, fairy dust, or the seventh infinity stone Marvel didn’t tell us about) to intercept the mock server and temporarily replace it with your real code. This allows you to actually verify that your application is working as intended, not just with the mock. This blew me away.
I’m not a fan of working with just a mock to design separate parts of the app, but now I can connect the entire application and make it publicly accessible without setting up anything. We can also attach a debugger to set breakpoints and troubleshoot.
I can not only run the code temporarily, but I can also create a steady-state deployment with business logic enabled whenever needed. Blackbird makes the code deployment persistent (so even if I turn off my machine, my team can still access it). This allows me to release backend updates, deploy them, and let frontend developers continue working seamlessly.
With Blackbird, my process becomes a whole lot simpler. I have to input the business logic for my API, build the frontend (which I can constantly validate to spec that actually matches my code), run my code from my local machine to test it against my frontend, and deploy it for a more permanent environment.
What Else Can You Do in Blackbird?
Modularity
While using Blackbird, I realized a few things. First, Blackbird is modular. The path that I mentioned before is the path that I used, but it's not the only path. You don’t need a mock to create a deployment, you can pass whatever image you want and create a publicly accessible url that's running that image. You can also already have API code, and use the ai spec generator to generate the spec.
Mock APIs Away
Second, I realized that Blackbird can function as a highly advanced mocking tool. When it generates the scaffold code, all that's missing is the business logic. If you add canned data, you can create a mock that closely resembles a production environment. Initially, I didn’t see the value in this, but then I remembered a tool I helped build at a previous startup. It let companies generate API specs and documentation, but the mock was limited, with separate URLs for each endpoint, no persistence, and no real logic.
With Blackbird, you can deploy a persistent mock for Partner or Internal APIs used in development. This offers production-like responses without data concerns, reducing the need for environment setup and lowering traffic for testing.
Finally, Blackbird hasn’t even been fully released yet! The value of its basic feature set is already impressive. I can only imagine the new use cases that will emerge as it becomes fully available on October 1, 2024
Who Is It For?
Blackbird is for anyone and everyone looking to develop APIs. I see Blackbird as the entrypoint for students to learn how to build a web application. I see Blackbird as a low-cost way for an individual developer to get an idea of the ground, or expand an existing application. I see Blackbird as a way for large organizations to have an API catalog with processes in place to enable their developers to build efficiently and successfully while lowering the costs associated with ephemeral environments and infrastructure upkeep.
Blackbird API Development is versatile, approachable, and powerful. You get out of it what you put into it and since you can use any of the features independent of the others, the use cases throughout the endpoint lifecycle are numerous
Looking Forward- What I’d Like to See Next
There are so many ideas I have for Blackbird, and features I would LOVE to see added in the future, and endless possible use cases. I truly think that it will change the way we develop APIs both at an individual developer level as well as at an efficiency-driven organization.
More Discovery
I mentioned it previously, but Blackbird can act as an API catalog for large organizations. It can be the home for all API specs, and current development. In the future, I would love to see the ability to automatically discover APIs by crawling through a git repository (or multiple). Keeping the specs up to date and notifying developers when changes have been made would be very useful in my opinion.
Spec Iteration
APIs are always changing. Pretty much as soon as we finish the first version, we are planning for the next release. I would love to see the ability to iterate on an API specification, while keeping/maintaining versions, version history, and statuses of said versions. I know this is in the roadmap eventually, and I foresee Blackbird being the central location for companies to monitor their development while also seeing what APIs are currently available, deprecated, or in development.
Less Siloed Deployments
Currently deployments are siloed. In my application, my backend talks to a postgres database that's running in a remote environment. That means that I can’t actually keep my backend in the deployment and use it as the application permanently. Obviously, Blackbird isn’t meant to be a space like Heroku, but I would love to be able to configure my backend to be able to send out requests to my database just as a last check to verify it’s working properly.
Exporting the Code
The last stage of Blackbird, in my mind, should be exporting the code to absorb it into my own infrastructure. Currently there is no easy way to do this. You would basically have to take the project folder and morph it into whatever type of deployment your infrastructure is currently running and go from there. This is something that I know is on the way according to the product team, and with Blackbird still being in early access is understandable.
Feedback
Anyways, I’d love your thoughts as you try out the tool. And if you have suggestions on other things you think would be beneficial to add to Blackbird, I’d be happy to pass that along to the team’s that are working on it.