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

81–90 of 164 posts

Re: Practical Front-End Architecture

#81

Post by mdtusz »

jaredgorski wrote: post #67
mdtusz wrote: post #63

Earlier quoted context omitted.

I continue to see this idea posted in HN and Reddit programming threads and it comes across as ignorance more than anything. The reality is that nearly all new modern web applications will be written using react or vue, with a long tail choosing a more esoteric or experimental tool because it either fits the project requirements, or the team is willing to accept more risk in favour of some other benefit (often times…

I think both can be true. There are practical reasons to use React and Vue, but that practical approach is obfuscated by the zeitgeisty culture around tools that get unwisely applied to every use-case. Frontend architecture needs to be approached soberly and prudently. Not every site needs React and GraphQL.

I completely agree!

What I intended with my comment was to point out that the idea of new frameworks being created every week is a bit of an exaggeration and that it being the reason frontend development is fragmented is just totally incorrect.

React or Vue on their own with a sprinkling of helpful utility libraries will get most projects 99% of the way there though, and often times that _is_ simpler than trying to put together your own system for server side rendered pages and template composition.

Of course, if you're making a blog, you don't need any of this, but for _web applications_, I don't think I'd reach for SSR anymore.

Re: Practical Front-End Architecture

#82

Post by karolisram »

BigJono wrote: post #37

> Therefore, we've elected to render our application completely on the client. On Next.js this means that we wrap our React app in a "client-side only" component that looks like this: > > This component only allows our React code to render inside the browser environment, minimizing Next.js' server-side render runtime. Yep, sounds like a practical way to do what is literally the default. So does the 4 paragraphs of cl…

Do you know any good repos I could look at to see how actually practical front-end applications look like? Of course, keeping in mind it does all you'd expect a typical web app to do like CRUD, etc. I feel like I'm deep in the rabbit hole of Next.js + Apollo GraphQL but am interested to simplify whenever possible.

Re: Practical Front-End Architecture

#83

Post by jaredgorski »

andrewingram wrote: post #62

Not planning on getting dragged into a debate about whether GraphQL is a good tech choice here (even though I won't pretend i'm not a massive fanboy). But the "with-apollo" Next.js example used as a reference (and then decried as being a bad experience and unscalable), is a pretty bad representation of how it can feel to use GraphQL with Next.js. I've never used Apollo in anger, but i've used Relay with Next.js for a…

I’d love to hear more about your experience with that “with-apollo” pattern. I decried it without using it first, but I see the problem as a coupling/cohesion imbalance.

What has it looked like in practice for you?

Re: Practical Front-End Architecture

#84

Post by woutr_be »

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…

I remember interviewing people for a front-end role as well, and when asked how they would decide between traditional HTML rendered on the server, or a framework like react/vue. Some flat-out couldn't even comprehend what I meant. I honestly feel like this is becoming a problem, where junior devs don't even know how to build anything without react/vue (or the likes).

Re: Practical Front-End Architecture

#85

Post by woutr_be »

lampe3 wrote: post #58
rimliu wrote: post #50

Earlier quoted context omitted.

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

Senior Frontend Dev: HTML was never gone :) I have and still working on big e-commerce websites. For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved. What I see is the problem that people think that "Frontend development is easier than backend development". For me, they have different challenges and different ways of thinking. Getting a good full stack developer is kind of getting a g…

> What I see is the problem that people think that "Frontend development is easier than backend development".

I hate that statement so much. Even had some serious arguments with "back-end developers" who were constantly mocking HTML/CSS/JS. Turned out that when pushed to do it, they just couldn't do anything and had to ask for help.

Writing proper reusable HTML/JS isn't easy, it also requires thinking on how to structure and split up things. Especially when you throw some CSS into it.

Re: Practical Front-End Architecture

#86

Post by aantix »

danr4 wrote: post #30

maybe a bit off topic but i'm still on the fence if front end will ever be "solved". The difference is that backend is always going to be some variation of CRUD, so the architecture isn't changing too much. front end being the actual user-facing layer means it will always evolve with human-computer interface (UX?). Mobile phones completely changed the way we thought about frontend, and it's just time until the next b…

https://hotwired.dev/

Re: Practical Front-End Architecture

#87

Post by emilecantin »

rattray wrote: post #61
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…

How do you keep your openapi spec up to date?

Not the user you were asking, but the way we do it is that the OpenAPI/Swagger spec is auto-generated from server-side code (a C# .NET app with the ABP framework) during the CI build, and that is then used to auto-generate an API client (via swagger-typescript-api) which is what the frontend app uses.

When the backend team makes some changes, they notify the front-end team which then runs the auto-generation script, fixes the typescript errors (if there were breaking changes), and that's it. Pretty nice setup, IMO.

Re: Practical Front-End Architecture

#88

Post by bern4444 »

jaredgorski wrote: post #73
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?

Totally, I think if this article were titled patterns it'd be more accurate. Architecture has a more specific meaning (at least to me).

As for using state, when you use something like react-router, all those things, path parameters, query parameters etc are stored in state.

You can build hooks that use the hooks provided by react-router to retrieve those values in a useEffect in the relevant components. The hooks you build can be responsible for validating the path/query params, coordinating route changes etc.

The larger idea is to use your state as a means of coordinating messages that any component can hook into. So you could include in each of those detail pages a redirect route component that only fires when the hook you wrote detects that a page is invalid.

To take this to another level. You could build a Higher Order Component that automatically embeds this ability (a redirect component with a custom hook) into your item detail pages so that it's automatic.

Re: Practical Front-End Architecture

#89

Post by jaredgorski »

yashap wrote: post #78
jaredgorski wrote: post #69

Earlier quoted context omitted.

> 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 abo…

Totally. With Next, your page component can export a getServerSideProps function which is used by the Next server to fetch any props necessary for the page component server-side on-demand. There’s a variation of this function for static builds called getStaticProps, which runs at build time to fetch data for props. So, even if we don’t render anything server-side, we can still run logic/fetches/etc. on the server side when a particular page is requested. This could be useful for dealing with sensitive data, for example.

Sounds like a cool app. I definitely see plenty of opportunities for static content there, like you said, but proper state management is vital for the real-time stuff.

Re: Practical Front-End Architecture

#90

Post by rattray »

emilecantin wrote: post #87
rattray wrote: post #61

Earlier quoted context omitted.

How do you keep your openapi spec up to date?

Not the user you were asking, but the way we do it is that the OpenAPI/Swagger spec is auto-generated from server-side code (a C# .NET app with the ABP framework) during the CI build, and that is then used to auto-generate an API client (via swagger-typescript-api) which is what the frontend app uses. When the backend team makes some changes, they notify the front-end team which then runs the auto-generation script,…

Nice!

Why not re-run the auto-generation script automatically?

Post reply on HN