There are some people who have done things like this. I think the problem it runs into its just a very specific way to do the thing and any engineer with any experience is going to have their own set of preferences. Its going to end up feeling constraining.
Just looking at this list, personally i would instead go with shadcn, trpc, node test for node, drizzle, pulumi, next auth or clerk, etc.
The time saved with a plug and play stack imo will not be significant compared to the long term time spent building on and maintaining the stack, so a developer would be rational to pick and choose based their specific needs.
Also I think typically its more natural to build incrementally than all at once. Like are they certain they are going to need graphql? Maybe they could worry about analytics in a few months?
I think its super easy to become over-invested in your own preferences, and lose site of how complex and varied real world requirements are.
If you don't want to mess with setup etc check out https://get.display.land/ which will let you download and do whatever you want with the resulting models.
Flavio discusses what we mean when we say exactly once, breaks down the relationship between FLP, distributed consensus, and exactly once, and debunks the notion that we can't have exactly once (as commonly understood) because of FLP.
Scribe is a log aggregation system, it doesn't really do topics/streams or have a good durability/streaming performance story. Its mostly used for aggregating data into a log storage system like DL, or Kafka, or into HDFS.
> Could the service have committed more messages than it acknowledged?
Yes of course. It may have committed records but not had time to to ACK success.
> Or many less than I've sent?
Yes again. However it will NEVER ACK success for writes which it hasn't committed.
So the persistence story is pretty straightforward (I'll see if we can update docs if this is missing).
If you want to avoid duplication on the write side, you would have to retrieve the last log record-- with id x-- and start adding records again from id x+1.
Fencing + locking combine to provide efficient exclusive access and the fat client (for now) guarantees write ordering.
Rainbow's End by Vernor Vinge explores this idea and where it takes us in 20 years. The book is set in a pre-singularity world where technological progress in every field is tethered to advances in computing power, and new fields emerge and die in a few months. I don't think this is particularly implausible, eventually.
In any case the idea that you can get a job at an auto manufacturing plant and stay there for the rest of your life, get a fat retirement check etc without ever really having to worry about change, has clearly been smashed by globalization (via technology) in the last 30 years, and I think the same process is accelerating in other fields.
Of course not "[losing] the desire to learn" is exactly what the author is prescribing here, and I think as usual many people are just talking over one another.
Just looking at this list, personally i would instead go with shadcn, trpc, node test for node, drizzle, pulumi, next auth or clerk, etc.
The time saved with a plug and play stack imo will not be significant compared to the long term time spent building on and maintaining the stack, so a developer would be rational to pick and choose based their specific needs.
Also I think typically its more natural to build incrementally than all at once. Like are they certain they are going to need graphql? Maybe they could worry about analytics in a few months?
I think its super easy to become over-invested in your own preferences, and lose site of how complex and varied real world requirements are.