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

Server-side rendering is a better choice for many applications (2020)

timr.co

Post reply on HN
Print view View original

271–280 of 286 posts

Re: Server-side rendering is a better choice for many applications (2020)

#271

Post by water9 »

BackBlast wrote: post #109
water9 wrote: post #86

Earlier quoted context omitted.

SRS is more secure because it doesn’t send down any links a role can’t see including even the link to get-based access from the account. It’s hard to attack a surface that is small.

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unles…

We’re talking about where dynamic variables get populated either on the client side or the browser side. If you put invalid input, it doesn’t matter what side it gets surrendered on. Input validation and rendering are separate issues

Re: Server-side rendering is a better choice for many applications (2020)

#272

Post by water9 »

lolinder wrote: post #150
BackBlast wrote: post #109

Earlier quoted context omitted.

SSR has more potential for security issues because you're often rendering some set of data from your database, which may come from a user, out to a browser which will then parse and execute code based on that rendering. You have to be sure your data going into the database doesn't have XSS escapes or your rendering of untrustworthy data doesn't have such XSS escapes. Which is why you shouldn't roll your own SSR unles…

This isn't a difference between SSR and SPA, it's a difference between using a modern framework and rolling your own. If I get a user-provided string from the server as a JSON property and set it via `.innerHTML =`, I have an XSS vulnerability. If I use React's JSX string interpolation, I don't. If I get a user-provided string from a database and inject it with a PHP ` ` tag directly, I have an XSS vulnerability. If…

Except what happens when react as the vulnerability you get attacked with everybody else with zero days… security through obscurity should be incorporated into any well multilayer defense. Make it not worth their time

Re: Server-side rendering is a better choice for many applications (2020)

#273

Post by xnx »

Most "apps" don't need the level of front end interactivity that frameworks support. Simple forms and pages would make a lot of users happier. Apps that do justify heavy front-end interactivity (e.g. Google Docs, Slack, CAD tools) will probably move to techniques like canvas rendering and WASM.

Re: Server-side rendering is a better choice for many applications (2020)

#274

Post by mg »

msm_ wrote: post #259
mg wrote: post #102

Earlier quoted context omitted.

How is Django more heavy than Flask? When I think about heavy, I think about how hard it would be to replace the framework with my own code in the future. So I don't like magic. One thing that keeps me from investigating Flask further is that Django seems to be way more popular: https://trends.google.com/trends/explore?date=all&q=django%2... So it will probably stay around longer. Me and other devs maintain this repo…

>How is Django more heavy than Flask? Because it is, by far, much larger project? Django has 551k LoC in 31933 commits, Flask has 27k LoC in 5156 commits. Django philosophy is "be opinioated, and bundle everything necessary for developers". Flask philosophy is "do just one thing and just be a good HTTP server, let users pick a solution to all the other problems". Django is a full-blown framework, whereas flask is alm…

I don't mind so much about the LOC of a framework. If there is stuff in there that I don't use and that does not get in the way of me doing things, thats not that much of a problem.

As for Flask not going anywhere - well, all projects go down the drain at some point. Just 10 years ago, the Zend framework was more popular than Django and Flask combined:

https://trends.google.com/trends/explore?date=all&q=django%2...

Good point about the dependencies of the flask version. I did not write it.

If you like to write a pull request which gets rid of the flask-sqlalchemy and replaces it with pure SQL, I would love to see that.

Re: Server-side rendering is a better choice for many applications (2020)

#275

Post by zmxz »

water9 wrote: post #270
zmxz wrote: post #95

Earlier quoted context omitted.

SSR has nothing to do with roles being sent and what a user can see. It's as related as Jupiter is to a brick.

It has to do with the size of the attack surface. in order for things to be client side driven gui elements need to be loaded for different role types. Those elements are often exposed If not directly then by showing which APIs are used to Authorize access to admin areas. That’s the whole point of rendering on the client. To load some Little div you might have an API call that when access by different role types will…

Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true.

There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface.

The choices related to displaying appropriate elements based on current user's role that's tied to entire logic of the app has literally zero to do with security.

Re: Server-side rendering is a better choice for many applications (2020)

#276

Post by safety1st »

edanm wrote: post #110
safety1st wrote: post #97

Earlier quoted context omitted.

I wouldn't say server side rendering is a "Thiel Truth," because it's a thing that is already popular and uncontroversial and agreed upon by millions. There is an echo chamber where this happened: * Facing massive datacenter costs, Google and Meta realized that if they could hand off rendering to the client, they could have smaller datacenters and save a lot of money. Things like React and Angular were born. Other co…

This is very wrong. For one thing, I don't think the motivation of Google and Meta was datacenter costs, though I could be wrong about that. But it's not that "VCs were pushing client-side SPA", it's that lots of the companies that wanted to build applications, found that they had a set of problems that was best solved by things like Angular. The state of the art before that for highly interactive client-side apps wa…

> I don't think the motivation of Google and Meta was datacenter costs, though I could be wrong about that.

Have you forgotten that these are profit-maximizing companies? Why do you think they do anything? To maximize profits. That is always the answer. If it doesn't maximize profits it's a mistake and they will back away from it.

So for example Facebook either thought that React would increase sales, or reduce costs, otherwise they wouldn't have created it. React hasn't moved the sales needle for them (why would it - they are an advertising company - React has precious little to do with selling more advertising). Ergo it was created to reduce costs. The cost benefit of moving all that compute out to the client is easy to demonstrate and significant for a company of that size.

Re: Server-side rendering is a better choice for many applications (2020)

#277

Post by KronisLV »

la_fayette wrote: post #212
ninkendo wrote: post #115

One of the fastest, lowest latency websites I use is HN, and it’s entirely server rendered. It’s also a massively popular website with probably thousands of hits per minute. Anyone who tells you server side rendering is too slow, probably has no idea what they’re talking about.

To be clear, there is a difference between SSR and SSG. SSG is something like PHP, which generates the full page HTML in the backend. I think HN is SSG? Many news websites or wordpress blogs also fall in this category...

> To be clear, there is a difference between SSR and SSG.

Here's a simple way to think about it.

SSG: there will be a process that generates/bundles HTML/CSS/JS ahead of time with all of the content that the site will have, like the many static site generators out there.

You should then be able to take the output of the SSG process and host it on a dumb web server, like Apache/Nginx.

For example, that's what I do with my HN Personal Blogs site, a set of Python scripts generate HTML output a few times per day, which is then served on an Apache container: https://hn-blogs.kronis.dev/

SSR: there will be a runtime of some sort that will execute any number of scripts on the server, to dynamically generate a response for the user's request.

This is what many PHP and Ruby sites are, if they don't opt to just use those languages for an API. You click on a button in the site, your request is submitted, the language runs some logic on the server and sends you a response, typically there's a DB as well, that most users interact with.

However, you can also mix those approaches. For example, you could make it so that the front page of your site is pre-rendered or at least cached, so that your servers need to do less processing and your DB would be under less load.

That's also what some flat file CMSes like Grav do - so that the articles will load pretty quickly, though those approaches introduce some complexity and the risk of stale data in some cases.

There's also stuff like hydration and many more recent concepts, but that'd get more lengthy.

Re: Server-side rendering is a better choice for many applications (2020)

#278

Post by traverseda »

michaelmior wrote: post #219
traverseda wrote: post #216

Earlier quoted context omitted.

I've never heard the term SSG before. Apparently stands for "static site generating" and is a `next.js` thing. No, hacker news is not a static site. It just makes use of caching HTML on unchanged pages, and as I understand it that cache is often bypassed for logged in users. This is why sometimes when hackernews is overloaded you can still view the site in private browsing, since you're not logged in it hits the cach…

SSG long predates Next.js. It was by no means the first, but I wrote something that I think could be called a SSG (not the term I used at the time) back in 2010 while the first release of Next.js wasn't until 2016. [0] https://michael.mior.ca/blog/designing-an-offline-cms/

Sure, static html sites have existed forever, but I don't know when the term "SSG" was popularized. I assume it was pretty recently all things considered.

Re: Server-side rendering is a better choice for many applications (2020)

#279

Post by MatthiasPortzel »

icedchai wrote: post #228
MatthiasPortzel wrote: post #171

Earlier quoted context omitted.

Hitting the “Reply” button on HN takes you to a new page with a textbox, taking over 500ms and a complete page reload. On some websites, that amount of latency is acceptable. But that could be instantaneous.

Where are you located? It's about 120 ms here (wifi off of gigabit fiber, east coast US.) Based on ping time, over 60% of that time is network latency to the west coast. Actual "processing" would be in the 50 ms range which is super fast.

It may be <100ms, but that completely misses my point. My point is that it could be <1ms, and no reload, if the Reply box was added in JavaScript to the previous page.

Re: Server-side rendering is a better choice for many applications (2020)

#280

Post by water9 »

zmxz wrote: post #275
water9 wrote: post #270

Earlier quoted context omitted.

It has to do with the size of the attack surface. in order for things to be client side driven gui elements need to be loaded for different role types. Those elements are often exposed If not directly then by showing which APIs are used to Authorize access to admin areas. That’s the whole point of rendering on the client. To load some Little div you might have an API call that when access by different role types will…

Why would the elements HAVE to be loaded for different roles? You're talking as if every single client-side app approaches authorization and authentication the same way and that's just not true. There's no attack surface here at all, the only issue with most client-side apps and interaction with server comes from CORS and devs copypasting solutions from SO to get rid of the warning, thus creating the attack surface.…

Because the whole point of client, side rendering is to not have session management on the server side so that it uses less bandwidth on the server provider.. that’s why you have JWTs and stuff like that. Architecturally when you have a session management system, where state is able to be maintained per user usually up by the same thread on the same physical server. that’s going to be more secure than a horizontally structured infinitely scalable system. But there’s always trade-off between security and usability/performance
Post reply on HN