If you want a fully built out network layer, with auth, logging, monitoring, policies, etc, then `fetch` doesn't really help. Axios and other libraries provide much more for building that sort of framework.
Any sufficiently competent typescript developer can build out an adhoc wrapper (that just inherits the type definition and passes along whatever it is passed after altering it however needed) in under a hour. It doesn't scale in the sense that you don't expose a configuration, but config as code is king.
(Source: have built out much more scuffed variants of this than the one I just described like https://github.com/boehs/ajar)
I guess a LLM can do as well. Although that's not something I'm quite ready to admit.
I've wrapped fetch a few times but i don't think I'd blame someone if they got tired of wrapping it and wanted a consistent interface across all the projects they work on.
Having done a major migration with Stripe, at a startup, I disagree.
They have lots of products, but you don't need most of them and can ignore them. What's left is, in my experience, the correct amount of complexity. We looked at Braintree, and it was just missing things that we were legally required to support, we looked at Judopay and it was... lacking (a nearby founder describe Judopay as treating payments like a hobby).
If your business is just ecommerce and you can use Shopify instead, sure, do that. If you just need to take dumb payments, just use Stripe Checkout. But if you need any control over your payments, Stripe is the only good option for startups. As you grow it becomes easier to justify more complex integrations such as Adyen, Klarna, etc, but Stripe is definitely the best starting place I've seen.
He is right, reading the docs you have no idea which events leads to what. Nowadays with llm's it's easy before that I still dont know which events mean what.
The migration I did was from the basic Stripe product to the complex one. I did it because we were legally required to do the transition. Stripe was the only major vendor with the technology ready for that migration.
> If you just need to take dumb payments, just use Stripe Checkout.
Could not agree more. Offload as much complexity (receipts, invoices, tax, customer info, etc.) to Stripe as humanly possible in the beginning. Don't build for edge cases or UX polish. If people want your product, they will buy it.
This is kind of the tradeoff you need to make when launching a product though. You cleave off some of the product's margin & send it to a third party so that you can get the thing launched. If it's unsuccessful, that's fine, you'll pay no money to the vendor. If it's successful..? Great! Now you can afford to pay someone to build a checkout that doesn't cost me thousands a month in fees.
Stripe takes 1.5-2.5%, so if you're sending them 1,000s a month, your revenues from that checkout are approaching the $millions p/a. Certainly enough to hire an expert in the domain.
Stripe's fees are well above interchange fees (especially in Europe). On top of that Stripe's pricing for other features (e.g. invoicing and subscriptions) is also a percentage, so you end up paying a ton for those features.
because stripe on purpose hide fees, constantly asks you to try out new features and then secretly charges you more then market price when you say yes. See radar, managed payment, stripe billing management etc.
> Our Founder! of this project is battling cancer. Your Stars and Forks are appreciated.
I'm sorry to hear this, but I'm also surprised that this is the first thing I learnt about this project, and that it is written in the third person. It detracts from the project.
I don't have a problem with mentioning cancer, but they should've mentioned which cancer to raise awareness and help others. The ribbon icon is gold which means pediatric/childhood cancer?
Asking for stars and forks is where it gets weird. I understand a crowdfunding program but how is this going to help?
Makes it even weirder that this is a completely anonymous, we don't know who works on it, and actually the project pretends to be authored by "AI". look at commit history and contributors
I don't want to be cynical here, my dad was diagnosed with cancer too but this just feels like some LLM was given a prompt to maximize stars and forks and this is how that went. I am very sorry to say this.
Although not disclosed on this page, the author's name is mentioned on their other projects[0].
> Our founder, Todd Bruss, is currently battling Cancer. Through it all, he continues to pour his heart into InkPen. Your support and encouragement mean the world.
The author has posted about their project on LinkedIn as well[1].
Open-source maintainers don't owe anyone perfectly-manicured marketing copy on their landing pages. Honestly, the fact that is the first thing you learn humanises the username behind the keyboard
> the fact that is the first thing you learn humanises the username behind the keyboard
The username is macOS26. The name is "Agent!". As in "Agentic AI for your entire Mac Desktop". All commits are made by this entity.
Until someone here told me there is a real guy behind it I sincerely gotta say, it looks like there's no human behind the keyboard and actually there's no keyboard at all.
Combined with cancer message on top it made me think some LLM "agent" is trying different tricks because it was prompted to achieve maximum stars and forks. I feel shitty for saying this but how not to be cynical because literally that's what we degraded to thanks to "ai".
> Combined with cancer message on top it made me think some LLM "agent" is trying different tricks because it was prompted to achieve maximum stars and forks. I feel shitty for saying this but how not to be cynical because literally that's what we degraded to thanks to "ai".
AI might increase the volume of shitty things on the internet, but it's not like GitHub accounts weren't anonymous before AI, and it's not like people weren't using scammy tactics to boost their star count before AI.
If the fear of AI turn us into worse people in our interactions, that's kind of on us, not AI
I honestly don't think anyone starred, watched or forked it because it was a person with cancer. They starred it because it's a good app. One that is missing on macOS.
Today, I used it to weed out hundreds of Linkedin "followings" with Safari. worked like a champ. It does very well at coding tasks too and automating Xcode builds.
I removed the Cancer banners. But I will tell you that I have physically gone through 2.5 weeks off hell. Chemo is no joke and I am 50% there. It gets tougher each time and the symptoms hit you in the middle of the week. And I also am getting booster shots that force white blood cells out of my bone marrow and it has severe side effects and all they can offer is over the counter Claritin.
I've had days of fevers, dehydration, nausea, vomiting and still holding down a day job. So please don't be offended by my diagnosis or saying that stars and forks mean the world because it kind of does.
This is a complexity that makes it harder, but not insurmountable.
It would be reasonable to say that if you run the file sync in a mode that keeps everything locally, then Backblaze should be backing it up. Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
> Arguably they should even when not in that mode, but it'll churn files repeatedly as you stream files in and out of local storage with the cloud provider.
When you have a couple terabytes of data in that drive, is it acceptable to cycle all that data and use all that bandwidth and wear down your SSD at the same time?
Also, high number of small files is a problem for these services. I have a large font collection in my cloud account and oh boy, if I want to sync that thing, the whole thing proverbially overheats from all the queries it's sending.
Reading your comments, it sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files. I know you haven’t technically said that, but that’s what it sounds like.
I assume you don’t think that, so I’m curious, what would you propose positively?
> I know you haven’t technically said that, but that’s what it sounds like.
Yes, I didn't technically said that.
> It sounds like you are arguing it is impossible to backup files in Dropbox in any reasonable way, and therefore nobody should backup their cloud files.
I don't argue neither, either.
What I said is with "on demand file download", traditional backup software faces a hard problem. However, there are better ways to do that, primary candidate being rclone.
You can register a new application ID for your rclone installation for your Google Drive and Dropbox accounts, and use rclone as a very efficient, rsync-like tool to backup your cloud storage. That's what I do.
I'm currently backing up my cloud storages to a local TrueNAS installation. rclone automatically hash-checks everything and downloads the changed ones. If you can mount Backblaze via FUSE or something similar, you can use rclone as an intelligent MITM agent to smartly pull from cloud and push to Backblaze.
Also, using RESTIC or Borg as a backup container is a good idea since they can deduplicate and/or only store the differences between the snapshots, saving tons of space in the process, plus encrypting things for good measure.
This. You should not try to backup your local cache of cloud files as if those were your local files. Use a tool that talks to the cloud storage directly.
Use tools with straightforward, predictable semantics, like rclone, or synching, or restic/Borg. (Deduplication rules, too.)
My understanding of Backblaze Computer Backup is it is not a general purpose, network accessible filesystem.[0] If you want to use another tool to backup specific files, you'd use their B2 object storage platform.[1] It has an S3 compatible API you can interact with, Computer Backup does not.
But generally speaking, I'd agree with your sentiment.
But if the files are only on the remote storage and not local, chances are they haven't been modified recently, so it shouldn't download them fully, just check the metadata cache for size / modification time and let them be if they didn't change.
So, in practice, you shouldn't have to download the whole remote drive when you do an incremental backup.
You can't trust size and modification time all the time, though mdate is a better indicator, it's not foolprooof. The only reliable way will be checksumming.
Interestingly, rclone supports that on many providers, but to be able to backblaze support that, it needs to integrate rclone, connect to the providers via that channel and request checks, which is messy, complicated, and computationally expensive. Even if we consider that you won't be hitting API rate limits on the cloud provider.
Sometimes modification time of a file which is not downloaded on computer A, but modified by computer B is not reflected immediately to computer A.
Henceforth, backup software running on computer A will think that the file has not been modified. This is a known problem in file synchronization. Also, some applications modifying the files revert or protect the mtime of the file for reasons. They are rare, but they're there.
The problem is, downloading files and disk management is not in your control, that part is managed by the cloud client (dropbox, google drive, et. al) transparently. The application accessing the file is just waiting akin to waiting for a disk spin up.
The filesystem is a black box for these software since they don't know where a file resides. If you want control, you need to talk with every party, incl. the cloud provider, a-la rclone style.
> even if the agents need ten days to reason through an unfamiliar system, that is still faster and cheaper than most development teams operating today
Citation needed. A human engineer can grok a lot in 10 days, and an agent can spend a lot of tokens in 10 days.
reply