Fine, I'll talk about frontend versus backend
Вставка
- Опубліковано 31 жов 2023
- I'm increasingly tired of "frontend versus backend" type debates. I hope this video helps explain why adequately.
Check out my Twitch, Twitter, Discord more at t3.gg
S/O Ph4seOn3 for the awesome edit 🙏 - Наука та технологія
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.
its literally the first thing they do in every company .
true and that is why designs are made, to know what to serve to the user and based on the requirement, both Front end and backend prepare the data models and schema, so following UI is completely fine otherwise it will be imaginary data.
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.
Backenders just want to solve puzzles.
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"
Exactly, I was about to make the same point. Also in some cases you render different components based on resolution. You could render a table on desktop, but card components on mobile.
I could not agree more. The original tweet doesn't even mention BFF. If I were just building BFF, I wouldn't even build a REST API. I think REST APIs are a good solution when you need data to be available to different types of clients consuming it, so the data needs to be exposed in a standardized way.
Exactly! As a backend dev I would totally agree with this.
Absolutely, I think that on this one, Theo ignored similarities in approach and points of agreement (BFF) to focus exclusively on divergence. Thus creating a rather uninteresting and unnecessarily antagonistic discussion. And repeating ad nauseam that it's a " dumb tweet " adds nothing to his argument. It's a shame, I wasted my time with this video and all I had to do was read Cory's clarification to see that they weren't talking about the same thing. Clarification that Theo doesn't mention, I don't know if it's incompetence or malice but I'm very disappointed.
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
95% + 1% = 100%
@@sandworm9528😂
@@sandworm9528 4% is dark matter
I think Cory later explained his point that he just wished the naming wasn't so coupled to the markup - it should have still been named after what data it provides, not what UI does it serve. So not "table1" but "reviewsWithSummaryAndStatistics".
Having a custom endpoint for a specific UI is fine by him iirc.
@@sandworm9528 the other 4% is unit testing
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
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.
"Geocities archives" :)) ah today I'm dealing with something like this, luckily I have my own bff, but even looking for data seems like searching for the needle and there's no documentations of their apis..worst case, was having states in numbers..like how would I know what 2 stands for
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.
I love Ryan's malicious compliance, what a guy
As a backend dev I wholeheartedly agree on this take (also commenting for the algo)
Nice take, I'm just not sure if I agree with 4:50 . Responding with Data (vs HTML) doesn't allow for more flexibility on the FE side?
I'd be keen to understand your viewpoint on dog-fooded internal/external APIs. So you have a frontend that you serve to users that uses the API, but you also want the API to work for external clients. How much of this holds up still? Is this just where GraphQL shines?
Great video! Would be nice to see a spectrum of too simplified to too specialized api endpoint returns. I understand the point this video makes but I would love some examples.
Somehow this reminds me of computergames. You only need to request things that your user currently needs to get shown.
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
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.
The server serves the back end. It's a secure gateway to sensitive code and private data. Servers can also serve front end, case in point, nextjs serving front end react code.
There's a reason server is the term we use for this. It's a restaurant waitress that serves the food prepared from the back end kitchen. The client doesn't need to know how it was prepared, just that the server fetched the correct meal from the kitchen.
Your friend is smart, you should listen to him. Web dev in 2023 is broken.
I think he is right because if your code in C is just a tool to fix some files? Or you just make a calculation and display the result? A server usually watches an endpoint for clients, while most code they write will not expect any client
Does this view point become less valid when you’re product has multi routes in? (Such as Reddit; App, API, Website)
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 ?
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.
Even for a one-off, one would hope that the variable names would make some sense.
Can you discuss how does this scale when the domain gets really big and we need to divide BE into different services for scaling or segregation?
If you have one huge database, you can have 1 team managing the data and creating generic performant rest APIs. The teams managing the different apps and features can manage their own microservices that query into your API, process them for what they need, and then serve it to the FE. They will probably also have their own smaller databases to manage data that only their features/ app needs.
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.
This is because people can be too dogmatic.. flexibility is key. The fastest way from point A to B is a straight line - some of my best ideas have come from recognizing a solution that was so simple and elegant but no one thought about them because "this is the way it's always been done".
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.
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
Then you make a thin BFF for each client.
IMO Sveltekit takes the cake here (in a positive way). I've long considered and debated with myself wether to create a REST API (within Sveltekit), but now I just use actions and call it a day. Even for client-only rendered pages. It's so simple and easy and safe. Why even consider HTMX, if you can have the same or even more simplicity and additionally rich interactive frontend? By the way, I'd like to hear Theo's thoughts on Sveltekit after some beverages :-).
Svelte is dying dawg
Brilliant breakdown!
Yeah! Can’t agree more that the goal is building a great user experience, and most of user starts from the front end
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
It kind of depends on what you mean by backend. Ever since SPAs became a thing people got it in their mind that everything that runs on a server is part of the backend, but it doesn't have to be.
Putting all that slow complicated communication between between the browser and the backend into the same datacenter or better yet into the same machine or even binary seems like a big win to me. But you still need to separate the backend from the front end. You don't store user data as a john_doe.html. You store it in a database and access it via the presentation independent SQL.
Hiring for drivers: Are you more of a pedal person or steering wheel?
I am falling in love with HTMX more and more every day
To the point of the UI endpoint returning keys with UI names - probably not best practice as UI can change.
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.
ConvexDB why shouldn't I use it...?
One advantage of a smaller number of fixed endpoints vs bespoke ones is it's easier to enforce that cross cutting concerns are being handled. E.g. making sure that a permissions are being properly checked on a call. Or that only the right fields are being returned... Is there a best practice for handling this kind of thing?.... Other than that I completely agree.
Couldn't you just have Middleware do that?
@@maxsturges4630 i agree with your way of doing it, I meant the OP
I try to do the api layers with data access layer, business logic layer and presentation layer junk to stay organized but then you deal with websockets and other random stuff that throws off how I should organize.
What's your take on using dynamic APIs i.e. Supabase etc. So the frontend team can choose exactly what data they need?
It's all fun and games until they come up with a query that brings your database to its knees ;)
@DarenC that's fair but can't remember how many times I have seen that happening from BE teams :)
Maybe a similar service that has more query restrictions could be the answer.
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
I am an middle-end developer!
If your company is responsible for both frontend and backend, I truly agree that you should be able to add extremely specific endpoints. It should only be for fetching data though.
Why only fetching data?
@@paragateoslo Multiple reasons. Updating is easier done in parallel than fetching as the fetching may be reliant on other queries. Updating is usually more fine-grained. Mixing that stuff tends to become a cobweb of nastiness in the backend.
Fetching view-specific data to get a better user experience is just a far better case for tailoring.
@@CottidaeSEANot sure I'm following.
Are we talking about not having a specific endpoint for updating from the frontend?
Say we have a form that collects data, that in backend may be stored different places. Should the frontend call multiple endpoints?
@@paragateoslo Give me an example of a form and I'll be able to provide a better answer.
Chances are most of the forms you will ever create are for very specific things and will not need custom endpoints and can also likely just be adjusted to be multiple forms without degrading UX even if they are. Multi-step forms for example.
I love this take because fundamentally this is a people/organisation problem masquerading as a technical issue. As someone who focuses on back end I am fully aware that the UX should trump everything. Ideally there isn’t a split but if there is these are exactly the things that should be expedited and not rely on cc-ing SRE etc.
IMO it is pretty cheap to make specialized api points along with restfull becouse you can increase productivity of team and speed of an app
But, this will become a shotgun taped to kneecaps when you add more features or features must be changed
What happens when u need a mobile app. Rewrite the backend ?
There is frontend devs, backend devs, and liars. That is all
processing data on the backend is SOOOO much easier than processing data on the frontend. I honestly can’t tell you how or why that is.
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)
Feels like the first tweet should be some htmx-style response. And the second should at least consider having the option to call several methods in the same request.
the challenge I often see is that any frontend/backend application is often very tightly coupled. A rename of a property in your backend can break your frontend application instantly especially if you use something like graphQL where the schema has to be followed or the API throws an error. And then who's fault is that a feature was broken?
I also see convoluted business logic. Some is handled in frontend and some in the backend and often there are disparities (it also causes trouble deploying them separately and dealing with browser cache still following the old business logic). As a consequence and to avoid fighting who broke something (and that the backend always needs to block any incorrect input data), the thing that worked most for us is keeping the frontend 'stupid' and the backend 'complex'. So if something breaks, we can always blame the backend.😀
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
True, I do agree that data should be named according to what they are and not where they are in the UI.
It’s not easy to have a direct backend for frontend. Many times you use the data at several places in the frontend itself.
A front-end shouldn't have a back-end at all. The two shouldn't even overlap imho.
@@levyroth I didn't mean to say backend is always required. My point is to fetch data to render a specific part of app is not as straight forward as Theo suggesting
I agree with all of this. But an interesting counter example of what not to do with APIs are the AWS APIs. AWS designed most of their APIs for their console, and then just exposed those APIs to developers. For example, the Lex API for bot building is abysmal, requiring multiple calls for something that should be a single call, because in the UI, the separate parts are triggered but user interactions.
What happens when your front end devs write backend code that queries a non indexed column in a SQL database with millions of rows and then wonder why all of the backend endpoints are taking a long time? 😂
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.
Agree. If your BE serves just one FE, built by the two guys sitting next to you, just meet in the middle.
Or create a BFF and both parties have what they want.
Yes and no. As frontend engineers, we tend towards generic and reusable components, because creating a million slightly different variations to fit slightly different purposes is tedious and results in unmaintainable code spaghetti. Similarly, I completely understand backend engineers wanting to avoid such maintenance hell by setting standards and pushing for reusability. Of course, this is a question of scope. If this comes from a small company with a small codebase, then I agree 100% with the video. If, on the other hand, this is just one service out of many in a larger company, I fully get why they would be vigorous in defending their stance. You need to impose order on chaos or the whole thing becomes unmaintainable and collapses under its own weight.
Why dont backend developers and frontend developers talk before developing any API?
They do, but there's always a conflict of interest. Sometimes backend think they are more important and better than frontend
Becsuse front-end people were never supposed to be tech literate. Front-end used to be what UX/UI is nowadays.
Theo: explains the eternal blood war between back-end and front-end devs.
Me: does both front-end and back-end; has an autoimmune disorder.
The war runs deep.
I agree with you on lot here, just wondering if BFF is harder to maintain in the long run, like people forgetting to update some query with the rest of the changes/fixes but it's also probably related to your code structure and organisation
It boils down to the eternal (weird) quest for "separation of concerns", which looks good on paper but is absolutely not useful in some cases where, by nature, your concerns are the same at every level of your app/system/service.
So why spend the time to try to separate the concerns by adding abstraction layers to pretend there is no friction between each part? If you'll ever use each part in a tighly coupled way, this friction isn't a bad thing. It's a logical thing.
On my job we're doing all stuff on BE, totally ok with that
API's should be a contract between frontend and backend, that should be reviewed if it is usable for frontend, and everything is clear and usable.
If you have the contract (e.g. OpenAPI spec), frontend and backend can be build.
So API spec first, before a single line of code of frontend and backend is written.
But start with the frontend to learn, test with the mocked API, based on the spec, and everything can be optimized.
If the frontend is happy, you can start to make the backend ready.
Then you have a neat way of communication, where frontend and backend is happy with.
FYI And I generate types from the OpenAPI spec, so frontend and backend can have type hinting from the beginning.
It is like TDD, write first the spec, then the implementation.
Write first the OpenAPI spec, then the frontend and backend code.
So are you advocating for graphql?
as a small team, yes everyone does 80:20 regardless of which way they go
Literally agree with you at this one
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.
Sure, accommodate what your user needs but don’t dismiss rest or other existing architectural styles.
Once the project grows in size, you realize that you need to draw the boundaries to keep it maintainable. Then you’ll add another layer under your bff (server actions, whatever you call it).
If you don’t realize that or you insist on what was being done so far was wrong and people before you couldn’t think it, then you’ll start hating your project as it becomes a coupled, spaghetti code. You try to take a forkful but you get the whole plate.
I’ve made that mistake in my startup project and right now I’m trying to untangle all that stuff from each other and realize it’s turning into modules around resources. It’s definitely more difficult to bring in that order later than sooner.
I think the point of Cory's tweet (as shown below the main tweet) was not that you shouldn't expose UI tailored endpoints, but that you shouldn't tie them to HTML structure. For example if this particular UI was tomorrow reworked and created as a list and not a table, those "table1" and "table2" properties wouldn't make sense at all. Yeah it's not a big change to just update names of these properties, but it seems unnecessary. If in an imaginary social media app these were called "followers" and "following" for example, they would make sense semantically and would actually describe what data is being returned.
But in the end, most apps are simple CRUD apps so doing a RESTful API isn't that bad. /api/users and /api/projects seem like good routes to get data to show in some list view and that's it.
Amen!
I find it funny how most backend developers who hate coupling their API with front-end still decide to work on web development projects. Like if they hate working with front-end so much, then just don't decide to take part in web development projects!
I actually agree with the tweet because coupling the API to the UI and having non standard behavior is blocking a lot of features because we don't have enough man power to allocate time for that refactoring so we've left our app riddled with bugs since they don't have high priority
curious how can it block features? You can have RESTful routes and have UI specific routes like '/getDataFor[specificUI]' entirely separate, one maintain the FS/BE team and the other by FS/FE team. As one comment pointed out it's an organizational issue more than a technical issue
@deybmen the code base is 2 years older than my time on the project. but you are right that it probably is feasible in an organized team, but it's one FE and one BE with a list of features expected every week that takes more than 2 weeks
what's twitter?
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"...
the most frustrating answer is "this is anti pattern". Ok, then what pattern is it anti? What consequences do you think there would be?!
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.
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.
yea I have a comms issue as well. I feel like there should be processes to make sure it is easy to inform each other of required changes including changes in load capacity needed. What are you changing, what do you need, what is the timeline...A lot of people hate paperwork but unless you have a process in place you are sure to forget to inform someone of some important detail.
4:06 «The components themselves can determine what data they need, on the backend itself.» It’s great for full stack devs, but otherwise this requires communication between the frontend and the backend dev. They should communicate, but I guess they’d like to avoid that.. Hence all the effort teams put into API contracts. To maintain the part-illusion of being able to work independently (until it all blows up, of course).
Now that we have Nextjs 14, I prefer use rest backend for complex business logic. If your Frontend just need to do simple crud, just use sever actions
I mean, you can still call a function that contains a complex business logic in your server actions no?
@@wobsoriano Yhap, but in this case, it makes more sense to create another project. backend is more scalable for complex scale logic. BUT YES, you can use sever actions for complex business logic
? GraphQL Types don’t have to be nullable
I am triggered by the lack of commas in the supposed REST-response.
Bad enough to call it a "REST"-api, when it clearly isn't, but invalid JSON is a bridge too far.
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().
Coupling to the frontend makes no sense. Yes, I agree, that the api in almost all cases serves the frontend but you still have to consider the scalability and maintenance. I think this has more to do with incorrect structure within the company. I see frontend devs behaving like ux/ui devs. Why??? Have a team that deals with ux/ui and let the frontend do what they do best! Same concept for backend, you don’t just have one backend team building everything! Have multiple backend teams and this nonsense will end.
Why even make this trivial, in the end if its all about delivering solutions and solving problems through proper communication.
5:35 But businesses/devs want to enable 3rd party API consumption, and merely dogfood their own single API, instead of the problems of keeping a separate API for 3rd parties up to date.
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.
I agree so much. I think this is pretty much a classic case of premature optimization, but in terms of design instead of performance. People seem to have a hard time actually asking the question why? Why don't we couple our API's to UI? Is it actually valid in most cases? Does having an exposed endpoint mean that the whole thing has to be coupled? What is the real cost of maintenance and so on. Given a precise context, much better questions can be composed, but either way - design ideas should absolutely be questioned if they prevent efficient solutions.
it only works if you have 1 client when you have multiple clients it's not worth doing that
The database REST shit where you have a route with CRUD per DB table is so hilariously backwards. Yet so many defend it religiously...
Between a better UX and a better DX guess who’s gonna always win in the end? That’s why the internet sucks
Isn’t backend and frontend people be working together 🥺 no?
I get the differences in work but the point I am trying to make is both frontend and backend have same goals i.e building application, no 🥺
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.
Only reason why this distincton exists is that some devs hate CSS ❤
And css is actually reasonably easy once you've spent enough time on it
@@gintoki_sakata__ anything is reasonably easy once you've spent enough time on it, that's called experience. Isn't that kind of a dumb comment? :p
@@pylotlight if it makes you feel better, yes, it is a dumb comment
Remix React Server Components for the win!
Yeah, separating out the front end into JS was a mistake. MPAs are better, made a little smoother with HTMX.
Overall I agree with your point though. The pattern is called MVP (Model-View-Presentation). Pass exactly what you need for the presentation layer.
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).
I would die on the hill 😆
I'm recently start studying react front to T3
When i develop spring backend api
More I have insight tk
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
"why do we have all these steps" - Umm because of the rise of SPA's and frontend overengineering, specifically frameworks like React. It was never like this before. You literally would just assign an instance variable in Rails and the data was in your HTML lol.
I agree with this on so many levels lmao
Yup yup
I am a frontend dev and we have a pure REST API on the backend. The backend devs are against any changes, so when we need to eg. remove items in bulk on the frontend, we send n requests to the server for each item. It blows my mind, but hey, backend knows best
What about sideend
I cannot agree more.
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?
The real problem is that there should not be any sides. It's all one system, and the divide between front/back is artificial and unnecessary.
Coincidentally watched this great talk by Joe Armstrong a few hours ago, where he relays the idea that any system too large to be fully (or mostly) understood by a single person probably shouldn't be built.
ua-cam.com/video/-I_jE0l7sYQ/v-deo.html
The real problem is that websites are not apps. Never were, never will be. It seems in 2023 we're very confused as to what and why we're codinf (apart from getting a job to get paid). Young devs really can't see the difference anymore between a website, a web app or just an app (used to be called software in my day).