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

Advice to Young Web Developers

tumblr.beesbuzz.biz

Post reply on HN
Print view View original

221–230 of 328 posts

Re: Advice to Young Web Developers

#221

Post by tdeck »

davnicwil wrote: post #213
tdeck wrote: post #176

Earlier quoted context omitted.

This misses the part where with an SPA I have to figure out what data and access patterns my frontend code is going to want, define an API+schema for the frontend-backend interactions, and (often) write data validation on both the frontend and the backend - all this in addition to the data definition I would have to do on the backend in any case. If I'm able to render things from the backend, I just have to query the…

Curious what you mean by the API flexibility Vs security point. To me, the API for a SPA is just another view over the exact same data that would be accessible in the HTML output of a server render (which, indeed, is the 4th point in the article). Your access to that data is gated by a cookie with a token in it in both cases. On the code level, it's really not all that different - the operations you perform 'directly…

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query endpoint to the client and never have to think about APIs again.

Instead I have to figure out what data access patterns my frontend will need and implement those, along with whatever visibility restrictions are required. I'm forced to do the former in the backend (as well as the frontend) because the latter can only be done in the backend.

(Aside: I realize that back in the day people did indeed use database mechanisms like DB users and stored procedures to do what I describe, and then client apps connected directly to the database. But this practice seems to have faxed and isn't readily doable on the web anyway).

Re: Advice to Young Web Developers

#222

Post by imtringued »

jkachmar wrote: post #198
RNCTX wrote: post #156

Earlier quoted context omitted.

https://github.com/steve-chavez?tab=overview&from=2016-10-01... https://github.com/begriffs?tab=overview&from=2016-10-01&to=... How many projects are there to automatically API-ify a database with auth boilerplate today? At least a few well funded ones, one recently funded by YC even. They came up with it in 2015? 2016? and still have a thriving project going with it. Looks like less than 10 people have more than 10…

Having followed the PostgREST project for years, it’s been wild to see the recent explosion of similar sorts of projects (as you describe); I’d very much believed this was a “solved problem”.

CouchDB is a database from 2005 that can _only_ be accessed via a REST api.

Re: Advice to Young Web Developers

#223

Post by catwell »

stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

> If you have the option of writing an SPA, it's simpler quicker to build this way, and so easy to deploy.

It's simpler if you only write the front-end, because it de-couples the work with the back-end.

If you are in charge of both front-end and back-end, server-side rendering is easier.

It's a case of Conway's Law. Knowing that, you may choose to have a back-end team and a front-end team or a team of full stack developers depending on the end result you want.

Personally I think it depends on whether the Web is just another client for you, which consumes APIs like native applications, or if your product is entirely web-based.

Re: Advice to Young Web Developers

#224

Post by arkis22 »

em-bee wrote: post #204
arkis22 wrote: post #189

Earlier quoted context omitted.

Loose is a word that describes knots. You are obviously writing more code for client side HTML generation based on JSON than regular server side rendering... I am saving effort if I need to write fewer files... Your feature requires a JSON route, html rendering, and javascript that pulls everything together. Mine is just a route that returns HTML. Why is there absolutely no difference in effort? You have 3 files, I h…

we won't be able to answer this without specifically comparing framework by framework. some frameworks make your code more complex, some help keep it simple. i have used different backend and frontend frameworks, and i found that backend frameworks do not make things simpler in the sense that you are talking about, if you want to create clean and maintainable code. sure you can put everything in one file, but the num…

yikes, please link frameworks that make your code more difficult.

Re: Advice to Young Web Developers

#225

Post by zelphirkalt »

stevage wrote: post #162

As a web developer, I frequently see these posts about how we should write (or at least transpile to) HTML because it's so much simpler, and the browsers can render it so fast, and it's the right thing to do etc etc. But they all miss the point: writing with client-side JS based frameworks (React, Vue, whatever) is easier, faster, more versatile. If you have the option of writing an SPA, it's simpler quicker to build…

> Server-side rendering or writing raw HTML are over-rated.

Just to be sure: These two are not the same and server-side rendering does not necessitate writing raw HTML. In fact, I think that most advanced languages used on the server-side have means of not writing raw HTML. There are template engines and some languages offer SXML, which already provides you with a kind of template engine.

Personal opinion: I really don't like having to write raw HTML in form of it being just a string, allowing for all kinds of markup issues, formatting issues etc. A programming language or used framework/library should have awareness of the HTML tags and prevent mistakes. SXML prevents mistakes in nesting for example. In Racket and I think in Scheme dialects as well, SXML prevents cross-site scripting by design as well. What many many people get wrong is how they split up their documents. They forget about composability and use only concatenation (looking at you, wordpress themes ...). This severely limits reuse of code. Good templating languages try to nudge you into the direction of making things composable.

Re: Advice to Young Web Developers

#226

Post by bryanrasmussen »

bigiain wrote: post #203
haecceity wrote: post #185

Earlier quoted context omitted.

I think only developers care about rendering speed like that. Most people are happy if the page loads in reasonable amount of time. UX people probably know what that means exactly.

What do you base that thinking on? Amazon, Google, Walmart, Mozilla, and Yahoo all have numbers that say otherwise. "Amazon and others found that removing 100 milliseconds of latency improves sales by 1%." I'm 100% sure there are people who care about 1% differences in sales, and the fact that has been rediscovered independently by different organisations shows that "people" at least "aren't happy" with very small in…

a 1% increase in sales and most people not caring are not definitely incompatible viewpoints.

That said I am definitely one of the people for whom it does matter.

Re: Advice to Young Web Developers

#227

Post by davnicwil »

tdeck wrote: post #221
davnicwil wrote: post #213

Earlier quoted context omitted.

Curious what you mean by the API flexibility Vs security point. To me, the API for a SPA is just another view over the exact same data that would be accessible in the HTML output of a server render (which, indeed, is the 4th point in the article). Your access to that data is gated by a cookie with a token in it in both cases. On the code level, it's really not all that different - the operations you perform 'directly…

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query…

> "client should only be able to query objects the user account has access to"

> "client should only be able to perform certain kinds of transactions and mutations"

The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}.

The answer to the question 'how do you know who the user is when they request a server rendered page containing some sensitive data?' is literally the copy/paste solution to how to do authentication on your API - as in, it's basically the same code that must be implemented on the backend in either case :-)

The point is it's the same data and mutations, just a different interface over them. There is no security tradeoff of using one over the other.

Re: Advice to Young Web Developers

#228

Post by [deleted] »

black3r wrote: post #214
speedgoose wrote: post #37

Earlier quoted context omitted.

Safari on iOs is a bit special. Some features are missing compared to the Mac version. You also need quite a few safari ios specific code if you want to build a web app. But this is a bit broken since Apple wants you to publish to the appstore and not release web apps anymore. You also need a Mac to debug safari on iOs. I hate Safari.

You don't need a mac to debug safari on iOS. There is remotedebug-ios-webkit-adapter. You need a Mac to debug Safari on Mac. Maybe that's the reason why some people only support Safari on iOS.

[deleted]

Re: Advice to Young Web Developers

#229

Post by martopix »

3131s wrote: post #173
jjoonathan wrote: post #61

Earlier quoted context omitted.

It's so sad that it became "acceptable" to not test in Firefox (as estimated by the number of sites I randomly encounter that don't work in FF but do in Chrome) right around the time that Firefox Quantum happened and Firefox became good again :(

Firefox must have performed poorly on Windows / MacOS in the past, because Firefox on Linux was never actually that bad. I've used Firefox for 15+ years now and never had the problems that people talk about.

I've also exclusively used firefox on Mac all my life and it's totally fine.

Re: Advice to Young Web Developers

#230

Post by beachy »

davnicwil wrote: post #227
tdeck wrote: post #221

Earlier quoted context omitted.

By security I mean pretty basic things like "client should only be able to query objects the user account has access to" and "client should only be able to perform certain kinds of transactions and mutations". On the back end that's not too tedious - just make sure I only query for what I want. But with a SPA I can't just assume the client will make only the "right" queries, otherwise I could just expose a SQL query…

> "client should only be able to query objects the user account has access to" > "client should only be able to perform certain kinds of transactions and mutations" The solution to these is equal for server rendered HTML containing {data} or an API just getting {data} in raw form - the request contains an access token which identifies and authorises the user - same goes for mutations on {data}. The answer to the ques…

> it's basically the same code that must be implemented on the backend in either case :-)

No, it's not. If I expose an API e.g GET /widgets,I need to ensure that there is no combination of parameters that will ever return a widget that the user should not see (e.g because it belongs to some other department).

Whereas when I render a web page server side, I just need to write a single, correct, SQL statement that pulls in the widgets that this specific web page requires.

Post reply on HN