hakanito

Agree with this. Like the author, I've been keeping ajour with web development for multiple decades now. If you have deep software knowledge pre-LLM, you are equipped with the intuition and knowledge to judge the output. You can tell the difference between good and bad, if it looks and works the way you want, and you can ask the relevant questions to push the solution to the actual thing that you envisioned in your mind.

Without prior software dev experience people may take what the LLM gives them at face value, and that's where the slop comes from imho.

Thanks, I spent my lunch hour completing it without cheating. Amazing!

How do you do that practically/reliably? Would be great to just paste a link to the SDK Github repo, but doesn't seem to work (yet) in my experience

The game changer for me will be when AI stops hallucinating SDK methods. I often find myself asking ”show me how to do advanced concept X in somewhat niche Y sdk”, and while it produces confident answers, 90% of the time it is suggesting SDK methods that do not exist, so a lot of time is wasted just arguing about that

It would lower the barrier to switch to Cloudflare for new customers, and once they are inside with a credit card on file it’s arguably easier to explore their product offerings

The obvious go-to choice was Cloudflare for us too, but then it turned out you can't use CF just as a registrar (at least on the basic plan or equivalent), you need to use Cloudflare's nameservers as well... But we use Google's Cloud DNS for everything, so that was a showstopper. In the end we went with AWS Route 53.

CF could probably get a lot more customers if they would allow you to use custom nameservers for your domain.

I know, but most people want to pay with their credit card and not a volatile altcoin, and they do not want to switch browser.

This is what I want too. Been wanting it for years.

Maybe once payments are bundled into the browser coupled with some W3 standard…

A world where the database is seamlessly embedded in the backend code instead would be more useful. Oh wait…

From reading the article, one of the key items addressed by HTTP Search is caching. POST requests are usually not safe to cache

Been pretty useful for discovery of SDK functionality in open-source libraries, that otherwise takes a bunch of time Googling the answer for. For example;

- Using golang, how do I write a custom marshaller for uber/zap

- Given a list of protogen.Files, how do I parse protobuf options and their values

Unfortunately the generated code is more often than not incorrect or uses non-existing API methods, but can give an idea of methods to use or where to look in the official api docs.

Yeah I’m sure there are all sorts of considerations. Also not saying it’s straightforward, just easier than writing a new db. You can for example write proto message extensions to support custom field behaviours.

But like a sibling comment said here, if you want the database implementation to dictate your models you can probably generate protos from something like EdgeDB. But then the db implementation is in charge, which seem a bit backwards.

If you’ve used graphql you’re presented with a similar challenge but on the other end of the spectrum - the graphql schema that needs to map to application models.

So one of the main considerations is to figure out how and where you want to define your source models. Is it the view layer, the model layer or the database layer.

Tldr; yes you’re right, it depends!

Love this idea, and in general agree that using a proto model as the single source of truth is a neat concept.

Not sure you need a completely new db though; with protobuf’s native support for plugins, perhaps the missing piece you’re looking for is a protoc plugin that generates the table definitions for your db of choice? Could work well for databases with declarative schemas..

Don’t want to discourage you from creating a new database, but writing a proto plugin is arguably a quicker undertaking!