I’m posting this here, because our whole frontend is written in Elm and we’ve a dedicated tutorial on how to write a full fledged GraphQL Elm app powered by Airsequel. The tutorial now comes with a companion repo at GitHub, which can be used as a template for your own projects!
And I’ll even be so bold to claim:
Airsequel is the easiest and fastest way to set up an Elm app with a full CRUD backend.
Let me now if you have any objections to it!
The main addition for this release is a SQL workbench where you can directly execute SQL statements on you database. I’m especially proud since it’s also fully written in Elm – including the text editor. (A big thanks to Pablo Hirafuji as this would have not been possible without his elm-syntax-highlight package.)
To limit the potential of misuse, this is currently limited to read-only queries on our Free instance at airsequel.com, but on our enterprise instances all SQL queries – as supported by SQLite in safe mode – are available.
We also changed our slogan on the landing page, since @supermario apparently wasn’t a big fan of it. (…and we weren’t either.) I think the new one captures our goal quite succinctly.
This is very exciting. I love seeing how Elm is being used both commercially and personally. Seeing work like this keeps me energized in my Elm work. Well done and good luck in your business!
Couldn’t remember what I said that you were referring to – was it the “get started in x seconds” trope I despaired about on the Software Unscripted podcast? If so I’m glad that sentiment resonated!
Congrats on the release!
I couldn’t see it in a quick skim of the docs, but do you support GraphQL introspection? If so, how do you reconcile that with sqlite’s dynamic typing? Do all types always come out as nullable string?.
Yes, exactly!
I mean, it really is just drag & drop to get the GraphQL API (I don’t know of any other online service which can do that), but I agree that it has a dishonest connotation about everything being fast and instant.
TLDR: For requesting table data via the GraphQL API, we coerce all data to the table schema’s type. For data generated in queries (therefore without a schema definition) we fall back to nullable String.
(…and we weren’t either.) I think the new one captures our goal quite succinctly.
)
