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

Ask HN: Would more apps build with Git back-end if there’d be a solid SDK?

news.ycombinator.com

Post reply on HN
Print view View original

11–15 of 15 posts

Re: Ask HN: Would more apps build with Git back-end if there’d be a solid SDK?

#11

Post by karmakaze »

hannes_paul wrote: post #3
PaulWaldman wrote: post #2

Can you provide a few examples of apps you have in mind? Are you indicating a service would fetch files from git based on user requests?

Oh I see how that was unclear. I don't mean using git as a database for user requests, but git as a back-end for collaborative applications. For example, in our case, translators and devs have to collaborate to achieve localization. Normally translators would work in some isolated cloud application and then data pipelines between said application and the git repo are built. But why doesn't the translator facing app j…

I think this is a pattern that does get used. The method I've seen is that the English language text is saved in files in particular directories with text keys. Translators add similar files with different text for the same keys and commit to the repo. Whether this is done manually or automated isn't a big deal. The app could even run the `git` commands and operate on the output of those commands and filesystem--there's nothing particularly hard to parse.

Re: Ask HN: Would more apps build with Git back-end if there’d be a solid SDK?

#12

Post by fiedzia »

karmakaze wrote: post #10

The value of git is distributed operation and tamper-evidence. What would be the value of these attributes for a cloud-based app? To me it seems more logical to use versioned data in a database that only the cloud app accesses.

Db idea of versioning usually is useless for implementing version control as git does. You could store git objects in a relational database and that makes a lot of sense (becasuse transactions and better data integrity guarantees).

Biggest issue with git for me is that its only usable for plain text. There is Dolt and few other projects that try to solve it,

> The value of git is distributed operation and tamper-evidence. What would be the value of these attributes for a cloud-based app?

Cloud based apps are very often distributed internally. For example consider a book store that has data in a database and replicates that in elasticsearch and some data analytics platform. Being able to use data versioning for those replications could be useful.

Re: Ask HN: Would more apps build with Git back-end if there’d be a solid SDK?

#13

Post by karmakaze »

fiedzia wrote: post #12
karmakaze wrote: post #10

The value of git is distributed operation and tamper-evidence. What would be the value of these attributes for a cloud-based app? To me it seems more logical to use versioned data in a database that only the cloud app accesses.

Db idea of versioning usually is useless for implementing version control as git does. You could store git objects in a relational database and that makes a lot of sense (becasuse transactions and better data integrity guarantees). Biggest issue with git for me is that its only usable for plain text. There is Dolt and few other projects that try to solve it, > The value of git is distributed operation and tamper-evid…

I can't tell which parts are agreeing or disagreeing with the quoted statements. Is doing versioning explicitly in a database necessarily more complicated than with git histories?

Using a distributed datastore should make operations simpler and more transparent without having to think about the distributed nature, other than latency of operations. So if using a distributed datastore achieves distributed nature, is the tamper-evidence what's needed and missing or something else? For a cloud-based app, redundancy/fault-tolerance is the concern rather than being distributed unless you're running a globally distributed platform that can't be partitioned.

Datomic/Datalog[0] is an example where the log of changes is the primary 'store' and a coherent view at any point in time is constructed from the log.

[0] https://en.wikipedia.org/wiki/Datomic

Re: Ask HN: Would more apps build with Git back-end if there’d be a solid SDK?

#14

Post by fiedzia »

karmakaze wrote: post #13
fiedzia wrote: post #12

Earlier quoted context omitted.

Db idea of versioning usually is useless for implementing version control as git does. You could store git objects in a relational database and that makes a lot of sense (becasuse transactions and better data integrity guarantees). Biggest issue with git for me is that its only usable for plain text. There is Dolt and few other projects that try to solve it, > The value of git is distributed operation and tamper-evid…

I can't tell which parts are agreeing or disagreeing with the quoted statements. Is doing versioning explicitly in a database necessarily more complicated than with git histories? Using a distributed datastore should make operations simpler and more transparent without having to think about the distributed nature, other than latency of operations. So if using a distributed datastore achieves distributed nature, is th…

>Is doing versioning explicitly in a database necessarily more complicated than with git histories?

What "versioning" means depends heavily on the database. "Versioning" for typical relational databases like Postgres does not achieve many of expected git features like branching and ability to materialize data for arbitrary point in time, unless you build something extra on top (or just use db as git storage). There are databases like dolt where "versioning" idea is similar to git.

> is the tamper-evidence what's needed and missing or something else?

I always work in controlled environments, so don't care much about tamper-evidence (unless its used for detecting integrity issues perhaps).

I didn't know datomic, that's looks like solution for half of the problem (distribution and history). I may still be missing something more human-focused like git, where you have branches, collaboration and push or pull when needed.

I was just commenting, not disagreeing.

Post reply on HN