Comment by tharkun__ | Hacker News Reader

Comment by tharkun__ | Hacker News Reader

Parent Full thread

This is something that powers a lot of data interchange but lots of people don't realize because they never work with older systems like that. It's not shiny. No frameworks.

I used to work for a large, old company whose products you have all bought and buy (and which shall remain nameless) about 15 years ago. I worked on data interchange between the systems used for record keeping of said products and various other downstream or parallel systems (same purpose, separate system because left over from merger/acquisition).

So basically bulk data import and export. The product was 15 years old at that point. Data interchange was via various fixed width or delimited (CSV but the C might be some other character or character sequence) files transferred to and from various SFTP servers.

It's been a while but there were probably like 20 or 30 different such data sources or exports going in and out. Worked like a charm. I bet they're still used without much change. The frontend was being rewritten at the time (old one was in Smalltalk).

I'm using this type of simple approach to build a SaaS right now. We need to spin up many VPS and provision them, and the fastest way to do that is with rsync and ssh.

But we didn't stop there: this SaaS for our open source browser product is entirely built like this: behind the scenes it's a collection of bash scripts that implement and execute the business operation of the SaaS.

So basically, it's a command-line interface to the SaaS. Think of it this way, say I didn't have a website, with login, and "click a button to open a browser", but instead people would write me letters, send me cheques, or call me on the phone. Then I can serve their requests manually, at the command line.

The reason I made it like this was:

- clear separation between thin web front-end and actual business logic

- nice command-line interface (options, usage, help, clear error messages) to business logic for maintenance and support to jump on and fix things

- inheritance of operating system permissions and user process isolation

- highly testable implementation

Maybe this is dumb, but I really like it. To me it's an architecture and approach that makes sense.

I'm sure this is not new, and I think a lot of good quality operations must be built via this way. I highly align with the author's stance of the composition of a few simple command line tools to get the job done.

Perhaps we can call this "unix driven development", or "unix-philosophy backend engineering"

browser product: https://github.com/dosyago/BrowserBoxPro (saas coming soonish)

I feel like you went way overboard with this one.. I think the first paragraph and an example of what you're doing that's similar to OP would've been plenty

I enjoyed their comment, thanks...

You're being a jerk, someone shared something they were proud of that's relevant to the discussion. What's the problem?

A lot of developers talk smack about CSV files (or tab delimited) but they really are the workhorse of our industry. They're simple, textual, compress really well, and as long as everyone on both sides has an agreement about the format, they're almost a standard.

sure, a lot of the criticisms of CSV are true, but given the above constraints it's really hard to beat them.

"everything is a file" still going strong

And they can be open in Excel for the best and the worst.

Reply on news.ycombinator.com