Show HN: Nitric – Node.js framework for building portable cloud apps | Hacker News Reader

Show HN: Nitric – Node.js framework for building portable cloud apps

github.com

70 pointstholm33 comments

I like the idea behind this project.

While designing https://stacktape.com, we were discussing a similar approach. But we eventually decided to go with a lower-level, more standard one. If I remember correctly, most potential users said something along these lines:

1. Too much abstraction - while developing a real-world application, you are very likely to come across a use-cases that either can't be solved using this kind of high-level abstraction, or would be easier to solve without the aforementioned abstraction. It's also very hard to tell, if you will or will not run into such a use-case. This also makes planning very hard, and in some cases almost impossible. Usually it's something like "This will take 8-12 hours if I won't run into a not-supported use-case and possibly weeks if I do".

2. Too much magic - Developers usually understand how tools like Serverless framework transform the serverless.yaml into a Cloudformation template and understand how things work behind the scenes. Therefore they can make assumptions and workarounds more easily. I fear this would be way harder to do with "high-level abstractions tools" such as nitric.

3. Lowest common denominator problem - while being able to migrate my workloads between clouds seems very promising, it also means I can only use services and features supported by all of the clouds. So you either give a lot of "goodies" provided by your cloud platform, or (in most cases) you give up the portability.

That being said, I don't worry about individual developer adoption. What I do fear is that it will be very hard to convince a CTO / Engineering manager / Techlead to choose such a tool for their team, making monetization hard.

I hope I'm wrong and these "high level, infrastructure-from-code" tools will find their users.

Wish you all the luck!

An alternative that others might want to take a look at in this space is Dapr from Microsoft which is language neutral and a CNCF project. Website is dapr.io

Dapr is fantastic if you're using Kubernetes, but we've found people having trouble with the learning curve. Also, Nitric's main SDK right now is for Node.js, but the underlying implementation is in Go and uses gRPC like Dapr. We have other SDKs in the works for Go, Python, Kotlin and C#. There is a bit more detail in the docs https://nitric.io/docs/language-support

What about permissions? A hard part about developing on AWS was grtting the right permsission set that gave enough access, but nothing more. Im sure the other cloud providers have similar systems to IAM

You're not wrong, it's one of the most difficult parts and definitely something we're trying to solve with Nitric. Here is the overview doc about how we handle this problem https://nitric.io/docs/reference/access-control would love your feedback.

I've been looking for something just like this! Having fallen in love with encore.dev, I considered building a Typescript duplicate.

This is such a great project!

So glad you like it! If you try it out we'd love your feedback and would be happy to help if you run into any challenges.

My one and only beef with frameworks like this is that one ends up learning the idioms of the framework to deploy as a first class citizen, then when faced with deployment issues, having to learn the basics of the target cloud platform as a second class citizen. I get why this is appealing, much in the way jQuery was appealing over raw DOM back in the day. However, I much prefer abstractions that are closer to the bare metal which still provide convenience and good DX such as CDK or Terraform.

Hey Andrew, thanks for checking it out. I think that the tradeoff between control and convenience is super important. We've tried to focus on convenience for Nitric, but also make the plugins and APIs transparent so you can regain that control when you need it. That said, it's hard to balance. Have you checked out Pulumi? They're another great option we like if you want control like CDK or Terraform.

for me at least it's less about control and more about comprehension, and the hidden costs of a lack thereof

Yeah, there is a cognitive cost to frameworks like this. Ruby on Rails is the same, where there are conventions to learn and pitfalls to avoid, but like DHH said "look what I don't have to do".

I've worked at companies that have had bare metal DX and they used it to stab themselves. I mean, anyone can be contrarian, and that's not what I'm trying to do here, but there is value in "idk what the queue is or how it's implemented, but I know how to call it". If you're not using an abstraction layer for everyday engineers (on a project that has 20+ engineers on it), then that means either your building one yourself, or you're forcing your teammates to engage with DevOps themselves.

If I were to start a company from scratch, I'd use something like encore.dev, because even though there's a framework to learn, it's a DevOps-less, or less-DevOps approach to building software fast without boilerplate.

And I'm not sure what it is about express.js, but everyone seems to have their own way of doing it. It's cool to see paradigms solidify, like tRPC and Nest.js, and now this.

I don't see any value in developers not knowing anything about the inner workings of their app. None. The only value that it gives is that they can bath in ignorance.

Where is the value that when your devs push something that breaks, you need to rely on external people to un-break it?

It's a business model, it only gives value to the company that build the framework. It only gives debt to the people using it...

I'll take a devil's advocate bite and offer: Onboarding. It's easier to get junior and mid-level devs started on a repo/project if they don't have to understand 100% of the full, entire stack. Maybe I'll bathe the babies in early ignorance to hook them and help them grow.

That said, if they stay in baby form and never grow...

You can give a baby a smaller piece of pie instead of some completely different pie that's baby friendly.

Personally I am for bathing babies in pie, so :thumbsup:

As always, it's a matter of where you draw the line around what counts as part of your app, and what you count as external dependencies. The level of abstraction that is safe to use changes by use case.

It wasn't all that long ago that it would be unusual for a programmer to not understand assembly code - and before that, to have an understanding of how transistors/vacuum tubes are assembled to make complex circuits.

But of course, nowadays for web development everybody trusts the CPU architecture to operate efficiently, the OS to do reasonable things, TCP/IP to remain reliable, browsers to support Javascript, etc etc. In the last few years we've even seen some stabilization even around the historically churny realm of javascript UI libraries - most developers don't even need to know how React works under the hood, let alone how V8 runs.

The reasonable level of abstraction has grown immensely, and the number of web developers who deeply understand the true stack is probably fewer than 10. For most use cases, a service that abstracts over the various cloud provider options is perfectly fine - and when its not, that's generally a "good problem" to have (because it means your app is having scale issues).

All business models are meant to give value to the business. The successful ones also give value to the customers.

I relate. I have had the 3 citizen problem of Azure + Terraform + Kubernetes on a project I worked on and yeah figuring out issues requires navigating all that.

The 2/3 citizen problem is everywhere in tech. Look out for it and avoid if you can. It is probably an innovation token. That is why I am less enthusiastic about things like Supabase (picking on the one I remember) and it’s ilk over just Postgres.

Maybe I am waffling on the basic point of: boring is good, at least as a default to be convinced from.

I feel lured towards Supabase's immediacy. Is it much more opaque to debug than an equivalent assembly of suitable components ?

I would argue that JS is not just a language, it's a mindset, and that mindset is, "I just want to write javascript, for the love of god don't make me learn more than I absolutely have to."

It's... unique, in the software dev world, I think. Node.js is not the right tool for this job, but god bless the folks who insist on using it here anyway.

It’s not unique, check Python.

They are simply two very popular development environments so you will get more tools.

Python doesn't have anything remotely close to this problem, as you can't (reasonably) write Python for the browser.

JavaScript has this problem because it's actually a somewhat attainable goal.

The main problem is that once you run into a problem not explicitly solved for by whatever Node.js framework that's holding your hand, you're in deep trouble, very quickly, unless you have a more "classical" software development background.

You can write Python code for the browser, and it’s even good for some specific use cases. Dash or Gradio for example.

You can also write everything in binary directly.

Which language do you use for web stuff?

JavaScript, which is why "you must hate JavaScript" is a confusing thing to say to me...

Well, the goal of software is to solve a problem or enable a usecase. It’s not to “write code”.

I am experienced in tons of software programming paradigms and languages, but I couldn’t care less about the details if it doesn’t enable me to output something useful.

So how many projects do you build in Brainfuck?

After all, you don’t care about the details, as long as the language enables you to output something useful, and Brainfuck is Turing complete, so that checks your only box, yeah?

…or maybe using the wrong tools is a terrible idea, and you really ought to care more about the details.

Huh? You have misunderstood my point completely.

I meant easy to use languages are better than hard to use but “technically better” languages. Brainfuck would be the last language to use for either scenario though.

JavaScript is decidedly not "easy to use" in any sense for building out and managing infrastructure.

There are AWS/GCP/Azure APIs where you can fully manage your infra if you'd like via JavaScript. Nobody does this, however, for a reason. Lots of reasons, actually.

That's what this submission is, a way to solve a problem in a much harder (and limiting) way than is necessary, given the other available tools that can be used to solve this problem.

You'd be much better off learning something like Terraform to solve the problems being addressed here. Not everything has to be solved in JavaScript, and that's a uniquely "JavaScript" community solution, given how seemingly attainable it is to newer coders (which a lot of JS programmers are).

With JavaScript you just have a lot of haters and lovers. Not many I don't mind ones. You clearly fall on the hater category. That's not an issue, but the way you represent it is not true.

Because I don't think JavaScript is useful for literally everything, I am therefore a hater? I don't think so.

Thanks for checking it out. We've definitely gone with a convienience first approach for the framework but realize that's not suited to every scenario. By the way, the underlying tech is written in Go and we're adding support for other languages if Node.js is a big concern https://nitric.io/docs/language-support

Typescript has a better type checker/type system over HCL (and IDE ergonomics), and it works pretty damn well in IaC [0].

[0]: https://www.terraform.io/cdktf

disclaimer: I write both HCL and Typescript, and go, (& many more) for a living...

Reply on news.ycombinator.com