6 ms·

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

70 points by tholm 4y ago

dlhavema 4y ago
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
- jcusch 4y ago
  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 https://nitric.io/docs/reference/access-control would love your feedback.
andrew_ 4y ago
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.
- jcusch 4y ago
  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.
  - andrew_ 4y ago
    for me at least it's less about control and more about comprehension, and the hidden costs of a lack thereof
- mikercampbell 4y ago
  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.
  - dncornholio 4y ago
    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...
    - fwip 4y ago
      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.
- quickthrower2 4y ago
  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.
  - liotier 4y ago
    I feel lured towards Supabase's immediacy. Is it much more opaque to debug than an equivalent assembly of suitable components ?
- deleted 4y ago
  [deleted]
mikercampbell 4y ago
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!
- jcusch 4y ago
  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.
mhoad 4y ago
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
- jcusch 4y ago
  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 https://nitric.io/docs/language-support
matus_congrady 4y ago
I like the idea behind this project. While designing https://stacktape.com 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!
JimmieMcnulty 4y ago
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.
- speedgoose 4y ago
  It’s not unique, check Python. They are simply two very popular development environments so you will get more tools.
  - JimmieMcnulty 4y ago
    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.
    - speedgoose 4y ago
      You can write Python code for the browser, and it’s even good for some specific use cases. Dash or Gradio for example.
      - JimmieMcnulty 4y ago
        You can also write everything in binary directly.
    - yunohn 4y ago
      Which language do you use for web stuff?
      - 4y ago

70 points by tholm 4y ago

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

jcusch 4y ago
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 https://nitric.io/docs/reference/access-control would love your feedback.

andrew_ 4y ago

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.

jcusch 4y ago
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.
- andrew_ 4y ago
  for me at least it's less about control and more about comprehension, and the hidden costs of a lack thereof
mikercampbell 4y ago
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.
- dncornholio 4y ago
  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...
  - fwip 4y ago
    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.
quickthrower2 4y ago
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.
- liotier 4y ago
  I feel lured towards Supabase's immediacy. Is it much more opaque to debug than an equivalent assembly of suitable components ?
deleted 4y ago
[deleted]

mikercampbell 4y ago

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!

jcusch 4y ago
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.

mhoad 4y ago

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

jcusch 4y ago
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 https://nitric.io/docs/language-support

matus_congrady 4y ago

I like the idea behind this project. While designing https://stacktape.com 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!

JimmieMcnulty 4y ago

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.

speedgoose 4y ago
It’s not unique, check Python. They are simply two very popular development environments so you will get more tools.
- JimmieMcnulty 4y ago
  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.
  - speedgoose 4y ago
    You can write Python code for the browser, and it’s even good for some specific use cases. Dash or Gradio for example.
    - JimmieMcnulty 4y ago
      You can also write everything in binary directly.
  - yunohn 4y ago
    Which language do you use for web stuff?
    - 4y ago