We’re excited to announce the official release of version 1.0.0 of the Nitric framework! Here's the story behind how Nitric started and what has led us to this release, told by our co-founder, Jye Cusch.
Video Transcript
We've been building Nitric now for well, for me and my partner Tim who started the whole thing, we've been at it for almost four years. And it came from a pretty unusual background compared to where it is now.
We used to work at a banking software company. I was running architecture for them. We had a team of about 2000 developers that were moving from all on prem, traditional java web application development to cloud development, fully distributed, totally new model for everyone. And we just saw exactly how difficult that was as a transition in particular for the team. Just all the new technologies and things to worry about.
So we actually built Nitric really just to make cloud applications that were portable. They could run on AWS or GCP or Azure without having to change much, if any, of the core code. And then when we open sourced that version of it, the first people who started using it were just building for one cloud. We got on the phone with them and were like, Hey, why are you doing that? Why are you using this thing that we designed purely for portability? And the first guy we spoke to gave us a really good insight.
He was saying I'm building for AWS for the first time. There are 10 different services I could just run my code on, let alone do things like messaging or data persistence or whatever it might be. So he was actually just using it as a way to delay his decision making because he could see under the hood it was possible to swap out the underlying components, and he was just fearful of making the wrong choice.
When we saw people were really using it, even just for one cloud, we went pretty heavily into that. And that's where the SDKs and things that exist now came from. Before that, it was all one big YAML file that just did deployments.
And V1 is really the last two years of hindsight, I guess, where we've realized some things in the underlying APIs that drive Nitric were a bit too opinionated in a couple of spots. So we're backing off on some of those opinions just a little bit. You can still do things the exact same way, but you're not forced down one path.
One really small example is when we implemented topics, we included a payload ID and a payload type along with the payload for the messages you would send to those topics.
Because we wanted people to do things like idempotent event handling. So if you have an ID in there and you have a payload type, you can pretty much uniquely identify it. But we realize in hindsight, that's for other people to decide if they want to do that or not. So those fields are being removed.
There'll just be a plain payload of an object and you can put whatever you like. If you want to put the ID in there still go ahead. But it won't be in there by default. We're also trying to make the local development a lot smoother as well, so we've got some visualizations and things happening now.
So as you're live coding there's actually a diagram that represents the logical architecture of your app that just auto generates itself. That was the same thing we noticed people were wanting help with was like, Oh, I've written this function and they didn't realize it was detached from things because they'd forgotten to attach a permission or something like that.
Well, now that line on the graph will just be missing. So it's easier to tell when things are disconnected or orphaned in some way and they can be reconnected and made to work.
Read more about Nitric version 1 and come chat with us about your cloud projects!
