| 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. |
Are. En developer is, flera developers are.
> Most ORMs, especially if they are of type active record, just misses that mark entirely
Miss. En ORM misses, flera ORMs miss. (Du fixade ju "are"!)
> Performance is generally bad, thus most ORMs has
Have. En ORM has, flera ORMs have.
Kom igen, så jävla svårt är det inte.