Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A database for 2022

tailscale.com

Post reply on HN
Print view View original

311–320 of 336 posts

Re: A database for 2022

#311

Post by tored »

alophawen wrote: post #294
unfocussed_mike wrote: post #285

Earlier quoted context omitted.

There are several PHP frameworks worth using. Laravel is, IMO, among the best web frameworks available full stop. Certainly one of the most maturely documented. It addresses all the points you make.

I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and…

Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks.

Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic.

* magic classes - using PHP magic methods for everything, the actual class is usually empty and things happening elsewhere.

* magic files - put a file with the correct name in folder somewhere and things happen

* magic configuration - put a hard coded string in some config file and you change the entire behaviour of the app.

* magic layers - if you follow the execution path with the debugger you spend the majority of time circling around in different layers and very little time in your own code.

All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.

Re: A database for 2022

#312

Post by samhw »

belter wrote: post #288
zimpenfish wrote: post #286

Earlier quoted context omitted.

> Sharing a folder or file from Dropbox is no more intuitive than using the S3 console. I've not really used the S3 console but, at least on macOS, sharing a file from Dropbox is as simple as "right-click on the file in Finder, Share..." then enter an email address or create a share link from the popup. Or I can right-click and "Copy Dropbox Link" if the direct link is good enough. Is the S3 console simpler than a ri…

Even easier and safer, create a signed url that expires after 5 min...Send it to the user... aws s3 presign s3://awsexamplebucket/test2.txt --expires-in 300

...are we deliberately reenacting the original Dropbox thread here?

Re: A database for 2022

#313

Post by Operyl »

samhw wrote: post #312
belter wrote: post #288

Earlier quoted context omitted.

Even easier and safer, create a signed url that expires after 5 min...Send it to the user... aws s3 presign s3://awsexamplebucket/test2.txt --expires-in 300

...are we deliberately reenacting the original Dropbox thread here?

It usually ends up happening when the Dropbox thread comes up, it’s really interesting seeing both sides rehash the same points.

Re: A database for 2022

#314

Post by zimpenfish »

belter wrote: post #288
zimpenfish wrote: post #286

Earlier quoted context omitted.

> Sharing a folder or file from Dropbox is no more intuitive than using the S3 console. I've not really used the S3 console but, at least on macOS, sharing a file from Dropbox is as simple as "right-click on the file in Finder, Share..." then enter an email address or create a share link from the popup. Or I can right-click and "Copy Dropbox Link" if the direct link is good enough. Is the S3 console simpler than a ri…

Even easier and safer, create a signed url that expires after 5 min...Send it to the user... aws s3 presign s3://awsexamplebucket/test2.txt --expires-in 300

But now you have to know which bucket the file is in, have the AWS CLI tools installed, use Terminal, copy the URL to messages / email, etc.

How is this easier than "right-click, pick a menu option"?

(If I want an expiring Dropbox link, it's there under 'link settings' in the pop-up. Admittedly only has date granularity but still there as an option.)

Re: A database for 2022

#315

Post by ransom1538 »

hparadiz wrote: post #304
ransom1538 wrote: post #234

Earlier quoted context omitted.

"know there are limits to MySQL" I have gone past mysql limits a few times. Will you go beyond its capability is a simple measure. Can your hardware write fast enough to keep up? If your hardware maxes out writing to disk 200 megs per second, welp mysql maxes out at 200 megs per second. If you need 400 megs per second of writing, well you need two instances that can write independently. That is when you are fucked. A…

That's what I mean though. I've never hit those limits. These days it's easy to put together a raid 5 with NVMe disks and you'll quickly reach gigabyte per second write speeds.

What cloud service can you do that on? Seriously asking.

Re: A database for 2022

#316

Post by klysm »

tored wrote: post #311
alophawen wrote: post #294

Earlier quoted context omitted.

I had a 10 year career doing PHP, in the last year or so I also enjoyed Laravel and built 10 or so sites with it. It did many things right. Eventually some blade template error resulted in an impossible stack trace due to the insane amount of magic behind the scenes in Laravel, and while debugging that I decided to stop relying on such black magic hack of a framework. Around the same time Go gained in popularity and…

Frameworks helps developers to move in the right direction, and that is a good thing, however when you have used a framework long enough you start seeing the cracks. Frameworks solves a general problem, you on the other hand has a specific problem. To be able to accommodate your specific problem and everyone else specific problems frameworks has tendency to heavily rely on magic. * magic classes - using PHP magic met…

> All of these things are considered bad practice when doing it in your own code, but for some bizarre reason it is considered good practice in frameworks.

I think that’s because that kind of code has a much higher maintenance burden. It’s much more difficult to get up to speed on what’s going on in complex magical code. But you can probably trust a framework that’s achieved critical mass to make reasonable decisions and stay alive for a while.

Re: A database for 2022

#317

Post by klysm »

unfocussed_mike wrote: post #309
klysm wrote: post #305

Earlier quoted context omitted.

I agree it's _initially_ productive, but the it becomes very difficult to maintain.

Why/where, particularly in Laravel? Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere). Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code inter…

I don’t have anything objective to back this up, but in my experience it requires a lot more discipline and initial knowledge from the devs. Much of the existing documentation for PHP is just plain wrong, or horrible advice. It’s difficult for new devs to learn these practices. PHP let’s you be ‘lazy’ and hack in shortcuts to solve problems - lots of discipline required there.

If you have a solid team and some people with a good background in the framework and PHP that can mentor effectively, then it probably won’t be bad. It still would not be my first choice though.

Re: A database for 2022

#318

Post by tored »

klysm wrote: post #317
unfocussed_mike wrote: post #309

Earlier quoted context omitted.

Why/where, particularly in Laravel? Laravel has an excellent ORM, a great query builder (I write almost no SQL), an effective database migrations system, a solid class hierarchy (no include statements anywhere), a really useful job queuing system, and it is built around Composer (one of the best package managers anywhere). Lighthouse is really a first-class, schema-first GraphQL binding with a very logical code inter…

I don’t have anything objective to back this up, but in my experience it requires a lot more discipline and initial knowledge from the devs. Much of the existing documentation for PHP is just plain wrong, or horrible advice. It’s difficult for new devs to learn these practices. PHP let’s you be ‘lazy’ and hack in shortcuts to solve problems - lots of discipline required there. If you have a solid team and some people…

Compared to what?

Re: A database for 2022

#319

Post by samhw »

VWWHFSfQ wrote: post #302
yawaramin wrote: post #301

Earlier quoted context omitted.

If from your perspective, a super-successful VPN product is 'really struggling', you must have incredibly high standards! We all hope to hear more about your successes, I'm sure.

do you want to hear about my successes? they're not going to be about shoe-horning a JSON file or a SQLite database file into my enterprise product.

Sure, so what are they about?

Re: A database for 2022

#320

Post by jeffffff »

tptacek wrote: post #262
jeffffff wrote: post #260

Earlier quoted context omitted.

it's not cargo culting if it works, and they even say in the article that mysql or postgres would've worked maybe next they will stop cargo culting operating systems and switch to SerenityOS?

They're talking about running many instances of MySQL locally, not hooking all their systems up to RDS.

no they aren't

Tailscale’s coordination server, our “control plane”, has become known as CONTROL. It’s currently a single Go process on a single VM.

source: https://tailscale.com/blog/an-unlikely-database-migration/

Post reply on HN