Fine, I'll talk about frontend versus backend

I'm increasingly tired of "frontend versus backend" type debates. I hope this video helps explain why adequately.

S/O Ph4seOn3 for the awesome edit 🙏

[grim.reaper]

I like your take here tbh, I believe most development work should start with the question “what are we solving?” And “who are we solving it for” and the design should be based around this for both frontend and backend.

[Pisipoisu]

The point is not to reference UI elements in your endpoints/parameters naming. Not that specialized endpoints/parameters are bad. If later I want to refactor my UI to not use a table, but instead a accordion, then there would be a naming clash between the UI and endpoint. If the endpoint named its parameters for example "users" and "condensedUsers" (if for what ever reason we have two tables where one displays all the info and the other a more specific condensed version), then the UI would still have the flexibility to display the data however it wants, and not have any reference to "table"

[rijkvanwel]

This is why backend engineers are backend engineers. They don’t care as much about UX, otherwise they’d have gravitated towards frontend. I guess backend engineers enjoy a walled garden where everything is controlled and follows strict rules. Front end is inherently messy, not only because of the spread of devices, versions and browsers, but also because of the spread in use cases — users are weird and behave in unpredictable and sometimes illogical ways.

[devagr]

This video is extra fun because i know you and Cory agree on 95% of things, and the small 1% disagreement is blowing up on the internet. Even on this specific topic if you had a conversation with him you'll end up mostly agreeing

[Maniac-]

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

[lucas-barake]

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.

[blipojones]

There is frontend devs, backend devs, and liars. That is all

[PauloPM]

This just makes so much sense it opened a whole new way of thinking for me.

It's not a bad thing to do things very specific to the project you're building. Like, all of these are just pieces of a thing you want to deliver, it's much better if they assert the direct needs of the project instead of generic ones you have to puzzle together to get what you want. This second option looks like you're creating a puzzle to solve when you could just get the direct answer instead.

This goes beyond web development even. I'm gonna use this philosophy for game development and even animation. Ty theo, great content as always

[Andres-itdu]

I love Ryan's malicious compliance, what a guy

[jsonkody]

When we talk about backends, last month I had a very surprising hassle with my friend, who has been programming for much longer than me, but mostly just in C, math stuff etc.—no web-dev at all. He does not consider the 'backend' to be a 'server, ' which was very strange for me. I told him that 'server' is an extremely broad and vague term that can be used for many different things and layers; basically, everything that creates a 'server' -> 'client' pair. He started shouting at me, saying that it's ridiculous bullshit and that a server is strictly the machine or maybe an Apache, and nothing more.

[MrHopp]

The line shouldnt be backend vs frontend. It should be between full stack engineers who understand the domain and use cases and write the code, and UI/UX experts who can invision applications that dont resemble the Geocities archives.

[shenzo-]

Somehow this reminds me of computergames. You only need to request things that your user currently needs to get shown.

[jonathanpalma__]

Completely agree with you and Ryan, my take on this topic is:

Use RESTful / JSON-API / GraphQL (or any “standardized” style of API) *only* for public APIs consumed by third parties.

Otherwise, use an approach where you can query/deliver only the data that’s required for your client (tRPC, remix loaders, RSC, etc)

[angelicking]

Yeah it is frustrating because from the BE side they love that the APIs are "efficient" when you call them that is but compound that with many APIs stuck together that is not going to go well for scaling. Overtime I am going to try to take over the BE side after the barrage of frontend request is lowered so that I can have my ideal backend apis the way I want them.

[crazystve]

First off, I completely agree with you. However, I can also see the point here in the original tweet.

Don't couple directly to the UI elements, a payload with {sales:[], users:[], common:[]} would have done the same purpose if the table names were as named that. However, it means in a couple months time when someone says, Hey we want to change that table to a different kind of widget, the payload still makes sense, and you aren't trying to explain to someone 2 years later why `table1` goes to the widget component.

That said, I've spent more than a decade as a full stack dev, with a leaning to the backend. and when I have to use REST, I 100% put specific endpoints for key hot-path calls. REST is great, but there is a difference between REST and REST-like. Correct REST comes with many tradeoffs, and sometimes those trade-offs hit the non-functional requirements of the client harder than it is worth

[lukasmolcic]

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

[mitchellcook]

It does depend on how many unique clients you are serving. So I think I agree in the sense that, if you have a single client, be great for that single client. But if you are serving 20+ unique clients, you can’t build custom APIs at each of their desires. Maintaining more and more APIs for single client use cases, may not be sustainable for a backend team

[dovh]

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

[atjontv]

At work, our system is composed of Three API servers. Two of them serve to Frontends. Both habe Frontend related APIs. But, we also have a gateway service that combines all three APIs into one, which does not expose frontend-only APIs.
This new API is what external clients interact with. This solves the debating, the frontend serving APIs give what's best for the UI as well as some generic endpoints and the gateway does translations and filtering if needed.
This setup has worked perfectly for the past 2 years and will in the future as we deploy more instances for new customers.

[dzmitryluhauskoi]

If all your backend does is making sql queries, sure you wouldn’t see the issue in making a new api that composes bunch of data. But if your backend has a complicated architecture, domain structure and business logic just adding a new api is not an option sometimes. If your backend team has an issue with structuring their apis around client needs that might be for a reason. I’d suggest to just use a dedicated bff, supported and developed by frontend team to avoid strong coupling. If you’d only knew how frustrated I am when I need to change api just because some ui got updated(no new data, no new features, just staff moved from one page to another). This is where next shines, since you can use it’s backend as a dedicated bff. Speaking as a full stack dev with a preference for the be.