Listen in to these snippets from a conversation where our co-founder, Jye Cusch, describes how Nitric was designed with customization and flexibility in mind. Reach out if we can help you with details about customization for your project!
Video Transcript
Using Resources Not Natively Supported in Nitric
How can you bring things into your solution that aren't supported by Nitric? Really good question. Really, really common. The very first customer we were working with, that was the first thing they wanted. They wanted to use AWS Rekognition to do some image processing, and that's not something we support.
We've similarly done some things with raw Kubernetes and Docker containers for a healthcare company that needed to do some data pipelines with the programming language R, which is obviously not a language that we've supported and would be a pretty tricky one, I think. The way that we typically do it is you would still leave the core of the application built with Nitric, like all the things that are supported would still be built that way.
And then in the deployment pipeline, we typically run either Pulumi or Terraform or whatever the preferences of that team to just fill the gaps. So in the case of the Rekognition, we would deploy all the Rekognition stuff a little bit first, and then we deployed the Nitric app, and then we wired up some permissions as the last step.
So it does mean a bit of Infrastructure as Code still, but we keep that to a minimum where we can.
Customizing and Extending Nitric
Customizing Nitric has always been possible, but it's been more difficult than we wanted it to be. The previous way that you would typically do it is either just build a new Pulumi program from scratch, which is way too much work, or alternatively, you could fork one of our existing backends for AWS or Google Cloud or something.
But then you're off the release train. So that makes it really hard, particularly if you had some sort of conflict later down the line. So we've created some new interfaces in Go. So step one in V1 has just to even make extending things using Go easier, since that's the language we use behind the scenes.
We will probably look at other languages in the near future, but just keeping our scope manageable. So in Go there's interfaces now, and you can implement a Go struct that implements the interface and you can embed one of our existing providers.
And what that lets you do is override one of the functions. If the way that we deploy topics isn't quite what you want, you can override just that behavior and leave all the other behavior untouched. And you can do that using our stuff as a dependency rather than forking it, if that makes sense.
So that's step one. We're adding an extension that would allow you to deploy any custom resource with Nitric in that same way. So you could embed one of our existing providers and then there'll be a method you can extend that'll allow you to add other custom resources. We think based on the teams we're working with that would have covered pretty much every team we've worked with to deploy the in most cases it's kind of five or less resource types that we don't natively support and we're looking at ways to make that extensible even in the SDKs as well. So you could extend the SDK with your version of it using ours as a dependency. And then you have these other resources in there with as little work as possible.
Anytime you find a thing you can't do in Nitric that you could do in, say, the AWS SDK, let us know on Discord or on GitHub as an issue. We'll probably add it pretty quickly if we see that it's genuinely useful. The escape hatch, if that doesn't work for you or the timeline's too tight is you can still include the AWS SDK and it'll work like normal if you're deploying to AWS and same for the other clouds. We're not doing any weirdness that would stop you from accessing these services like S3 or whatever, the same as you normally would.
Explore Nitric through the documentation.
