[kiney]

Unpopular opinion: I'm actually a fan of singe page specific endpoints. You get much easier debugging, easier to audit security, easier performance optimization an the imho pretty small price to pay is that it's "not elegant" and a bit of backend code

[WD-42]

Yup. Especially when your api really only has 1 (possibly 2 in the case of a mobile app) real clients. People like to pretend their apis are generic but they aren’t. There’s a good argument to stop writing generic apis for your single application.

[hansonkd]

Typically the endpoints clients are multiple frontend developers. If the frontend is blocked for every page they need waiting on the backend to expose data that massively increases the costs of features and reduces the time for delivery.

[bunderbunder]

This sounds like more of an org chart problem or a value chain management problem than a technical problem.

[throwup238]

That's why we have Conway's law.

[bunderbunder]

Yeah. And a gentle nudge that Conway's Law is about lines of communication in general, not specifically the org chart.

I used to be in charge of the stored procedures that served as the API to a shared database system used by many teams. (So, not exactly the same thing, but I'd argue that the sprocs vs ORM debate isn't entirely dissimilar from the REST/RPC vs GraphQL debate.) My turnaround time for getting database API changes into staging for application teams to play with was typically less than one work day. But that happened because I had a lot of latitude to just get things done, because the company valued rapid delivery, and therefore made sure we had what we needed to deliver things rapidly, both from a technical and a business process perspective. This was in a very highly regulated industry where every change required paperwork that would be audited by regulators, too.

I've also worked at places where this sort of thing took ages. Typically the worst places for work backing up were organizations that used Scrum, because the whole "sprints" thing meant that the _minimum_ time to get something from another team was about 1.5 times the sprint duration. And even then you could only manage that if you could deliver a request that already met all of that particular team's requirements for being able to point it, and could convince their Product Owner that it was a higher priority than whatever their pet project is this quarter, and the stars align so that you perfectly time the submission of your request with respect to that team's Scrum process's frame rule.

The thing I want to point out here is that absolutely none of that bullshit was ever the API technology's fault.

[DangitBobby]

Frontend devs can write fake API calls which return the data they expect in the meantime.

[WD-42]

This happens anyway.

[hansonkd]

Not nearly as often with Graphql and happens less and less as your backend and data models stabilizes.

Most of our frontend features now don't have backend changes and we were able to increase the ratio of frontend to backend devs.

[blowski]

My experience is that the problem is avoided in theory, but not in practice.

Making a good API on a large system with many clients is always difficult. GraphQL makes it easier in theory, but if you have average level devs working on it, they’ll make a bigger mess than if they use simple REST. The latter will still be complex, but at least it’s easier to have observability.

[ethbr1]

Aka never underestimate the power of additional complexity to drive bad use, absent familiarity.

[eddd-ddde]

This is the true purpose of REST. If you need to make multiple requests for a single operation you don't have enough endpoints.

The idea that resources and the underlying data needs to map 1-1 is wrong.

[marcosdumay]

The modern web development practices are just insane.

The GP's idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy.

On the other extreme, we have the HTTP 1.0 developers saying something like "networks are plenty of fast, we can waste a bit of it with legible protocols that are easier to make correct", while the HTTP 2.0 ones are all in "we must cram information into every single bit!"

Every place you look, things are completely bananas.

[klibertp]

> idea that a frontend developer would send a ticket to somebody so they can get all the data they need... it's just crazy.

For me, what's crazy is that there are "web" developers who can't just add the endpoint they need while working on a frontend feature, or "web" developers who can't just add an element or a page for testing the backend endpoint.

What ever happened to full-stack developers? The "frontend" and "backend" developer split is so incredibly inefficient that it's really jarring—you take something that should take 2 hours and magically, through tickets, delegation, and waiting for results (then repeat that for debugging, who knows how many times!), make it into a 2-3 day task.

I once reproduced (black-box style!) a two-week effort by a three-man team in six hours of work simply because I had PyCharm and IDEA opened side-by-side and could write code on both sides at the same time.

If someone has a good explanation for why the full-stacks that were once the norm went almost extinct, I'd be happy to give it a read!

[GeneralMaximus]

For context: I work on large-scale browser apps that are closer in complexity to something like Linear or Obsidian than to your standard WordPress blog with some forms. E.g I'm currently working on a browser-based GIS tool for the financial sector.

I started my career as a full-stack developer, but went all-in on frontend because I felt I was spreading myself too thin. At one point I found that I could choose to be almost good enough at doing two different things or extremely good at one thing. I chose the latter option.

Modern browser apps are complex beasts, at least if you want to do them right. You obviously have to worry about all the technical bits --- HTML, CSS, JavaScript, your view library of choice, platform APIs like <canvas> and WebAudio, cross browser testing, bundle sizes, performance optimizations, techniques like optimistic rendering, all that good stuff.

On top of that, you also need to work closely with designers to make sure they know the features and limitations of the platform(s) they're designing for. More often than not, you end up being a sort of bridge between the backend devs, designers, and product managers.

A lot of times you end up doing design too, whether you like it or not. I've learned a lot about UI/UX design just because I often have to fill in the gaps where a designer forgot to include a certain error state, or didn't test their design on tablet screens, or didn't account for cases where a certain API might not be available.

I tried for many years to learn as much as I could about Django as well as React and friends. But it eventually got too much. I found that I wasn't able to keep up with both ecosystems, and I was producing code that wasn't very good. I could certainly build things quickly because I was familiar with all parts of the stack, but it came at the cost of code quality, security, stability, and robustness. I eventually decided to hang up my backend developer hat and focus exclusively on what goes on inside the browser (which can be a lot by itself these days!)

It's probably possible for a single individual to build a high-quality server-rendered MPA with some forms without making a mess of it. But that says more about how good Rails/Django/Laravel are than about the capabilities of any single individual. I don't think a single person could build a product like Linear end-to-end without cutting corners.

[int_19h]

IMO the fact that being a full-stack dev is so taxing is an indication that the stack as a whole is just way too complex and overengineered. Which is rather obvious from looking at the state of affairs on the frontend side of things. Desktop GUI devs don't usually have those problems.

[mc10]

I don’t think this is a fair conclusion; web development is harder than desktop GUI development for various reasons.

For one, clients (mobile, desktop) are drastically different with all sorts of downstream implications:

- Differing screen size requiring responsive design

- Internet speeds magnitudes different

- Intermittent internet

- Uneven feature support due to different versions of browsers

- Everything needs to be JS at the end of the day

Desktop apps generally don’t have to worry about any of these issues.

Also, desktop GUI frameworks are typically either fragmented (one per OS) or don’t look OS-native.

[int_19h]

Thing is, even when web apps are essentially used as desktop app replacement (Electron etc), all the complexity discussed here is still there.

As far as looking OS-native, this is (unfortunately) increasingly less relevant as OSes themselves drop desktop UX consistency even internally. But that aside, Qt is still around and is a very mature framework for "near native" UI, and then there's Avalonia and others. Even Gtk is surprisingly decent on Windows these days. Although I'm not sure what this all has to do with the original subject, since web apps most certainly don't look native anywhere.

[evantbyrne]

I don't think the claim is that a single developer should be able to build an entire enterprise product, but rather that a single developer should be able to implement the software side of a task end-to-end. The latter is a reasonable expectation when your software is monolithic.

[apsurd]

> ... I don't think a single person could build a product like Linear end-to-end without cutting corners.

Cutting corners is a feature. I bet the Linear team is as pained as any, internally, at the tradeoffs they're making.

There is no way to know "what to get right" without going through it. So for 80% of the dev cycle the job is to cut corners to get to the 80/20, rinse and repeat forever.

This isn't against excellence and the dream of a beautiful product experience as your reply seems to convey.

[marcosdumay]

If you absolutely need 2 people for that, they should be side by side.

But yes, that break-down of the problem is insane. People artificially split an atomic problem in two, and go create all of that extra craziness to try to solve the communication problem they made.

And then people go and push UX and UI tasks into the frontend developer, and ops tasks on the backend since them are there... What is insane again, because those are really incompatible tasks that can't be done with the same mindset.

And since it's standard, backend tools won't support the frontend and the other way around. So the insanity gets frozen on our tooling.

[riffraff]

Because people have a limited appetite for complexity.

I wrote some front-end stuff back in the days but I've lost track of whatever is happening these days. jQuery to append some stuff took five minutes to learn, but learning react hooks takes a determined effort.

Likewise, adding a field to a graphql type is simple, but doing it with authorization, controlling n+1s, adding tests etc.. requires front-end folks to actually invest time in learning whatever back-end they're dealing with this time.

Everything is just a lot more complicated these days, and if you've been around for a while you may not be excited anymore by the churn, but rather fed up.

[jack_riminton]

This is why the Rails community should be applauded in my book, for their dogged determination that we should keep it a “one person” framework. Yes it may not be as performant, type safe or flashy on the front end but my god it’s productive.

At my startup there are 7 devs who can all do tickets across the stack and as we grow I think it would be good if we could resist the pressure to silo and specialize

[ethagnawl]

> but my god it’s productive.

It really is. Regrettably, I've drifted away from it in large part because of client requirements for more "modern" and "maintainable" solutions (e.g. Python or Node; I'll take Python every time, thanks). Django comes very close in terms of productivity (and is better in some ways: auth, admin, etc.) but the Rails CLI, generators and community (not sure if this is still relevant) give it the edge.

The "recent" (last 10+ years) movement towards "lightweight" libraries (instead of frameworks) that require you to either reinvent the wheel, copy-and-paste or use some random "getting-started" template every time you start a new project is disheartening. As others have said above, I think it's partially resume-driven-development and people wanting to tinker (both of which I do appreciate).

Something which continues to surprise me is that there hasn't really been a "modern" successor to Rails. Granted, I haven't kept pace with developments in the Node/TypeScript world but, last time I looked, Sails was on the right track but wasn't very actively developed and I was shot down (in favor of Express spaghetti) when I suggested it. There's also a smattering of Rust web frameworks but none that quite fit the bill and come with all of the batteries and opinions included. I keep saying I'm going to do a Summer of Code project which attempts this but ... life.

[mike_hearn]

There are some Java frameworks that are kinda similar? Take a look at Micronaut for example. It has data access interfaces that use ActiveRecord's naming approach, controllers, view renderers, and a whole lot more on top.

[GreenWatermelon]

There's no modern successor to Rails because Rails itself os still modern and very much up to date. The recent introduction of Stimulus allows to implement a SPA completely on rails (if they wanted) with the same simplicity present everywhere else in the framework.

[ethagnawl]

I don't agree with much of this but it's timely: https://zenstack.dev/blog/js-fullstack

[defen]

Many organizations would rather pay 3 people $120,000 each instead of paying 1 person $300,000 to do the same work, for a variety of reasons. Some good, some bad.

[evantbyrne]

Microservice architectures and the associated explosion in complexity on both ends are to blame. When it takes twice the time to build something, it is natural to hire twice as many developers. Increased complexity drives specialization.

[nurple]

I think it's elegant. I loved MVVM in the postback world, and with SPAs, I see view-specific endpoints as the view-model continuing to reside on the server while the view was split off to the client-side.

[blowski]

I’ve heard this called the “backend-for-frontend” pattern.

[charlie0]

Sounds good in theory. In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code. This isn't a problem until the application gets big enough and now you have business logic that should be the same spread out across an app. This leads to weird bugs where something that should work the same way doesn't depending on which page you're accessing things from. Of course, I don't a solution, solving things like this is what makes software engineering hard.

[Sammi]

> In practice, what I've seen is people don't just do single page endpoints with shared services, they follow this all the way down into the services and so you end up with lots of duplicate looking code

There is no easy or simple or final solution. The solution is to do the hard work of software engineering and catch this stuff at code review time or to plan and do refactoring later when you realize something needs normalization. I wish developers would just accept that software engineering is hard and do the hard work necessary.

There's that whole "the best software engineer is lazy because he will automate stuff", but that does not give anyone a license to automate stuff in an unmaintainable way. Automating stuff is hard and there is no easy way out.

[shados]

The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance.

Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database.

The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.

[rbalicki]

GraphQL gives you this. https://relay.dev/docs/guides/persisted-queries/

[crubier]

Came here for that. People in this thread basically reinventing GraphQL lol.

"We need a http API endpoint that gives you all the data for one page. And also be able to reuse parts of it for other pages." Yeah bro, this is GraphQL.

[datavirtue]

Agreed. Specific endpoints. I was on a project recently where a 40+ yr old dev was going crazy over "pure REST." It's embarrassing. Sure, have your pure REST but FFS create specific endpoints if you they make sense.

[mgkimsal]

You are literally Transferring the REpresented State of a given page/view/screen.

Screen-specific REST endpoints will make their way as a default in to a JS-based framework in 2025 and people will pretend like this is some breakthrough advancement.

[mjburgess]

And finally HyperText will progress into the futuristic HyperCard