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.
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.
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.
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.