Generic Frontend for Database

Apps
1

I’m not sure this idea would be viable or useful, but here goes.

I currently have this app that’s essentially a “generic frontend” for a database with an API. For example, in this generic frontend I can make a table called quotes with two columns named quote and author. After I created that table, I can use said app to add data into the database using a standard form.

Now, the key bit here is that this database has an API, which other apps can use to get data out of the database. For example, I have a quotes app which uses that API to get the data and visualise it in a specific way. Check out the link for an example of what this looks like.

I’ve been thinking about how I could do this with IPFS. I guess I could just replace the database with IPFS and then IPFS itself is the API :woman_shrugging: Anyhow, what do you think about this? Does this sound useful at all to you? Should I store my quotes in something totally different?

2

The way I think about IPFS, it’s a file system.

Looking at the settings for your app:

[{ quote: "Quote", author: "Author" }, ...]
Or:
{ data: [{ quote: "Quote", author: "Author" }, ...] }

So looks like you are already creating this in JSON? So, you could make an editor that saves this to a specifically formatted JSON file.

And then the location of the file is either an IPFS hash or a gateway path like ipfs.io/ipfs/QmSOMEHASH

Or make a directory filled with individual JSON files, e.g.

{
  "quote": "A pithy saying from the depths of history, that makes you ponder the meaning of life",
  "author": "Jason Blob"
}

Obviously individual files might be harder to parse through, but you could store a directory hash and then each of the quote files could be looped through or randomly selected.

I think this is the very definition of like 2 or 3 different SaaS apps that use Google Spreadsheets as a way to make JSON APIs.

The nice thing of course is that you could make a front end app that has a “new quote” button, two fields, and then could save that to the JSON file, and it work right away locally, as well as online for others to consume.

Looks like you’re using Heroku right now?

This BTW would one way to do super simple things like user registration or form entries on static websites – except my thought was that this needs to be encrypted of course!

3

Thanks Boris!

Well, the API output is JSON. The editor is just the frontend for the database. I’ll post some screenshots of what it currently looks like (context, I made this 3 years ago).

55
551554×1108 28 KB

59
592118×1118 218 KB

Cool. Which ones did you have in mind? The only one I vaguely know is Airtable.

Yeah exactly.

Yeah, this old thing I set up 3 years ago.
Still use it to save quotes though :sweat_smile:

Interesting, form entries definitely sounds like a good use case :+1:

4

See Sheetsu as one example https://sheetsu.com/

I can’t find others right now. Way simpler than Airtable — just a front end interface that then gets output as JSON.

And what I meant was that this front end could load and edit JSON files directly — and then save back to IPFS. Database may not be required.

Of course, with Heroku, where you don’t have a file system — it ends up being easier to just use a database!

I did a quick search for JSON editors. This is a bit too complicated but may give some ideas https://github.com/json-editor/json-editor

5

Oh gotcha. Yeah, that’s a good idea :+1:
And indeed, no database, because we have ipfs.

Will probably build this once we’ve got some identity and “personal files” bits in place :eyes:

1 Like
6

PostgREST

Note quite the same, but could maybe a good place to take ideas from

http://postgrest.org/en/v6.0/

Structure

One challenge with random JSON blobs is that it’s incredibly unstructured. There are many cases (in fact, the common ones) where you want to impose some structure on your data. For single user use cases, it can be okay since they’ll generally self-regulate, but Mongo has taught us that’s not always the case. There are for sure cases where the ad hoc simplicity is okay.

Event sourcing is IMO a nice in between, but that’s me beating the event sourcing drum as usual :drum:

7

That’s a good point! Event sourcing does seem to be a nice in between. Between full-blown data standards and random json blobs to be more specific. Not as strict as a standard, but more strict than no standard at all. As long as the event itself is properly structured and has enough data that is.

Might have to hold off a bit with this until we’re delving into event sourcing + databases with Fission :smile:

1 Like