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

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.