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

91–100 of 164 posts

Re: Practical Front-End Architecture

#91

Post by blunte »

vagrantJin wrote: post #53
blunte wrote: post #7

Earlier quoted context omitted.

I'm in the same boat. But I don't think there's a lack of good info, but rather there's too much info and too many variants and options. There are probably many "correct" choices in the beginning, but we naturally want the good beginning and good long term maintainability/extendability. Rails without a JS frontend is excellent in so many cases. The trap is when you start adding a little JS here and there to make thin…

> What I'm hoping for is a configurator/wizard where you can choose your options, and then you get a fully functioning foundational system to start from. Not sure if Yeoman is still around but did they not attempt something similar?

I know it has been attempted many times. But like the general problem of too many options, it doesn't gain enough attention and develop a critical mass.

And in the case of setup tools, they tend to all suffer from the problem of being very difficult to change once setup. The tool you use to build the customized foundation is often unable to make future modifications if you have changed any of the generated code.

But by now we know the 99% common options people want: a choice of a few databases, (probably but optional) user profiles and auth, etc. The database side is pretty much solved, but the user management is definitely not - and it's the source of so many data leaks.

Re: Practical Front-End Architecture

#92

Post by brundolf »

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…

We use Apollo at my new company and I have mixed feelings on GQL so far, but I asked HN about it and lots of people had positive anecdotes: https://news.ycombinator.com/item?id=28488259

Re: Practical Front-End Architecture

#93

Post by brundolf »

karolisram wrote: post #82
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.

I've been doing web dev for almost 10 years and I've been extremely impressed with Next recently; I think it's the most "practical" framework out there right now assuming you're not wanting to go 100% client-side or 100% static-rendered (you can do each of those on their own very easily without it). The way it lets you mix both, as well as server-rendered where needed, is a game-changer.

I'm more ambivalent on Apollo/GraphQL, but I know some people have been happy with the decision to use it

Re: Practical Front-End Architecture

#94

Post by drewpc »

Not the OP nor the post's author. We have a similar stack (React + NextJS + TypeScript + Mobx) but use a traditional REST API using Django Rest Framework. There are some interesting topics in the post and in these comments that I figured I could expand on:

1. The primary reason we chose NextJS (with SSR) was to be able to write a declarative React component that is run on the server and the client. For example a button to follow or unfollow a page (think: like/unlike in social media). In the previous generation of our application, we wrote the button in PHP that rendered HTML and toggled UI state on the front end using JS/jQuery. That meant writing the button logic (and HTML/CSS) in two places instead of one. Now, we have a single React component that renders itself based on state; it's the same component on the server and client.

2. I don't understand the extra work to avoid SSR. SSR is great and can be used behind authentication--there's no actual need to work around it. Additionally, in a NextJS application, SSR is only used on the first page load. When you click from page to page, it's all client-side transitions.

3. @yashap said "The FE stack at my current co. is React, MobX and TypeScript, powered by REST APIs that are well documented via OAS. It’s a very nice, easy to learn and maintain stack." Agreed. Same here. It's wonderful. In particular Mobx. A lot of the comments seem to say "I expected the article to talk about how to maintain state in a React application"--that's how. Use Mobx. No matter what reactive JS framework you're using, use Mobx to maintain "global" state.

4. The discussion of "why move to NextJS when my Webpack config from 6 years ago works just fine" is a good one. Two big reasons we moved to NextJS (away from a Webpack config from 7 years ago) were: the handoff from server -> client is more seamless and the developer experience with hot module reload for server + client sides was worth it. Any JS application these days is going to be a tooling nightmare: Webpack, Babel, TypeScript, ESlint, React, polyfills, plugins, and then dependencies. That's awful no matter what JS framework you choose. Create React App doesn't fix that, it just hides it for the first step of creating a react application. You still have to maintain all that nonsense.

Re: Practical Front-End Architecture

#95

Post by jaredgorski »

bern4444 wrote: post #88
jaredgorski wrote: post #73

Earlier quoted context omitted.

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…

I see what you mean.

By way of clarification, I see route validation and pageload validation as potentially separate. For example, a given route parameter may govern a whole scope of pages in the app, so it makes sense to centralize that route validation logic rather than duplicate it in each page’s validation hook. In a more traditional server (like Express), we can just handle requests which contain that route parameter with a particular middleware function that validates the route. However, if we’re just using Next.js’ filesystem router, we have to add validation in the component tree, in a wrapping component. You’re right that we could make a HOC, but then we would either need to apply it to each page file in that directory or just put it in the App render as a wrapping component, which is what we elected to do.

On the other hand, an individual page may need to run some specific logic to validate that particular load. That’s where the page validation hook comes in. We have a centralized permissions spec in the runtime which contains fallback rules for each page, so we can just update the “abort” callback with each route change so that the page can just bail out of the pageload and redirect the client appropriately.

Re: Practical Front-End Architecture

#96

Post by andrewingram »

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

I've mostly used the Relay examples as a starting point, though they've generally need to be fixed up to avoid some bugs. In the olden days of getInitialProps (still available as an API, but its use isn't actively encouraged) things were easier and more elegant, getServerSideProps and getStaticProps both force things to be a little uglier.

For my older (getInitialProps) approach, you can see a rough example here: https://gist.github.com/AndrewIngram/e974f63160af9df292fc39e...

Look at the last file (PostDetail.jsx) to see what it's like using GraphQL as part of a page (PostLayout isn't defined here, but assume it's just a regular React component using Relay's useFragment hook).

Re: Practical Front-End Architecture

#97

Post by Scarbutt »

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…

For example, Ikea for product lists sends mini chunks of simple HTML. No JS involved.

Can you elaborate how? like some turbolinks thing?

Re: Practical Front-End Architecture

#98

Post by billoshoes »

brundolf wrote: post #92
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…

We use Apollo at my new company and I have mixed feelings on GQL so far, but I asked HN about it and lots of people had positive anecdotes: https://news.ycombinator.com/item?id=28488259

Do you have any examples of JWT refresh token auth for Apollo? I'm having an absolute nightmare figuring it out

Re: Practical Front-End Architecture

#99

Post by brundolf »

billoshoes wrote: post #98
brundolf wrote: post #92

Earlier quoted context omitted.

We use Apollo at my new company and I have mixed feelings on GQL so far, but I asked HN about it and lots of people had positive anecdotes: https://news.ycombinator.com/item?id=28488259

Do you have any examples of JWT refresh token auth for Apollo? I'm having an absolute nightmare figuring it out

Sorry, that stuff was already set up when I got here

Re: Practical Front-End Architecture

#100

Post by yuchi »

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.

Sorry to be the “actually…” guy here, but actually… what the article describes is ISOMORPHIC server side rendering, which is very different from traditional SSR + client side dynamic behaviors.

The fact that the same code can render the initial static page AND the dynamic client interactive UI is the point here.

Post reply on HN