jcusch

Fair enough, I thought what I'd originally written for that section was too wordy, so I asked Claude to rewrite it. I'll go a bit lighter on the AI editing next time. Here's most of the original with the code examples omitted:

Watching Tuomas' initial talk about Linear's realtime sync, one of the most appealing aspects of their design was the reactive object graph they developed. They've essentially made it possible for frontend development to be done as if it's just operating on local state, reading/writing objects in an almost Active Record style.

The reason this is appealing is that when prototyping a new system, you typically need to write an API route or rpc operation for every new interaction your UI performs. The flow often looks like: - Think of the API operation you want to call - Implement that handler/controller/whatever based on your architecture/framework - Design the request/response objects and share them between the backend/frontend code - Potentially, write the database migration that will unlock this new feature

Jazz has the same benefits of the sync + observable object graph. Write a schema in the client code, run the Jazz sync server or use Jazz Cloud, then just work with what feel like plane js objects.

It looks like I was missing a www subdomain CNAME for the underlying github pages site. I think it's fixed now.

An ad for what? I'm not associated with any of the projects mentioned.

Thanks for the feedback, I like the idea of the multiplayer mode

Thanks, I'm glad you enjoyed it, I hope your friends have a good time too

This is great, I've been wanting to do something like this after finding an old series about making games in the terminal (https://www.youtube.com/watch?v=xW8skO7MFYw). I'll need to checkout bevy now.

Thanks! That's not harsh at all, it's exactly what Tim and I are looking for. It's honest detailed feedback with great reasoning. I appreciate you taking the time to provide so much detail.

The reason for the abstractions is that the behavior of equivalent services from different clouds is functionally the same, but offered through subtly different APIs. If you think the value of each cloud is how unique their object storage (S3, Cloud Storage, etc.) is, you’ve missed the point entirely - the value is being able to store and retrieve data. The same is true for all the services nitric abstracts.

Saying they’re expensive and impractical because they’re not unique is obviously wrong. They’re valuable because they’re easy to use, safe, scalable, etc. while requiring almost no maintenance from the user. Storing data or sending messages, etc. aren’t uniquely valuable components worth spending time on for most applications. They’re basic building blocks, so why not minimize the effort and time to use them as much as possible?

There are unique and valuable services offered by cloud providers, those aren’t what nitric is focused on. I’d rather spend my time dealing with those unique, valuable tasks instead of wasting it on the basics.

Common denominator implies you're restricted to some subset of the cloud's features. I'm curious what restriction you see, since nothing about nitric limits combining nitric code with existing cloud libraries or extending providers to change the cloud interactions behind the abstractions.

How you're describing iOS is similar to how nitric works. Developers indicate in code "I'm reading from this bucket", it's a request not an order, they're not actually configuring the permissions system. That request is collected into a graph of other requests (for resources, permissions, etc.) and passed via an API to a provider to fulfill.

If you want to change what "read" means you're free to do that in the provider without changing a single line of application code. But you also get the benefit on the Ops side of not needing to read the application code to try and figure out what permissions it needs to work, that part it generated so you can't miss anything.

If you want to output Terraform or config files or something else like you do today, to enable audits and keep it alongside the code, you can do that easily.

Nitric is a layer on top of Pulumi/Terraform. It also supports Python, Go and Dart. Other language support is also possible.

The Ops side of nitric (the providers) can be written in any language, but the out of the box providers are all built with Go, interacting with Pulumi or CDK for Terraform. You can just as easily write the deployment part of nitric with Terraform HCL to avoid the nasty issues you mentioned.

I'm curious what designs you use to avoid the issues. For example, if your code needs to access a resource (e.g. making a call to send an event to a cloudwatch event bus or SNS topic on AWS), how do you deal with things like:

- Consuming AWS client libraries (or APIs) in your application code

- Avoiding writing cloud specific mocks/etc. for testing that same code

- Avoiding env vars with resource names/ARN/etc. to use with that code, that then need to duplicated in the Terraform/other IaC without typos etc.

- The code not knowing whether it has the permissions needed to make those calls, so it's can't be guaranteed to be correct before deploying and testing in a live environment

- No longer needing that topic in future, but it lingers in the IaC because the two are unaware of each other

To me those are all examples of the application code "getting involved in the infrastructure it's running on", which I agree it has no business doing.

Nitric deals with these things by separating that code into another module that's sole responsibility is dealing with the cloud, exposed by a common interface for any cloud/environment.

What other designs/tools do you recommend?

The application is agnostic to that with nitric, more so than usual. It could be worth reading the docs on how it works, I don't think you got it.

I'm curious what you think wouldn't work. Nitric doesn't cover every use case, but in those cases you just continue to do what you would have already.

We really like CDKTF and Pulumi, they're two options nitric uses for deployments, but it's also a layer on top that helps decouple application code from the target cloud(s).

Software built with nitric ends up with considerably less cloud related code in the application. The bulk of it is split into the provider, enabling separation of concerns.

For example, instead of AWS client libraries, environment variables for ARNs, etc. existing in the code you instead have 1 line defining a resource using the SDK. That other code is separated into the provider, enabling testing in isolation and separation.

That's essentially the idea with nitric, you ask for cloud resources in an abstracted request. How that request is fulfilled is determined by the provider used. What "read" access in nitric means can be up to the platform engineers.

That's actually something nitric helps with, it provides an API for deployments, separating it from application code. Those other teams like devops/sre/etc. are free to customize that process how they see fit. They can enforce naming standards, tagging, sizing, etc. all through automation.

I can definitely see your point, but we don't think cloud development has hit up agaist the limits of inherent complexity. It's still needlessly complex in many cases. Projects using Nitric typically write the bulk of the application using the abstractions and go direct for anything unsupported or specialized.

The point of Nitric isn't to avoid knowing how your infrastucture works, it's just to speed up development and improve cohesion.

Thanks Junto, for function deployment we use matched files as the entrypoint for containers rather than exported functions or something similar. This lets you group many message consumers, route handlers, etc. together in a single container.

Thanks, that's the way we see it too. We think people mistake "separate files" for "separation of concerns", but many applications have inherent coupling to their infrastructure.

It's a valid point, Nitric isn't a good fit in some cases. We've been working on improvements to the underlying provider implementation to allow for easier extension for non-standard cases. Nitric is a gRPC API under the hood, so alternate implementations can be built to satisfy the APIs when customization is needed.

There is a collection of new tools trying to address this exact problem such as Nitric, Winglang and Ampt for example. (disclaimer, I work on Nitric)

There are probably a few reasons it might seem like web apps are faster. A few that come to mind are perceived performance https://developer.mozilla.org/en-US/docs/Learn/Performance/P... and optimization/offloading work to servers (caching, server-side rendering, APIs etc.).

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.

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

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.

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

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.

We've been using Pulumi in the nitric framework https://github.com/nitrictech/nitric for a while now. Originally, we used native solutions like CloudFormation, then looked at options like Terraform. Pulumi ended up being our favorite by far. The docs are awesome and using the features of a language + editor you're already familiar with are pretty appealing. Autocomplete, typesafety, automated testing, etc. make it really productive.