notoverthere
As in, so you can plug the camera into an iPhone and transfer photos from camera to phone?
But I still disagree that the use of Firebase, in and of itself, is a bad engineering decision. It's just a tool, and it's up to you how you use it.
Firebase gives you all features needed to secure your backend. But if you configure it incorrectly, then _that's_ where the poor engineering comes into play. It should have been tested more comprehensively.
Sure. You could build your own backend rather than using a Backend-as-a-Service platform. But for what gain? If you don't test it properly, you'll still be at risk of security holes.
If you're trying to bring value to market, focus on your core differentiator and use existing tooling for your boilerplate stuff.
Although if you aren't going to support DDG with ad revenue, I'd suggest supporting with a donation if you can afford it and value their service.
It traditionally hasn't behaved as one – which sort of makes sense, because WordPress grew-up in a world where long-lived servers with writable and persistent local disk storage was commonplace.
I'm sure things have moved on since those days. This was back in 2016. But it sure was a fun challenge!
This is super cool, though.
What is core?
Online stores can (and do) remind us about this stuff via email. No third-party tracking cookies needed – you're already a customer of theirs. If they want to get in touch, they already know your order history and contact details.
Or, you know, we can add our own reminders to a personal calendar.
Likewise for underlines on headings – I can't see that in the style guide.
Firebase handles all the complexity for you. You get a nice set of JS SDKs for auth, database, cloud functions, file storage and static hosting.
And the best part is how damn cheap it is.
No fussing with low-level Redis clusters or paying for things on the edge. It all 'just works' and it does it fast.
Or alternatively, apply a class to the body tag – e.g. `<body class="high-contrast">` – and declare CSS rules accordingly. Specificity should take care of overriding the 'normal' style rules where needed.
It comes with an adapter for Google Photos, so you can use it to download / backup photos and videos in your library.
Note: there are some limitations to this approach – namely that rclone won't be able to download your original image files, even if you uploaded with 'original' quality. These limitations are documented on the rclone website: https://rclone.org/googlephotos/
If you're quick enough, you can see it in action:
Paste a link in a WhatsApp message. The preview might take about half a second to load. Hit 'send' before the preview has loaded, and it'll never show for that message.
Paste the same link again, but wait for the preview before hitting send. It'll stay attached to that message.
So presumably the 'proper' way to do it, if you're not looking for convenience, is to use `div`s. /s
So in other words – a unique key is generated every time a virtual machine is created. It's fully automated, never shared between instances, and never needs to be handled manually. That key will give the virtual machine permission to access other AWS services, in this case the AWS Secrets Manager.
So as long as you're using EC2 instances, you won't need to worry about securely passing a 'master password' to your VMs in order for them to access secrets.
The first resource I'd recommend is JSpreadsheets, which is a list of open-source JavaScript spreadsheet & data grid libraries. https://jspreadsheets.com
One of the most fully-featured JS libraries is Handsontable. It looks very flexible. They have some demos on their website to play with: https://handsontable.com/examples.html?headers
(Bonus: If you're using react, there's already a react component for using Handsontable: https://github.com/handsontable/react-handsontable )
It's an extra link in the chain, meaning another potential bottleneck and added latency.