Hacker News Reader

Comment by hmottestad | Hacker News Reader

PHP is my go to language for building simple backends that store data as json in a file and synchronize access using flock(...). There are a ton of cheap hosting providers that support PHP and all you have do to is copy your files over and everything works.

I love to focus my energy on building a great frontend with React or Vue.

View on HN

In the past I built a few things on Google App Engine. Honestly one of my greatest regrets in life. I ported a few to PHP so I won't get screwed again when I need to change hosting provider. Still need to port some and am dreading doing it but it will be for the better.

It's a shame companies, especially large ones with strategic architecture teams who should know better, haven't identified the short term cost savings of using cloud provider specific services is not worth the long term cost of vendor lock in.

And for startups their recently minted MBA CEOs are too willing to load up on "tech debt" on the race to revenue.

And really, it's not a bad trade - financially. But it will frustrate your eng team, for a bit - especially if you don't actually get the revenue stream going.

Huh. I deploy a lot of stuff to GAE and love it. But my approach is to just write regular Django apps, add a half dozen lines of GAE-specific stuff to the settings and that's it. No trouble at all running the same apps somewhere else with only trivial changes. That's worked really well for me for work where we're already on GCP and GAE lets us run our lower traffic services reliably for very little money.

I was using Datastore and other GAE specific stuff.

You have any good simple examples of your backend? Sounds like what I've been attempting to explain to others. How many concurrent requests and what size of data can you run with a setup as described?

Storing stuff in a json file sounds horrible to me. Why would you want that?

Because your data is teeny tiny, not performance critical, and `json.load` and `json.dump` is easy and usually less brittle then you're language's marshalling library.

Why save 10 minutes on setting up a proper database? Data is never teeny tiny, data is never not performance critical :) These decisions only bite you in the ass.

Setting up a database takes way longer than 10 minutes. Data can be teeny tiny. Data can not be performance critical. You literally know nothing about the commenter’s application.

"I just want to serve five kilobytes of data."

With SQLite, you can have a simple database set up in a minute.

All my side projects have teeny tiny amounts of data. JSON file in the order of KB. Performance is great.

I have one project with a dozen users that handles around 50 reads per second and maybe 30 writes per day, no issues at all. Setting up a DB for that would just bite the next dev in the behind since it would need a lot more maintenance then an apache server with php.

PHP supports complex data structures using associative arrays which map to the application requirements. Which can be easily saved in JSON. A SQL database with rows and fields does not always work well with these data structures. Often, as long as the data size is manageable, a json saved in a mediumtext field in MySQL works just fine.

Because you asked I got around to publishing it on Github: https://github.com/HASMAC-AS/LightStore

PHP gets a lot of criticism for its legacy of behind hacked together. One thing that does get as much criticism, and one reason I avoid it for even simple things, is since it's request-based, it doesn't have a good story for connection pooling. While working on a former employer's PHP SDK, I had to add proxy hooks to it, then document how to set up Apache or Nginx as a proxy so you can get outbound connection pooling. If you depend on any third-party APIs, this can be a big deal for performance.

Doesn’t PHP-FPM handle pooling? Perhaps we’re talking about different things

Isn't this for process reuse and incoming connection reuse? I needed outgoing connection pooling.

I've wondered why there's no JSON-based equivalent of SQLite, like "MongoDB but it's just a file and a library."

I think because SQLite ate that market with the JSON extension. I've also seen LMDB used in the wild.

But ... SQLite is "just a file and a library".

Yes, but it's SQL. Some people want a "document database" that looks more like JSON. (Yes, I know you can store JSON in SQLite.)

Reply on news.ycombinator.com