16 ms·
SPAs Are Dead?
- stepbeek 6y agoMaybe I'm missing something, but this seems like a very narrow definition of SPA. A SPA can just sit on a different path from the API server and cross-site cookies aren't a problem. For instance, www.example.com/app and www.example.com/api
- weird-eye-issue 6y agoThis is how I prefer to do it. No CORS pre-flight requests and messing with CORS settings
- yitianjian 6y agoSeconding (thirding?) this. I'm curious, are there any SPAs that aren't done this way?
- weird-eye-issue 6y agoYes there are a ton. Actually it was a bit of a pain setting it up that way. I'm using Cloudflare to dynamically route to S3 or an ALB based on the path. If Cloudflare didn't have that option I would have had to roll my own solution to defeat CORS which could have added in another point of failure Edit: I meant Cloudfront. I do that a lot
- beckingz 6y agoapp.example.com vs api.example.com ?
- true_religion 6y agoSure I've done that but only for SPAs that are totally anonymous, and deploy the api.example.com behind a CDN cache.
- slowmovintarget 6y agoThe article is referring to all the myriad other things an SPA will bring in. Analytics, feedback components, interactive galleries, notification components, header components... you can sew a site together from SaaS components that all live in different domains. Well... you could. Harder now. From the article: > So are SPAs dead? Well – SPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.
- preommr 6y agoI have my backend on a different subdomain instead of a subdirectory because it solves issues at the dns level. This means I don't have to deal with setting up a reverse proxy or separate rules for cloudflare. This applies not only to production but also for local testing. I used to have a reverse proxy for local development. Moreover it gives you better security by default since different backends are now treated as different origins, so same-orign-policy, and same-site (for cookies) kicks in.
- weird-eye-issue 6y agoYeah I used rules in Cloudfront for this. Only have one API backend so security doesn't really factor into this much. Actually I consider it slightly more secure because there was no way for me to misconfigure CORS.
- preommr 6y ago> there was no way for me to misconfigure CORS. This is a pretty big issue because there are a shit tonne of bad resources that poorly explain CORS - so many places just slap a wild card in 'access-control-allow-origin', and call it a day. Even a lot of the framework middleware can be confusing and unhelpful. FWIW, once I actually got it setup, it was very simple, very easy. I highly recommend MDN's CORS page[1] as the only source someone should read, and to read the whole thing to actually learn it rather than just grabbing a library to solve the problem in 15 minutes. Even then, I had to start with a small test project and test things at different levels to understand what a library would be doing. My back end is golang, and I used gorilla/mux, so I did things step by step to really know what was working and what wasn't. I've done it other ways with something like Spring boot and libraries where it's just a goddamn mess because it tries to automate too much for you and it becomes way too confusing. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS
- dragonwriter 6y ago> I’m curious, are there any SPAs that aren’t done this way? For…enterprise reasons…the SPAs I’ve worked on in $DAYJOB use apis hosted in a separate subdomain (and, therefore, origin) than the page itself, meaning we have all the CORS headaches. But, certainly, segregating by path rather than domain is a lot more convenient if you control both the page and the APIs it consumes.
- billti 6y agoThat's what I moved our stuff too, because it was just easier for a number of reasons (cookies and CORS stuff being amongst them). Any calls to other domains are done through the API hosting on the site domain. He does allude to that at the end of the post though: "So are SPAs dead? ... SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes.". That is a narrower definition though.
- tshaddox 6y agoIndeed, the intended audience seems to developers of SPAs which only use third-party authentication and data. The article even mentions "pretty much every authentication protocol – like SAML, WS-Fed and OpenID Connect." I'm obviously not in this intended audience, because in my experience this is an extremely niche SPA use case. I can't even think of a website that does this or would want to do this. Maybe if you want to build a third-party web client for something like Gmail or Apple Music?
- stepbeek 6y agoIn enterprise environments, I can see that being a problem. Tools like SAML are more prevalent when SSO is used.
- timw4mail 6y agoCookies suck. The interface is beyond terrible, they were never scoped properly, and they don't have to be used. Browser storage (sessionStorage, localStorage) is perfectly valid for storing an authentication token.
- kostarelo 6y agoBy interface you mean.. the HTTP protocol? At least they can be scoped on the domain level. Browser storage can't.
- leipert 6y agoLocal storage and Session Storage are scoped per origin as well: https://developer.mozilla.org/en-US/docs/Glossary/Origin https://developer.mozilla.org/en-US/docs/Glossary/Origin
- pmlnr 6y agoorigin != domain level. See https://publicsuffix.org/list/public_suffix_list.dat https://publicsuffix.org/list/public_suffix_list.dat
- wdb 6y agoGot to admit I only learned about this because of the Github Private Page item posted earlier on HN. I still not clear what this list does or tries to do. Can't find much about it on MDN. Need to do a bit more digging
- kadfak 6y agoLeaking your auth tokens through XSS sucks more.
- leipert 6y agoI don’t know whether you are referring to only local and session storage being feasible or not, but on can access cookies from JS as well.
- tus88 6y agoHow do people bridge the SPA/ORM gap, when no such gap exists in serverside rendering?
- paxys 6y agoSounds like an overreaction. The only thing affected by the browser changes is some third party authentication mechanisms, and those can be easily fixed (as mentioned in the article itself).
- pier25 6y agoI prefer using cookies, but most SPAs actually use JWTs.
- jakelazaroff 6y agoCookies and JWTs are not alternatives to each other. You can store a JWT in a cookie.
- shock-value 6y agoYou can also store a JWT in localStorage and require an additional secure signature for it within a cookie (http-only). Best of both worlds.
- ivoecpereira 6y agoIf doing that, why not go full-mode and store JWT in cookie with http-only flag?
- shock-value 6y agoThere are good uses for page content to know what's in the JWT (display username, show logged-in status, etc). Cookies also have stricter size limits. Additionally, cookies by themselves are uniquely vulnerable to CSRF, although I guess these days using SameSite property correctly mitigates that.
- jakelazaroff 6y agoYou can prevent CSRF attacks by simply requiring a custom HTTP header: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html#use-of-custom-request-headers https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Re...
- pier25 6y agoTrue, although in the vast majority of cases JWTs are sent via HTTP headers (specially if you're making requests to multiple domains).
- rory 6y agoThe general trend here seems that browser security improvements are more likely to kill core-function-of-your-app-as-a-service type software products, rather than SPAs in general or in particular.
- ngrilly 6y agoI don’t like the click bait title, but the conclusion is interesting.
- deleted 6y ago[deleted]
- jessaustin 6y agoSPAs as in the UI/UX concept certainly not. SPAs as in “browser-based standalone applications that do cross-site authentication and API calls in the context of a modern identity and SSO architectures” – yes. Has the latter ever been a definition of "SPA"? One would have thought the acronym "single page application" to have been fairly precise...
- shortlived 6y agoSounds like JAM stack to me
- andrewstuart2 6y agoAnd the latter is not even true unless I missed something significant. It's just lazy implementations thereof that are dead. Having developed SPAs for much of my career, I did plenty of cross-site login and work never realizing third party cookies were even an option. I just figured they were bad practice and that oauth2, understanding the limitations of web frontend oauth2 security (e.g. can't really do a full authenticated client without a backend to keep secret the client secret), and using proper CORS was the right way to do it. I think that's the way forward with the removal of third party cookies, is it not? I guess I'm more surprised that somebody was using third party cookies for non-tracking purposes than I am surprised they're being removed. > Some people recommend replacing silent renew with refresh tokens. This is dangerous advice – even if your token service has implemented countermeasures. If I follow the link the author is clearly talking about public clients, which are always going to have significant security limitations. Somewhere else on the site he mentions BFF (backend for frontend) architecture as a mitigation. Which I kinda thought was the whole point of confidential vs public oauth2. The spec is super clear that public is less secure which is just the nature of security; if you have to ship a secret to someone who shouldn't know it, but they need to use it, you're kinda out of luck. I think I'm picking up that the author's definition of SPA is also assuming no back-end, in which case many of the security points make a lot more sense. But even if you just throw out a secure authenticating proxy, which can be done with very little code and a few off-the-shelf and OSS products, you're back in business and more secure than ever.
- throwaway185205 6y ago
- arendtio 6y agoWhat the article completely ignores, is the fact, that building cross site apps has been next to impossible for a long time. Since you can't contact a server who doesn't explicitly allows connections via CORS, your browser based app doomed. And I write this as someone who would love to build apps all day with web technologies.
- kreetx 6y agoI don't quite get what you mean. If the cross-origin server (to your app) wants to be consumed then it will respond with the correct headers. And if the server is under your control then you can configure it so.
- zyemuzu 6y agoThis. I suppose that's what has me confused about both the blog post and comment, i.e. why would you not control your servers?
- kreetx 6y agoNot entirely sure what parent meant but it seems that many web developers are still confused as to why they can't consume any site on the internet from the front end.
- arendtio 6y agoBecause that is actually the classical pattern of applications using the internet ;-) The whole point of internet protocols like HTTP, SMTP and the likes is about not having control over the server and being able to let programs talk to each other anyway. So if you want to build a classic client app it would be independent from the server implementation. So maybe it would even be 'your' that you would use. For example you could built an app that could talk to a Dropbox server. But with the current SOP setup you would require Dropbox to configure their CORS accordingly.
- arendtio 6y agoFor non-browser apps the server doesn't have to explicitly allow it. A simple curl can access any server it wants. If y browser based apps wants to access another server, that server needs to be configured to allow it (because of the Same Origin Policy) and how many servers do you know that allow anybody to access them via CORS? So take for example a WebDAV server. In theory, you could build a web based app, that can access any WebDAV server out there on the internet. In practice, that WebDAV server requires a special CORS configuration in order to be accessible via a browser from a different origin. Any other normal desktop app doesn't care about CORS and can access any server it has credentials for, no matter what configuration it has.
- sly010 6y agoWhat the author describes was never a good idea anyway imho. We will just have to learn to point a subdomain to third party servers.
- echelon 6y agoOr services we integrate with will have to start emitting the correct headers.
- _nhh 6y agoI am currently involved in a app development where a single code base is deployed to several platforms. Cors is being a topic for the last two month. I am increasingly concerned about the future of javascript webapps and its build targets like cordova/capacitor/electron because there is no single cors configuration which fits all build targets :(
- hawski 6y agoI hoped that designers learned something and decided to stop the war against their users. I did not hold my breath. To clarify I have nothing against actual web applications like an image editor or a game. However a wiki (I don't appreciate Notion), an online shop or a damned blog should not be one. I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended.
- tomComb 6y agoI want all those things too, but not clear on how you think notion should be implemented. I use it exclusively in the browser on a laptop. I find it slow but I do not think that is the fault of browser tech or SPA architecture, and I assume it will get addressed.
- jmkni 6y ago> I want my history, link copying, bookmarking, middle-clicks and Ctrl/Cmd-clicks to work as intended. In a well designed SPA, these will all work.
- hawski 6y agoIt's like with C or C++. Most people that do write it shouldn't, because they are not good enough or the process is broken and they will shoot their leg. SPAs are the same way, because you have to implement all those normal website things again by yourself. There will be casualties.
- jinushaun 6y agoExactly, the problem is that you don’t get these baseline features for free. SPA, in my experience, is a lot of people poorly reimplementing the wheel.
- adrr 6y agoThey work perfectly fine under a SPA. SPA pushes history which lets the back button work and you can bookmark the URls. They have real URLs so you can create tabs. Go look at https://www.target.com/ https://www.target.com/ and see if you can tell difference between SPA and regular web page except for the speed aspect.
- gibsonf1 6y agoI think SPA's are alive and well using the Solid project [1] with Inrupt's auth library[2] that supports Open ID Connect PKCE with dpop tokens. [1] https://solidproject.org/ https://solidproject.org/ [2] https://github.com/inrupt/solid-client-authn-js https://github.com/inrupt/solid-client-authn-js
- austincheney 6y agoA better way to think about it: Who wants SPAs more, UI developers or their users? If the demands of the developers out pace the demands of their users AND those demands primarily determine product design decisions the product is not all designed to benefit the user despite developers pleadings to the contrary. That is a very pronounced example of bias.
- CivBase 6y agoUsers just want pages to load fast. UI developers (presumably) just want to maximize user happiness. A SPA is just a way to front-load resources for a website so users don't have to re-load redundant resources for each new page. Whether that is actually worthwhile for the user depends largely on how many redundant resources a site has and how many pages a user is likely to request in a single session. SPAs are a situationally useful tech just like blockchain, machine learning, JS component frameworks, etc.
- austincheney 6y agoIt’s hard to know what users want if those wants are assumed, which serves to reinforce bias.
- takeda 6y agoWhy authors of these blog posts assume that everyone know what the context is? Even if one assume the term is related to computing and technology, there's 4 different things named SPA. Is it that hard to expand the term in the title or in the beginning of the blog to help people quickly decide if they are interested in it or not? Sorry for the rant, but this is not the first time the article forced me to read it before I could decide if I'm interested in it.
- jeppebemad 6y agoTo be fair, most of the blogposts are not written for us on HN, but for the followers of the blog in question. I do not mind having to figure out the context, if it means I get to explore the esoteric and far corners of the internet from one place :)
- astro_sloth 6y agoLong live the SPAs.
- maxharris 6y agoI did web dev professionally for seven years until I started writing Swift a year ago. The learning curve for native iOS development is a little steep because Apple doesn't write adequate documentation, but resulting application delivers a superb user experience with extremely low power consumption. Web apps and APIs are not the answer to the biggest problem we have today, which is the lack of open alternatives to Apple's App Store and Google's Play Store. While it is true that Apple cripples their browser to make web apps second-class citizens, browsers will always add a layer of indirection. Even if the performance loss were made negligible, it would encourage the creation of user interfaces that target the lowest common denominator available on all platforms. In my opinion, the best way to fix this situation in the long-run is to design completely open mobile devices. I'd love to replace my iPhone and iPad with devices that are repairable and run a mobile-optimized version of Haiku. We're not as far off from that as you might think; metal 3D printers such as the Markforged Metal X will make it easier and cheaper than ever to make cases that turn a pile of parts into a working phone. What does this have to do with web apps? Well, if you're spending all your time keeping up with web development, perhaps it's time to learn some new skills and push things forward in a different direction.
- pgt 6y agoThe Web After Tomorrow by Nikita Tonsky: https://tonsky.me/blog/the-web-after-tomorrow/ https://tonsky.me/blog/the-web-after-tomorrow/