Another issue with Cloudflare's registrar is that it's almost impossible to move a domain between two Cloudflare accounts - https://developers.cloudflare.com/fundamentals/setup/manage-.... You have to kick it out to a third-party first which is just silly.

I've run into all of these issues running a GraphQL API and, while they aren't easy, they aren't exactly intractable either. Let's not pretend that OpenAPI/REST or Protobuf are perfect alternatives. They've each got their warts and tradeoffs.

The thing that I still _like_ about GraphQL is that it's a nice approach for expressing complex domain models over a protocol. If you are working with either REST or protos, you may still have to reason about graph-like structures but without the benefit of a graph-like schema.

OpenAPI can do graphs too, since you can put in refs to objects that can themselves have refs to other objects, possibly recursively.

At that point you've recreated the exact same problems many here are complaining about, N+1, authorization on leaf nodes, ability for the client to create queries that are hard to optimize, etc...

The client doesn't create queries in this situation, you explicitly define them server-side. So optimization is easier. I've seen this time and again with services that aren't GraphQL but tried to provide a semi-freeform query feature; if you only have a few clients and control them all, it's way easier to just make separate endpoints for whatever they need. If you have many clients, maybe GraphQL makes sense.

Auth on leaf nodes, maybe I'm not understanding the issue but it seems solved without GraphQL. JWTs are one way.

Your bank account is an asset for you, so debits increase the balance while credits decrease it. This is also called a "debit normal" account.

Liability accounts are tracked in reverse and are "credit normal". You increase the value (how much you owe) with a credit to the account and decrease the value (payments you receive) with a debit.

One way to think about is you always "credit" the source of the money.

If you get money from somebody you "credit" them for giving you the money. You say "I must give you credit for having done this".

If money goes into your bank-account you don't credit your bank-account because money didn't come from there it went there. If you don't credit the bank account you must be doing something else and that is called "debit". When money goes to your bank-account you "debit" it because now the bank-account is more "indebted" to you. You don't have the cash in your wallet but the bank-account is indebted to you by that amount.

From the view-point of the bank-manager things are of course reverse. When you put money into your bank-account the bank-manager "credits" you-the-account (in their books) for having done so.

I guess a crucial thing to realize is that your bank-account in your books is a different thing from your bank-account in the books of the bank. It seems like there is only one bank-account, but two different parties (you and the bank) each have their own version of that "account" in their book-keeping system.

A double-entry book-keeping system is "subjective" in that it always describes things only from the viewpoint of whoever it is who is doing the book-keeping.

Thanks this explanation helps. Does that mean that from the banks perspective my deposits are a liability?

Yes! Because you can remove your deposits from the bank and they also have to pay you interest on that balance. Your mortgage is an asset to the bank for the opposite reasons.

Exactly, from the bank’s point of view every dollar you deposit is incurring indebtedness to you

This could be extremely helpful for conveying trig or other math concepts in an education setting. I know a lot of visual learners that struggle with mapping the math to the visual space. Sprinkling in interactivity is a great way to help cement understanding.