Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Practical Front-End Architecture

jaredgorski.org

Post reply on HN
Print view View original

71–80 of 164 posts

Re: Practical Front-End Architecture

#71

Post by yashap »

lolive wrote: post #68
yashap wrote: post #66

Earlier quoted context omitted.

We edit the OAS with Stoplight Studio, and enforce it with server-side middleware, which validates that requests and responses conform to the OAS (400s if requests don’t conform, 500s if responses don’t conform). At a previous workplace I’ve used OpenAPI Generator to generate clients and server stubs from the OAS, which is a nice approach to ensuring you’re confirming to the spec, too.

Did you have the requirements for users that you do not know want to define their own API upon your data?

No, it’s never come up. This is touted as a selling point of GraphQL, but IMO is mostly solving a problem that few people have. Having worked a lot both consuming and producing external APIs, people seem happiest with idiomatic, well documented RESTful APIs, they don’t want to learn some complex RPC system like GraphQL just to use your API.

I think these GQL benefits are somewhat legit:

1. Fetch in one round trip what would take multiple with REST

2. Fetch only the response fields you need

But honestly, 1 generally saves 0-1 round trips, and for 2, while response payloads are smaller, GQL requests payloads tend to be huge, so it’s largely a wash. At least in my GQL usage, they’ve been minor wins, not worth the complexity that GQL adds.

Re: Practical Front-End Architecture

#72

Post by dgb23 »

tl wrote: post #46
dgb23 wrote: post #20

Earlier quoted context omitted.

HN doesn't talk about it often but PHP is still the workhorse of the web. And that is for good reason. It's fast, stateless, easy to use and not just batteries included, you also get the charger, the repair kit, repair parts and adapters for seemingly every use case. That said, it's clunky in many ways and (very) slowly losing it's dominance. It's community clings on class based, mutable OO (while even languages like…

> and (very) slowly losing it's dominance Is it losing dominance? https://arstechnica.com/gadgets/2021/09/php-maintains-an-eno...

Haven't seen those numbers yet thank you. I was basing the above more on tiobe index, google trends and gauging the frontier of web development, which includes tooling, modern libraries.

Much of the effort in the latter part, innovation, products, tooling and marketing at the web frontier seems to more strongly focus on JS/TS/Node/V8/serverless/WASM. When I started with web dev, PHP was the de-facto standard language for small web-shops (Ruby was on the rise, Node on the horizon). I don't think that is true for the next generation of web developers.

Re: Practical Front-End Architecture

#73

Post by jaredgorski »

bern4444 wrote: post #57

There's a lot in here that seems off if not quite wrong. Throwing errors to be caught higher up, the way they manage redirects, and the lack of discussion around managing state (which could on its own solve lots of these problems). So much of this seems convoluted and unnecessary for a very simple goal of building a dashboard. Their use of Apollo seems to provide no advantage over a basic REST API. There's frankly ve…

Great feedback.

I’ve been wanting to write more about most everything you mentioned, but ended up writing about a few interesting patterns we implemented recently. I probably should’ve titled the post “A few interesting patterns we implemented recently”.

As for state management solving the problems of pageload validation (instead of our error boundary and redirect mechanisms), can you provide an example?

Re: Practical Front-End Architecture

#74

Post by yakshaving_jgt »

d3nj4l wrote: post #2

I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…

Elm's architecture is practical, and I haven't found the ecosystem lacking after having shipped tens of thousands of lines of it over the past five years. I've shipped a bunch of big React applications also, but Elm is the one I would choose every time.

Re: Practical Front-End Architecture

#75

Post by jaredgorski »

newshorts wrote: post #40

Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need…

Good! We need to get back to the basics and stop shoehorning React into every application.

I regret that my post is yet another React promotion. Not intended: architecture depends on use-case. I’m hoping to write more soon about selecting tools appropriately, which probably doesn’t mean React in many cases.

Re: Practical Front-End Architecture

#76

Post by Weebs »

ehnto wrote: post #24
d3nj4l wrote: post #2

I really love this kind of article because, as primarily a Backend developer, I'm finding it really really hard to make a "clean" SPA without any mentorship or help from experienced Frontend Devs. I can't find any well-documented best practices or architectures and patterns that seem to be widely accepted in the frontend ecosystem like there are for backends. Next is the closest that comes to having a "right way" but…

I think that's my pet peeve with modern frontend tooling, they feel like walled gardens of arbitrary knowledge that only applies to their ecosystem rather than to some fundamental learning about software. When I learned about OOP I was able to understand OOP code in a broad range of applications, languages and frameworks, but learning how react works gives me no insight into anything but react, and it's even abstract…

I think if we're talking about concepts at the level of OOP, we'd be comparing MVU and virtual DOMs rather than React. I learned to write UIs in F# through Elmish (used by Bolero), which was inspired by (unsurprisingly) Elm. React, also being inspired by Elm, was simple enough to transition to once I was comfortable in Bolero. It was basically MVU with components that have local state and lifetime function callbacks. I ended up tripping over TypeScript/JS more often than React

At the same time, I do know what you mean about the walled garden ecosystems. It seems unfortunate that every framework I pick up, I'm learning a new set of components everyone uses for things like virtualization. On the backend it feels less common to be using a library that's only relevant to your stack, and when there's a killer library in another language, you don't need to move mountains to use it.

Re: Practical Front-End Architecture

#77

Post by jaredgorski »

rimliu wrote: post #50
newshorts wrote: post #40

Been interviewing for a few roles lately and finding the new “react dev” eerily similar to those relying on jQuery back in the day. I ask vanilla js and low level layout/styling questions in my interviews (not gotcha questions, but instead what I consider to be fundamental skills indicative of experience) and am consistently met with confusion. Maybe I’m too old for this game and front end devs will never again need…

Just wait till HTML is rediscovered. "Hey, look, my content page is 2KB instead of 8MB"

“Hey look, the browser loads each new page one at a time instead of loading them all in the initial load.”

Re: Practical Front-End Architecture

#78

Post by yashap »

jaredgorski wrote: post #69
yashap wrote: post #52

Earlier quoted context omitted.

Agreed. Having worked extensively with GraphQL, I’ve come to see it as a MASSIVE source of unnecessary complexity in almost all cases. Haven’t worked with Next.js, but using an SSR framework, then not using SSR, seems like a tonne of unnecessary complexity too. They even say: > At Liferay Cloud, our project lives behind authentication and our clients are enterprise-level, with relatively modern browsers and powerful…

> So, why are you using an SSR framework then? Great question; I should’ve mentioned this more concretely in the post. I would’ve nuked Next completely, but we like the filesystem-based server and the ability to add imperative server-side logic cohesive with each page (getServerSideProps). In the past, this logic ends up on a separate server file and it’s less cohesive. Next keeps things a bit more organized for us.…

I haven’t used Next, can you explain this more?

> the ability to add imperative server-side logic cohesive with each page (getServerSideProps)

Our use case is an administrative web-app for managing a transportation network. i.e. you’ve got a bunch of cars and buses driving people around, you can use the admin web-app to see a live map of all the vehicles, see their itineraries, book driver shifts, configure rules about fares, where people can get picked up and dropped off, etc. It’s a mix of highly live/interactive content, and more static content.

Re: Practical Front-End Architecture

#79

Post by jaredgorski »

ilkkal wrote: post #29

Got a big chuckle out of them describing server-side rendering as this new-fangled unproven technical risk of a technology :) I get the context, but it was still funny. Ah, back to editing index.php I guess.

I’m with you :)

It’s certainly nothing new, but the “buzz factor” impresses people who don’t know what it’s for and they implement it everywhere thinking it’s an improvement. The trend/gimmick culture in frontend is a real thing.

Post reply on HN