I also write articles in Sketch, because the app is heavy on illustrations. Using sketch allows me to draw the images directly while writing the articles. It is then sliced and exported into the app through a custom plugin.
It makes creating a small web form to feed your database as easy as
SELECT 'form' AS component;
SELECT name, label, type FROM form_fields;
INSERT INTO parties(name, date) VALUES(:name, :date);
And creating an api on top of that db as simple as: SELECT 'json' AS component,
(SELECT JSON_GROUP_ARRAY(JSON_OBJECT('name', name, 'date', date)) FROM parties) AS contents;
[1] https://sql.ophir.dev/
[2] https://github.com/lovasoa/SQLPage UPDATE parties SET name=:name, date=:date WHERE id=:id;The update form would look something like this:
select 'form' as component;
select 'event_name' as name,
(select name from events where id=$id) as value;
select 'event_date' as name, 'date' as type,
(select date from events where id=$id) as value;
select 'event_id' as name, $id as value, 'hidden' as type;
and the page processing the form would look like this: update events set name=:event_name, date=:event_date where id=:event_id;
If what you are saying is that it's more complicated than a google sheet, then yes, there's no denying that. But it's also an order of magnitude less complicated than traditional web tech, and the result is a real website, not a google sheet.It's a little bit more complicated to set up than a google sheet, but it's less complicated to use afterwards.
So I beg your pardon.
But what it really meant is that this sort of a technical solution may appeal to a developer, but not to regular users, not the ones who just updated spreadsheets for their website yesterday. Looking from that “mere mortal” point of view, and when it’s suggested by a person who isn’t yet known to be an author, in that context it feels like a 50% sarcasm and 50% our common geek stereotypes. I understand what SQLPage provides for a technical person, so please treat my comment as a joke which it is.
Btw how would you compare this to https://datasette.io/ which is the first thing that came to mind? Is yours a bit more developer oriented?
- datasette builds one single website and API, which you cannot customize, on top of a SQLite database. It is a little bit ugly, but very efficient to help you discover your own dataset, and make some quick data analysis. If you're concerned about restricting public access to your database, sharing it may not be ideal.
- SQLPage does not build anything for you by default. You need to write at least two or three SQL queries to make a useful website on top of your database. This requires you to already know the schema of the data you are working with. But this allows you to build visualisations of your data that look the way you want. While Datasette mainly offers tables, SQLPage provides forms, graphs, lists, tables, data cards, and more. The results tend to have a more polished and professional appearance, and your database remains private. Only the (parameterized) queries you create yourself can be executed by website visitors.
Furthermore, a significant distinction is that Datasette exclusively works with SQLite, while SQLPage can connect to SQLite, Postgres, MySQL, or SQL Server databases.
Anyway it's a great looking tool and wishing you the best with it!
Although what sheets excels at is batch editing and collaboration, which is really hard to get in an SQL frontend. My brother usually runs a Raycast workflow I wrote for him to extract a small number of party data as TSV which gets copied in clipboard. Then in sheets he can just paste that to get full rows and columns populated.
After that he and his friends start proof reading and cross referencing social media data for each row, and Sheets makes this super easy as they can see each row highlighted with each user’s color so they don’t step on each other’s toes.
Your solution is still very good for other use cases and I think I already have one in mind. My father always wanted to maintain a list of up-to-date prices for the vegetables that sell in my hometown’s large wholesale market.
well played
The sql source code for it is here: https://github.com/lovasoa/SQLpage/tree/main/examples/offici...
The site also links to this little collaborative game written in SQLPage: https://conundrum.ophir.dev/
The github README has code snippets and associated screenshots: https://github.com/lovasoa/SQLpage#examples
There is also an official repl.it that you can fork to quickly try it online without having to download anything: https://replit.com/@pimaj62145/SQLPage
And SQLPage cloud is coming: https://sql.ophir.dev/your-first-sql-website/hosted.sql
My recommendation would be to have a clear "see a demo" button, which leads to a website that showcases the most common elements I might want to have on such a page (a form, some graphs, etc), maybe with source code close by.
They’re not easy to create but side by side code/result demos like the ones I saw on https://imba.io/ make it very clear on what I’ll be getting into as a developer.
Realtors and doctors, mostly.
It’s an app for finding parties and festivals in Romania, and the sheets choice makes it super easy for my brother and his friends to add parties to the app.
I thought about adding a “real” database and tried some apps/frontends for them, but nothing made it easy enough to update and insert rows for non technical people.
I figured I could just download and cache the Sheets CSV, and use that for the database.
PS: the app is the one I had trouble getting published because the App Store reviewers deemed it“too simple”: https://notes.alinpanaitiu.com/Dealing-with-App-Store-reject...