Fine, I'll talk about frontend versus backend

Yeah, separating out the front end into JS was a mistake. MPAs are better, made a little smoother with HTMX.

Thing I have seen being done client side just because it would be easier for us to do it instead of back end makes me want to pull my hair out. The level of ignorance you have to have to think it makes any sense if enormous. I still like to think they are just a bunch of lazy fucks instead of having that level of incompetence, and I'm not talking about having to chain 15 or so requests. That would be something to go over, but getting 200 for what should be 401 response is just to much, let alone everything else.

Between a better UX and a better DX guess who’s gonna always win in the end? That’s why the internet sucks

Coming from a Ruby fullstack environment, usually with Rails, PostgreSQL and Bootstrap, I really like what I've experienced with Next.js so far. Probably my favorite framework, currently

The frontend needs the backend to provide the data for the best user experience.

Why cant the API's primary objective be to serve the one who's using the data for this purpose?

Frontend and Backend NEED to work together.

Remix React Server Components for the win!

One question in backend suppose I am using node and MongoDb

I have to do aggregation on a collection

after aggregation I am getting data

[
{
AllStatus:
{
active:4,
suspended:1

}
}
]
But client side needed like this
allStatus=
{
active:4,
suspended:1
}

do I have to do the Javascript calculation in the backed after getting the data from aggregation to get the desire output that client is seeking?

Is there will be any performance issue on backend ?

When issue come, backend dev codes less but have more reponsibility, frontend dev codes like animals but has less responsibility. Backend dev tend to do their way and assume that it is no pain to change from frontend.

So are you advocating for graphql?

What happens when u need a mobile app. Rewrite the backend ?

If the rule is "Don't couple API to UI Element", fine. I'll make just one endpoint to fetch all necessary data for my front end then call it only once on the first useEffect().

eat more, you are skinny

Backend vs Frontend? 😂

Nah bro

Backend + Frontend = 💪

I think this is why graphql servers that are being worked on by frontend devs are SO powerful, it becomes the "frontends-backend" and really bridges this divide that we have.

And you can shove business logic and return view models to the clients to make clients dramatically less complex.

The counter argument is "graphql then becomes your monolithl", and I think that's OK (provided you have services broken up and separate from the graphql server.

Brilliant breakdown!

The cohesion that graphql brings to the FE and BE allows specialists to thrive more than ever compared to REST. It would be nice if TRPC was available for other languages besides JS, but it’s not (at least not by default without significant customization on the server side), and not very BE dev wants to code in JS/TS.

amen

I had negative experience in 100% cases when BE tried to follow FE structures. It falls apart mostly at every change when you need to change the UI, or update data structure. When you rise to 2 clients, that happens often by introducing mobile app, your BE api complexity exponentially growth, making if serve different data composition requirements. access rules, or features. And when you have micro-services on BE it spreads allover them, making it unmaintainable. Just following the REST even for one client - it’s a reasonable tradeoff, making it focused on the domain area, not representation. Also it resolves HUGE problems of caching such a combined responses, when some of “hydrated” entities got outdated.
And I’m saying it as a frontend dev. Meanwhile I agree that Next.js is really convenient as a BFF layer, for data aggregation/transformation, from many other sources, to feed FE with what it really needs. But we don’d consider Next js server fetching as a dedicated BE, right?

It's a no-brainer that APIs should help to optimize the UI. We are all here to serve others.

I have many times created more than one variant to get "the same" information, e.g. a full variant and a lite variant to reduce the payload for optimal speed. As I said, a no-brainer.

Personally I don't even want to work in a place where there are two groups of developers - front- and backend. It often leads to scar tissue on the edge between them. Development should happen by feature, and if you want more than one person to work on it, let them work on writing automated tests (and train engineers to be able to write both code and tests). Or add people once the design work is done and it's all about finishing off things. The split between front- and backend engineers is a dysfunctional one.

Gelud yuk geluddddddddd wkwkwkwk

On my job we're doing all stuff on BE, totally ok with that

I think this is more of having so many company customers using your API data structure.. So if you want the specific API endpoint to have the response data... they will not yet do it.. Why? Others Client Customer Companies are using this for this purpose... Especially you have a contract for $1millions of paychecks...

Otherwise if something breaks and it is too complex...

The Customer Company Client's lawyers will make fine penalty against you or lawyer's will come knocking at your door... Usually these are realistic edge use cases.. I've also experience this when we are handling hundreds of Customer Company Clients... But overall, these pull requests is just there.. probably moved it into a future enhancement... But it will be noted, not for now... I know how it feels and annoying...

Especially, knowing your data structure for your API endpoints. These are being mapped out and documented... Trust me when you really handle Customer Clients and you have made a $500,000 good for 3-4 years contract deal... Believe me, you do not want to touch that... It happens for a reason.. So as for the Front-Ends, it is really up to you to make a workaround... And welcome to the Deep Deep South of Iceberg Development... XD lol.. that is how it is... Eat it up.. swallow it... move along and find another way until a new update release it out...

You have mentioned about there are other tools... True... But what about they have been using a different tools for so many years now... You cannot just immediately change to new tools... That is also another impact to the Customer Company Clients... You cannot just change things you want... That is the reality...

For small startups... this is possible to make changes. It also depends on what you are trying to solve.

In big companies, you'd have several FE feeding from one datasource BE. Coupling to a specific UI output is indeed not future proof or how I would personally go on about it. This is a blatant example of creating a dependency. Design dependency and FE specific (ioS, android, web, washing machine) dependency. You start off with the premise of these APIs almost certainly being used exclusively by that FE .... I'm a front end person and I would totally ask the BE guy to revert back to UI agnostic terms to favour this principle.

HTMX

That's a great way to put it. However, I don't really agree with naming the data "table1", "table2", "main", etc. That's just moronic; the API shouldn't need to be aware of which UI component will render the data. It should be in a more general, yet still sensible format.

Hard Agree. If it's a public API, tweet makes sense. If it's specific to one front end client (extremely likely), tweet is nonsense. I have been in this situation described, at work, except my MRs were not blocked. Thank God our whole team is full stack and we don't have two opposing Front/Back forces. We tried generic endpoints, realized it was shit perf, then we fixed them down to one query per page. Because of Back end for Front end. Because our back end was guaranteed to only ever be used by exactly our one front end client.

I partially agree, but a point to consider:
what if you have a native app, which for some reason wants the layout of some pages or just the UI in general, now it doesn't make sense to still use table1 and table2 (because you don't have this 2 tables), and you're left with 2 choices:
1. either refactor the endpoint to return the data based on the new layout, but it's a bad idea because people who didn't update will not be able to use the app
2. make a new v2 revision for your api, which is bad because you're bloating your server with "unused" but used code.

this problem wouldn't exist if you just return a json with the data with "generic" keys, which can be reused without depending on the UI

Just came to say your thumbnails are bad

what's twitter?

To me, frontend already handles a lot of complexity in navigation and other user interaction-driven state management. BE should manage all the complexities of data processing and give something to the FE that can be simply mapped to the UI. If we're querying from a sub-system that serves multiple apps, I'd just query it on my microservice, process the data, then return it to the FE. Your app will always need to have its own micro services anyways, so why force the FE to query the third party or sub system api directly when you can process the data on the BE and have better performance? Or worse, why would you query the sub system api on the micro service just to pass the exact same object to the FE?

HTMX tho

Those devs that just block your PRs on reasons like "this is how you're supposed to do it even if your way is faster, because I don't care about the app or your DX or how cool your code is, all I care about is me and always having my way"...

Because it's extra work to cater for your users. That's why.

As a backend dev I wholeheartedly agree on this take (also commenting for the algo)

I have the opposite problem.

I'm happy to make new APIs for consumers that need them, but they look at what's already there and make something really chatty, and then I have to go investigating why a particular endpoint suddenly has 50x the load it had the previous day, when we could have added what they actually wanted easily. We even have pact tests for consumers to spec out what they need.

This is not even a be/fe thing, as my consumers are other back end services, it's just a cross-team thing.

🤣 Backend for Frontend

I am falling in love with HTMX more and more every day

I think the point is to future proof your code, so that you can change your UI design and not have to have this weird scenario where you’re loading table1 into not-a-table. A bespoke API is fine, but maybe make the response UI agnostic

Fuck it lets just go back to PHP at this rate it seems like the logical conclusions.....

I straight up return component props types/interfaces from my tRPC endpoints. I like it because it directly expresses what this endpoint should be used for: fetching + transforming data to be displayed for a particular component.

For apps where a table or group of tables will be used only in a couple features, yes, close the gap and make things simpler, however in the corporate world, and I'm talking about application that will be used to manage a company like ERPs, CRMs and the sort, this approach is not feasible, reasoning:
Take registry tables like Products, Customers, Providers and tables that hold accounting ledgers, those tables will be used throughout the application, so having every single feature develop it's own API increases the maintenance surface too big, imagine changing a business rule in you Product registry because you have a new Tax rule to conform to, now all the API endpoints that will touch that table need to be adjusted.
We can't discuss these issues only in the lenses of web and mobile app development or from what most SaaS business model requires. Sorry but that's not where the most developers work and not where most of the capital around software is spent(read where demand is).

hate backend. works like shit. (i made the backend)

What about sideend

I have mixed feelings about this. The skepticism towards frontend is well earned (Redux, GraphQL).

I think the big elephant in the room is systems design and data structures. The frontend is often like "hey i want xyz for this component" and the backend is like "yeah but don't you see how this not gonna end well in the future".

That said, I understand where you're coming from. Most of the time the backend is not eliminating complexity, they are just dumping it on the frontend which then resorts to monstrosities like GraphQL (yeh I really hate it).

There is a balance to be had here but its really hard to trust you guys when you defend abominations like {table1: [], table2: [], main: []}. Come on Theo, really!?

Frontenders shouldn't tell the backenders how to work, but just what they need. And vice versa. Respect people with each of their own expertise. Also, are we talking about backend-backend? Or faux-backend (backend in javascript) :D

sveltekit is great as you literally don't need to worry about any of this bullshit about frontend vs backend as the entire code lives together, unless you go out of your way to separate it - in which case, why?