How to Hack APIs in 2021
labs.detectify.com
labs.detectify.com
This isn't my experience at all, especially when network conditions are not great. The browsers has error handling and a progress bar. Single page web applications often have bad or no error handling and you have no idea if the request failed, the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage.
- Works terrible in bad networks.
- And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue.
Thats just bad design.
Reactive libraries/frameworks don't explicitly make this worse or better, except their presence implies a high chance of dynamic loading and, therefore, more opportunity for bad design. In addition most component libraries fail to communicate /who/ needs to size a component and if it is ever dynamic. It really doesn't help that most 'official' examples fail to resolve these issues.
> Works terrible in bad networks
Yes, software traditionally works shitty under bad network conditions unless the developer actively tests under bad network conditions or has previous experience of handling bad network conditions. This is as much true for anything developed ever that touches a network.
> the shifting of images
This is simply developers missing to add width and height attributes to their <img/> elements. This has been happening since the dawn of the <img/> element and is unlikely to disappear. Also has nothing to do with SPAs, same happens with server-rendered HTML.
That's the whole thing. SPA = state. It requires a lot of dev time to properly handle everything. With stateless applications, you can simply refresh your browser.
The sluggishness is not only because of bad network conditions, but it's multiplied by the huge application that has to be sent over the network, application initialization, and the many subsequent network requests.
A "huge" application can be broken up with code splitting/dynamic imports. Initialisation can be seeded with serverside data or saved in browser storage between pages.
The only semi-unavoidable part is the "subsequent network requests", but even these can be sped up with caching, batching, etc.
> It requires a lot of dev time to properly handle everything.
But yeah, these things take effort
But if you take everything into account, you can also develop a really good native app.
This is not reality.
not everything is equally affected by bad network conditions, SPAs generally are very badly affected by bad network conditions, indeed what is a bad network condition for an SPA might be acceptable for a traditional static page.
A SPA's network dependency or robustness totally depends on the product's design. Some types of applications lend well to offline first (anything where the user owns their content/data, todo, notes, documents, pictures, etc). Others are much more dependent on fresh data. Which pretty much means anything big enough it's unreasonable to replicate it to the device.
I'm a fan of "offline first" design and have been a proponent at various companies. To the point where I can build the feature in at very little additional cost if it is considered and decided in the design phase. Bolt-ons patterns are messy.
However, the reality is that very few customers see this as a significant advantage. Which means that it doesn't really translate to market success. If budget is the #1 priority I can't in good conscience advocate for offline first unless it's going to offer a significant win for the company somewhere.
There is a Chrome-only local file system API.
Generally SPAs are limited to browser provided storage like IndexedDB.
This has been easy to implement for as long as I can remember, so not sure why'd you say it's terrible. What stopped you previous times?
Can't stand "<bla />" though with that pointless/clueless space. The only place where I've encountered these are older JSP, FreeMarker, or Thymeleaf/Spring MVC apps (ugh).
So much truth, not once I was trying to click on some image that had link underneath, and it suddenly moved to some other place and I ended clicking something different.
Switching off JS/fingerprinting doesn't really help either since it'll just disproportionally benefit Google's stronghold on web analytics even more.
The bigger issue, which seems to be what you are complaining about seems to be the gaping hole in privacy provided by 3rd party storage/resources. That is not a particular problem with SPAs, and can even be exploited without JavaScript.
I'm not sure where you're coming from regarding Google and web analytics. When 3rd party storage is gone (or partitioned) it sounds like everyone would be on the same page in terms of what data they can collect.
That could be said for a lot of assumptions developers make. Everyone has 32GB of ram, everyone has an SSD, everyone has an i7...
It is an old problem, but like almost everything else in computing for some reason it seems to have become much worse since about 2010.
In 2000 a developer might have been developing on a Pentium 3 with 128 MB of RAM, but they could reasonably expect their audience to be using at least a 486 with 16 MB of RAM because that was the minimum spec for IE4.
Now you're stuck with trying to impress people with a Ryzen Threadripper and 64GB of DDR5, but your webapp still has to support everyone's iPhone 7 (with 2GB to share with iOS and everything else they have running) for as long as Apple does.
Apple supports (at least security wise) probably more devices than you think.
Maybe it's a process problem, not a developer problem. Like management prioritizes a dozen analytics trackers and ad partners without any tooling for performance testing on a range of devices.
On the developer end (as a developer myself) we definitely deserve some of the blame for embracing things like Electron with such zeal in my opinion. I don't care how much memory a developer's workstation has, there's still a lot of hardware in use that can't take the bloat. I'm not saying everything has to be a native app written in vi against an original print of The C Programming Language as Brian Kernighan and Dennis Ritchie wrote it in 1978 or it's automatically shit, but something like React Native for the desktop would be far less horrible in terms of resource usage I reckon.
Or for free software, chances are it is add supported. So push as many ads and trackers until the churn rate gets too high or competitors take market share.
Or more generally, maybe the design just follows the money.
It's not the developers' job to assume anything about users. It's the project managers'.
Not to mention that some SPA doesn't maintain state, and all the sudden one need to jump through the the process all over again. Personally SPA seems to try reimplement a lot of browser feature all over again in client side JS.
You scroll and scroll, and scroll, and every time you reach some level "down", another section is loaded, then at one moment it stops. Something somewhere fails, no more new sections, no way to continue from that point, only a full refresh and a huge scroll down.
A flawless SPA backed by a flawless API that produces responses in tens of milliseconds is superior to the old ways.
But a trash SPA backed by an API that produces responses eventually if ever and requires me to open the browser's developer tools to find out what happened? You can keep it. Old-school frameset sites are better than that.
I know it's nitpicking and not the point of the article, but I don't think that's true. APIs have become commonplace because of the rise of mobile apps, that need one to talk to the back end. SPAs are in turn a response to the universality of APIs, because single page apps let you handle the browser as one more of those N clients, and avoid maintaining dofferent points of entrance to your backend.
I bring this point up because people seem to hate SPAs (usually for good reasons) and it's important to realize the problem they're solving. Better handling of complex client side logic and the like, which are usually pointed at as the main benefits of SPAs, are usually just an afterthought by companies, since the percentage of SPAs that reach a level of complexity where that's an issue is relatively quite low.
We ran it as an exercise at work to learn about security vulnerabilities, and it was great fun and highly educational. Really recommend it.
How much time did it take? (for one person to do it)
We did a write-up on our blog if you're interested: https://purplelabs.eagleeye.com/blog/the-hackathon-capture-t...
To me it looks like we are increasing the surface area for a attack - again this is a hunch, a kind of smell test.
But I also see that react etc are running away with all job offers.
There's nothing inherent about that. You can design a server rendered site using only generic data-driven pages, and you can design an SPA API with a concrete interaction model. But, for some reason, people tend to not do those.
In an SPA, we call the API to fetch x, y, & z to render it. In an MPA, we query the database to fetch x, y, & z to render it.
Since the query to the database is entirely server side, it does not need to be locked down in the same way that the API does.
Mentally, it's a lot easier to look at the /admin/orders page and say "should this user be able to see all this data that I can see is visible?". It's a lot harder to wrap your head around all the myriad ways that someone might call the API, and understand whether you've let anything slip through. With the MPA, those items that shouldn't be there should be pretty obvious, just by looking at the page and seeing what data is visible.
For an MPA, the data available to the client is all and only what is rendered on a page. For an SPA, it's all and only what is available through the API. You'll be looking at rendered pages frequently as you develop, but you will rarely (never?) be looking at the full possible output of the API.
Some people will lock down which queries can be called against the API in production. This can mitigate some of the issues here, and is probably good practice for websites that aren't intending to make their API available directly. Particularly GraphQL API's.
Sure, your average static content site didn't use an API in 1998, but WordPress/Drupal sites have exposed poorly secured APIs since the early 2000s even if the standard front-end didn't use them for content display.
I told them, but they responded with something like "We are currently unable to change that. There are plans to change that in the future though".
Now all you need to do is grab their GraphQL endpoint from devtools and you‘re off to the races.
I didn't realize until this project that a dynamic, reactive site can use static hosting.
Vue has been a pleasure to work with. It supports server side rendering too but do far I haven't needed it.
I've written a fully statically served, backendless PWA, that uses the browsers local storage for persistent data, meaning that the data is fully private and owned by the user. If a user needs to sync their data between clients, they can connect the app to their Dropbox or Google Drive. There's even a chat implemented with WebRTC which allows users to communicate directly with each other, without a backend.
If you disregard the JS haters on HN, you'll realize you can do some amazing things in the pure browser runtime nowadays.
[1]: https://hurl.dev
Leave a reply if you want to be notified when the content is ready.
I'm curious what you mean by this "reliable setup" part. Can you elaborate?
"This section could contain anything, but at minimum it needs to contain some kind of user identifier and a timeout (iat)."
The iat claim is when the token was issued, not when it expires. The exp claim is when it expires.
See also https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4
Now I need to see an article on modern API development methods, including trusted frameworks.
Cheers
Seems like a real "wet sidewalks cause rain" story. The model was becoming more popular among developers and then they made frameworks seems more likely than the other way around.
Then the "ten billion" part. The three frameworks he listed dominate. Everything in "etc." is minor in comparison.
I find this meme about JS frameworks lazy. (Note: totally a web backend person, so I should be the first to do the teasing). There seem to be much more boring answers:
1. With some exceptions (ClojureScript, TypeScript, Elm, ...), everyone who writes for the browser is forced to write JS. On the backend, people can express different opinions by using different languages (Python, Ruby, Java, Elixir, ...). So people that would split themselves into language camps on the backend are more likely to split into framework camps on the frontend.
2. The frontend environment is constantly changing (browsers) so the code is going to be churnier. You can't just not upgrade like you can on the backend.
3. User interfaces are more iterative than backend stuff, so the code is going to be churnier.
4. All this churn makes a rewrite more accessible and tempting.
I just find it easier to believe that there's some difference in the constraints and freedoms of JS devs that causes them to make more (but not really that many more) frameworks, rather than there's some secret character flaw or something.