Adam Berger

Your backend should probably be a state machine! docs.statebacked.dev/blog/2023/09/1…

@erikras Mutation observer for recording changes: github.com/pluginsdotdev/… Corresponding implementation for replaying changes: github.com/pluginsdotdev/… Never fully released pluginsdotdev but everything in the repo should be in working order.

I've got a Frontend (Interview?) Question for ya! I want to record, with timestamps, all the changes to the contents of a <div> to some format that I can then play back those changes whenever I want in another <div>.

State Backed is a great AI orchestrator (we've been building a *ton* of AI-focused apps with it ourselves). Now, it's even better: we're increasing the timeout for each state machine step to 90 seconds.

@BenjaminDEKR Programming and management are consolidating... We're all managing the fragile emotional state of our persnickety robot helpers now. It's been working well for me for the past few days. We'll see what next week brings...

@abrgrBuilds It's disturbing yet amazing if this works 😆😆

GPT-4 has become so @#$%@ lazy, it won't even output more than a handful of code lines now: Fix. This.

Yup. Simple libraries for the clojure-capable and managed services for the rest. Tough to turn some of these ideas into usable in-language abstractions in other languages but a managed service could make it accessible to all. Even XState looks just different enough from traditional js/TS that people are scared of it

@sayestheorem @dustingetz @36Rleonoel Oh nice. Love electric clojure but haven't seen missionary. Thanks for the pointer!

@sayestheorem Will do. I kind of want to build a business that just turns great clojure libs into services for the rest of the industry. Lots of good stuff there.

@sayestheorem Definitely. Check out github.com/wilkerlucio/pa… for the best non-dataflow-oriented version of this I've seen

@abarrallen @ankrgyl These are my favorite problems. Love talking about this stuff if you're ever down a chat.

@ankrgyl Chat with @abrgrBuilds

It turns out complex, stateful software is hard to build 😬

It was great chatting with @leeatchison on the @software_daily podcast about State Backed and the backend state machine architecture we're so excited about. Thanks so much for having me! 📻 Listen to our conversation here: softwareengineeringdaily.com/2023/11/16/bui…

@adymitruk So refreshing to hear this perspective. I always hope someone else out there believes that there's intrinsic (and long term business) value in doing things right and chasing curiosity to deeper understanding but... man! it's tough to find sometimes.

"Pragmatism" is nearly always "I'm too lazy to learn to do it in a better way." Criticizing better methods is an attempt to ensure your cheese isn't moved, you fat, lazy mouse 🐁🧀. You can see this everyday in "#eventsourcing is hard" posts. Others: Not using keyboard shortcuts during development Not designing before starting and just "agiling" through the project Clunking around in heavy electron or jvm -based IDEs instead of nvim Needing a "clean git history" instead of knowing proper rc branch management Shipping unfinished code inactivated behind a feature toggle instead of managing concurrency in development and dealing with merge conflicts Not using Linux because "it just works" marketing BS is taken at face value on inferior platforms Not understanding css and html fundamentals and relying on a framework, wp, etc Not learning bash and leaning on ci/cd tooling The thirst for money outweighs curiosity and rigor in this industry. Too bad. Good for those that are doing the work though.

@jacobmparis Cohesion & coupling are 2 sides of the same coin: modeling semantic reality. False similarity forces the introduction of artificial special cases & prevents independent evolution. False difference forces duplication & reimplementation. The job is to model reality faithfully.

Everyone loves to talk about separation of (unrelated) concerns But MUCH more important than that is colocation of related concerns Keeping related things together helps more than ANY attempt to split things apart

@AdamRackis 👀

I've thought about "application skew" more in the last day than ever Folks who version internal endpoints so clients hit the version they were deployed against ... how tf do you manage that in practice? Does *every* change to endpoint logic / payload get a new version? 1/

2 days to build, test, and deploy a major new feature affecting DB, untrusted code-running, and API layers. Also 2 days: upgrading dependencies in a 1 year old rust library (ts-bindgen). Pretty convinced @unisonweb function-level versioning is the right way out of this mess.

It's so nice to see a reply aiming at figuring out the truth instead of just being needlessly mean... thank you! I am excited to try to figure out the truth too. My main point is that changes in APIs are easy to identify and determine if they're backwards compatible or not. With server actions, the only reasonable way to identify the code to run is based on where the component is in the hierarchy for a route. So any change to that (I think) will cause backwards incompatibility. As you say, renamings are probably breaking, which is surprising. Worse, changes in where a component is rendered would also break (I think). Other small naming changes, adding or removing params, etc may cause incompatibility too depending on the wire protocol. The whole problem is that with an implicit interface, it's very hard to tell what is a breaking change. With explicit interfaces, it's easy.

@abrgrBuilds @AdamRackis I'm just trying to understand your point better. Do you mean that changes in API interfaces are very rare and problematic, but using server components, every time a frontend developer decides to rename a component it would basically mean API changed? I wonder how this works, too.

Server actions 🔥

@anthonysheww @AdamRackis @thdxr @t3dotgg Thank you. I think it's great to experiment with this stuff. We need that to drive devex & user experience forward. I have obvious worries that it's hard for an engineer to see that this only works with a particular type of infra but that's not your or vercel's problem to fix.

@AdamRackis @abrgrBuilds @thdxr @t3dotgg For what it's worth, I was (and am) just trying to provide some info. Happy to see builders building! I had what I thought was a useful link and some context on how that thing is working outstanding at massive scale so I wanted to help if I could.

ok time’s up here’s the deal with server actions if you’re excited about them you’re wrong if you’re mad about them you’re wrong let’s do this unfortunately @t3dotgg was right - the key thing the haters are misunderstanding is that NextJS is a backend framework in your head think about it like express or any other http server - you wouldn’t be surprised if you could return html and do a database call right next to it except it’s a better express because it lets you build all kinds of complex interactive clients via React fundamentally there’s nothing wrong with this - you’ve been doing it forever in every other language, just never with this kind of focus on the frontend bits but sorry nextjs fans you’re wrong too for dismissing people’s worries about “separation of concerns” the only real job you have as a programmer is encapsulation - figuring out what details to hide and what to expose and because this is your one job, of course you’re all terrible at it forcing a hand rolled API layer at least guaranteed some level of thought and blast zone for refactoring with that gone, doing the wrong thing just got a lot easier it’s why in past generations, the frameworks had some encapsulation ideas built in (to varying degrees of being useful) all the acronyms, MVC, MVVM, DDD yes can be overkill but the root ideas exist for a reason asp.net had these ideas baked in, elixir’s phoenix has a tutorial about bounded contexts right at the beginning, PHP only got lambos once Laravel nudged you into a stricter structure are they perfect? no. but they’re a hell of a lot better than whatever you’re about to come up with given that NextJS has no philosophy on this problem at all so a lot of you are about to repeat all the same mistakes we’ve seen a generation ago if you don’t slow down

This isn't about the DB. This is about breaking interface changes between client and server. It is not a risk with an explicit API where backwards and forwards incompatible changes are easy to identify. Deploy notifications break users who just wrote a long post and have to refresh. They also misunderstand distributed systems where some servers are upgraded and others are not (or where deploys happen all the time).

@abrgrBuilds The scenario you described is a risk with many web apps. One solution is deploy notifications. Another is versioning APIs. Another is not making breaking DB changes. Lots of options.

Locality of Behavior (LOB) Principle: The behaviour of a unit of code should be as obvious as possible by looking only at that unit of code. Locality enables a programmer to understand the source by looking at only a small portion of it. Note: DRY and Separation of Concerns fight against LOB. So find a balance. More: htmx.org/essays/localit…

@anthonysheww @AdamRackis @thdxr @t3dotgg I'm just so confused. You think it's a good thing that we added a key feature to an open source library that can only reasonably run on your specific type of infra?? You use interfaces (typescript) everywhere BUT between two different machines? There's a simpler solution here.

@abrgrBuilds @AdamRackis @thdxr @t3dotgg It’s already been done, as described in the article. 😁 We’ve gotten resoundingly good, “Reddit-style 11/10, would recommend to a friend” feedback on it which has been great to see. Stoked for the team that built it!

@AdamRackis @anthonysheww @thdxr @t3dotgg Huh??? My product doesn't compete with Vercel at all. We're firmly not in the space of serving frontends. I enjoy the needles ad hominem but would actually love to understand how you keep your code working for real users using the hot new thing. What's the plan?

@abrgrBuilds @anthonysheww @thdxr @t3dotgg Ohhhhh you’re building something that competes with Vercel’s infra I get it now lmaooooo 😅 I knew something about this exchange smelled fishy, and it wasn’t just the blue check

@thdxr If only computer scientists had invented a solution to allow two components to evolve independently. Some sort of interface for programming between applications. Maybe we call it an IPA?

"NextJS is easy to run anywhere" this is not true - i'm getting tired of people continuing to claim this it dismisses the tedious work that the OpenNext community is doing to actually make feasible to run it correctly outside of Vercel here is yet another example: with server actions you no longer handwrite API endpoints - which means you don't have the ability to explicitly control versioning from Vercel's point of view this isn't a big deal because on their infra, every deployed version of your app can stick around forever and requests from old clients get routed to the right version: vercel.com/blog/version-s… this is only possible because of serverless functions which scale to zero - they solved this problem via a specific infrastructure solution yet every demo they do of "look how easy nextjs is to self-host" is always some simplified docker deployment that glosses over details like this this is just one of an infinite number of examples seriously getting tired of wading through the spin