Htmx Is the Future

You are comparing apples with oranges. I'm talking about organization, you about individual developers.

I can have fullstack that is better than a specialist. Specialist only means that they have specialized in one part of the architecture, that doesn't necessarily mean that they solve problems particular well, that depends on the skill of the developer.

And the point is that even if they do have more skill within that domain, total overall domain can still suffer. Many SPAs suffer from this, each part can be well engineered but the user experience is still crap.

If your developers is lacking in skill, then you should definitely not split them up into multiple teams. But again I'm talking about organization in general, that splitting teams has a devastating effect on organization output. Difference in culture will make it harder to move between teams, thus the organization will have much more difficult time planning resources effectively.

BFF is all about reflecting the need of the client, but the argument was the a generalized API is better because of re-usability. The reason why you split into multiple BFFs is because the workflow isn't the same, it differs a lot between a web client and a typical app. If the workflow is the same you don't split, that is why I wrote BFF per client type, a type that has specific workflow (need & requirement).

> This is a case by case basis on the product.

Of course, it was an example.

> That sounds terrible, and very OO. I'd rather generate another client for my openapi documented API, in whatever language is most appropriate for that client

I'm talking about the server here, not the client.

> That's a stretch, if I need a form, I likely need the same data if I'm on iOS, Android, native, or web. Again it's about execution of a workflow.

But the authentication and redirects will probably be different, so you can reuse a service (class) for updating the model, but have different controllers (endpoints).

> Yes, those API are not being designed correctly

Every generalized API will have that problem in various degrees, thus BFF.

> Yet ORMs are tools of generalists.

Oh, you think a fullstack is generalist and thus doesn't know SQL. Why do you believe that?

> That depends a lot on how the orm is being used.

Most ORMs, especially if they are of type active record, just misses that mark entirely when it comes to relationship based data. Just the idea that one class maps to a table is wrong on so many levels (data mappers are better at this).

ORM entities will eventually infect every part of you system, thus there will be view code that have entities with a save method on, thus the model will be changed almost from everywhere, impossible to track and refactor.

Performance is generally bad, thus most ORMs has an opaque caching layer that will come back and bite you.

And typically is that you need to adapt your database schema to what the ORM manage to handle.

> We literally write clients for APIs we don't own all the time,

The topic here is APIs you control yourself within the team/organization. External APIs, either that you consume or you need to expose is different topic, they need to be designed (more). The point is internal APIs can be treated differently than external ones, no need to follow the holy grail of REST for your internal APIs. Waste of time.

But even with external APIs that you need to expose they can be subdivided into different BFFs, no need to squeeze them into one, this has the benefit that you can spend less time on overall design of the API, because the API is smaller (fewer endpoints).

> That's what a client is...

I'm specially talking about server architecture here, the client uses the adapter.

> then wait wait wait wait even more for completely inscrutable reasons later on. (e.g. amazing how long you have to wait for Windows to delete the files in your node_modules directory)

As far as I know, windows explorer has been extremely slow for this kind of operation for ages. It's not even explainable by requiring a file list before starting the operation, I have no idea what it is about Windows explorer, it's just broken for such use cases.

Just recently, I had to look up how to write a robocopy script because simply copying a 60GB folder with many files from a local network drive was unbelievably slow (not to mention resuming failed operations). The purpose was exactly what I wrote: copy a folder in Windows explorer.

What does this have to do with React or JavaScript?

This is a pretty popular approach, and I use it sometimes, but "agree on an API spec for the project" does gloss over how challenging and time consuming this can be. How many people here have ever gotten their API wrong? (raises hand). There's still a lot of ongoing coordination and communication.

Companies do this, but it is really hard to support. I prefer teams that own an entire vertical slice. Then they know their API and more importantly, The WHY? their API does what/how it does. A BE team can never know the entire context without exposure to the end use IME, and there is far less ownership. YMMV and it will ultimately come down to how your company is organized.

Maybe django is less so a dependency bloat than most other frameworks. Just called out the common consequences of getting more. You get more.

Npm projects are likely the most bloated by far, but also are java based projects, just look at Spring.

Calling out a python framework or some Go lean solution being the exception of the rule is fair enough, my point is developers expect everything and have little to do but rapid painless developement

I would love to hear about those asked to migrate their python 2.7 django ecommerce app to python3 since v2 is totally dead and unmaintained posing serious security risks. But sure if we forgo these things, and don't ever need to touch the code again, some frameworks have no downside. Makes a certain kind of developers finally be right.