Those who chase Easiness over Simplicity will end up creating something that is neither Easy nor Simple!

Every time somebody destructures, the context of a given value is reduced, and therefore, its meaning. Objects give context, and I think they are worth keeping. This is one of those habits the React ecosystem pushed too much, a net negative in almost every situation.

⚠️ Pure chasing the ultimate architecture design ⚠️ I can't entirely agree with you in terms of returning anything other than the ID and Etag; Most of the time, the client will already have the information, so you do not need to return anything or do optimistic UI updates. You are better off respecting CQRS (be pragmatist), so you do not fight Physics/Speed of Light but take advantage of it. Also, most clients should be doing Task-Based UI instead of CRUD-Based UI.

The best marketing I found is to show the value instead of talking about the value. And yes, it has been almost half a decade since we started leveraging @EventModeling to stop guessing the future and applying Event Sourcing to stop guessing the past!

I can assure you that this is on point! I lost priceless time getting distracted by DDD. I greatly respect the community, and I owe a lot to some of them. But it was a massive misdirection. The focus should be on the data, information, and workflows. Done! If you are talking about "Aggregates," you have already left out too many non-technical people who chase such trivial technical aspects and deviate from the conversation about the bike-shedding technical topic that does not matter.

By now, we know that most things are 80% cacheable, and invalidating or recreating the entire application is suboptimal! Micro-frontends don't come for free, but that is the precise challenge that should be given now in the web frontend world, especially after HTTP2 became GA. I am happy to see something happening. I am grateful that you took ownership of the situation and pushed through despite the pushback! Keep going, Zack! I sincerely appreciate your work from far away! You bring value to this world by solving costly problems! You are a legit example of a Staff+ Engineer.

Would you still be the same if it was Alan K. OOP? Which is closer to Erlang than Class-Based from Java? The frustration is that I can be the "bUt acTuaLLy" person by saying that, but I am not even sure if I should stop or if it is worth continuing to remind the industry that Messaging should be the focus, which was his point. Granted, my background is in distributed computing. I see the value in that context.

It is not wrong we would remove a lot of complexity from clients if we follow REST (actually REST, not the Rails RESTful that took over the industry) Since the protocol would drive a lot of trivial things but hard that we do in clients today. It took me forever to understand what I was supposed to be doing. I still don't do it properly, but I can no longer dismiss its value. It is honestly much more straightforward.

@nats_io right? If so, welcome to the club! You were missing out! Spread the FOMO!

I have been working on event-driven systems for about half a decade! I would love to learn from you about the topic and maybe share some valuable experience with you!

Until we need to colspan rowspan 🥹🥹🥹🥹🥹

Honestly, I am as dumb a writer as I get. I think, read, write, listen to pictures, and... I own that, and I do not hide it. So I take an afternoon beers video call over this silly method of communication. I believe that only a good thing will come out of that!

Tesla or Req. I couldn't care less which one we chose. I do not want to waste a second on such a trivial matter. To begin with, I became the maintainer, trying to support Tymon as much as possible when he needed to delegate. That is all. I care about the ecosystem and am not paid to maintain the packages. Until today, I believe Req middleware is more complicated than needed. Look at how many types of Steps github.com/wojtekmach/req/bl… Internals already have product biases github.com/wojtekmach/req/bl… This is a major red-flag, that is the problematic situation of wanting to be "battery-included" instead of optimizing for simplicity and easy to use at the app-level. So on and so on. Most people do not understand that the only fundamental problem in Tesla is the macros github.com/elixir-tesla/tesl…. That is all. I will own being wrong if anyone points me to a fundamental flaw in the architecture or code or any significant improvement other than a predefined configuration and loses the ability to have multiple clients in Req. Tesla internal is much simpler if we remove everything related to the macros. Lastly, statistics show that Tesla has brought food to the ecosystem, and until today, it still does. Give credit where credit is due (and again, Tymon is the creator and the one who takes the credit, not me). I am unsure about starting over, retesting everything, and continuing the guinea pig toying with ideas until v1.

Huh? All I care about is that we play like a soccer team and win the tournament. I could care less who the team's Messi is, Dave. Elixir has not already been consolidated in the eyes of CTOs. That is just not true. There are so many trivial things we haven't aligned on that are so silly that CTOs are scared that we haven't. All I am saying is, could we work as a team and put individualism aside for a moment?

That is a good question. I think you need both separate. Otherwise, you need to split the information somehow eventually. It is not accidental that they are two different headers. Especially at the platform level, you want to avoid domain-specific data logic. ID: Identity of the Resource. Etag: Version of the Resource. Query Side: Etag is about allowing clients to pass enough information to the server to understand the state of the resource requested, potentially optimize caching, avoid extra computation, etc. Command Side: Etag would enable the server to understand if the action performed was based on stale data. Based on the tolerance for such stale data, the server could decide to reject the command.

Likewise, I said multiple times I usually use Req for greenfield projects above Tesla! Simplify this because I want the battery-included aspect, it is extremely useful for most cases out there! Especially during active development and experimentation.

Also, since you are a Dota pleb, that explains high IQ! You are not a 2K pleb, are you? 🫣 Otherwise, I will revoke you the smart license!

These are the books pretty much! The fact that you managed to avoid it and discovered Scott and F# put you ahead of 80% of the industry 😎

What do you mean by the interceptor approach? I am trying to understand the situation because that is precisely what Tesla is doing today. If you look inside Tesla, you will find pre- and post-steps (like the steps), but it was discouraged to some extent by a single API. As I tried to communicate and collaborate, Req opting into 3 lists of middleware where the order matters among them and where you sometimes need steps that expand across Pre, Post, and Error ... is quite complex. Unlike a simple function that takes the request and the next step to run, you decide to continue the pipeline whenever it makes sense to you and process the response however you please. It's even simpler than Plug EMO. There is no need to Halt or coordinate the order of steps between 3 configuration lists.

I am OK with that, and I would support it. Except that stats show that it is not even close to be the case and real production environments that pay the bills still running on Tesla. So we better off make sure it is as good as it gets in the meantime.

I would 100000% this argument if you point me to a fundamental flaw in Tesla that couldn’t be fixed or drastic architecture change that granted such splitting

I hear you, this is where I can’t speak much, I don’t use any of those things unless I am working on a shared HTTP SDK since I am defining the behavior spec as the DI instead of mocking the http layer. Being said, architecturally, all possible with very little effort

Given that Message Validation != Domain Validation, I agree. Message validation should happen as much as possible for the client constructing the message. Do not send invalid Messages ever.

I asked a long time ago for permission to discourage it: github.com/elixir-tesla/tesl…. But honestly, I am focusing on fixing bugs and whatnot across the ecosystem. I am just one person trying to support a massive chunk of it. I have been trying to get to a point where all of that could be removed and replaced by a simple data structure, Tesla.Env + a Middleware Pipeline. As mentioned, Tesla is closer to Plug than Req architecturally speaking: github.com/elixir-tesla/tesl…. I brought it up and tried to hint at the focus on these standard Pipes and Filters' middleware patterns, and maybe there was some common ground around the architectural intent.

Right there, at -1 page even

80% of the programmers are incapable of understand the book, fundamentally, and only repeat why they heard. The rest 20% are too busy to waste time. Clean Code, meh, still better than the alternative offered.

It sounds like I am missing out! I wonder how much code could get written in the event-driven and event-sourcing stuff I do where I have full specs of the messages and information design ... Yet another weekend task to do 😭

Hot take, #MyElixirStatus It would be best to create even more Structs than we think. Structs have names; names give identity; please give identity to data!

What is that supposed to mean?

I was waiting! Sadge

I stopped completely around 2020, after ~5.5K hours; except that you need to add at least 15K more from Dota 1 to that 😅 Today I am just a Admiralbulldog YouTube frog 🐸

"This is the sad, fact right most people are bad at programming. Most people who are good at programming are really busy. They're not usually the people giving you advice about how to program." @Jonathan_Blow