🌀 Airsequel 0.6 - Teams, Pro Plan, API Access Control, and more!

Show and Tell
1

This version has been a long time coming and it’s finally online! Welcome to Airsequel v0.6! :tada:

I’m posting this here, because our goal is to become the easiest to use backend for Elm apps.
Check out the tutorial: How to build a todo app with Airsequel and Elm !
(Also, our complete frontend is written in Elm.)

Our main goal with this release is to enable professional usage of our hosted version of Airsequel at airsequel.com. Until now every database was standalone and public (unlisted). Now we have:

  • Full fledged user and team management
    • Teams own databases
      • Databases are either private or public (unlisted)
    • Existing public databases can be assigned to teams
    • Check out the documentation for more details

  • New paid Pro plan with less restrictions than the free plan. Check out the detailed feature comparison at airsequel.com/pricing.

  • API access tokens for fine grained control on how a database can be accessed via its API

Other notable improvements are:

  • Option to create databases from an AI prompt
  • Dedicated read-only endpoint to duplicate databases at
    /readonly/<readonly-id>/duplicate
  • Description field for databases and tables
  • GraphQL
    • Add support for comparison operators like and ilike
    • Support filters over several columns in mutations and queries
    • Support limit and offset arguments to only show a subset of the result rows
    • Support order_by argument in queries
    • Results are no longer reversed

For the full list of all changes check out our changelog.

We also have a blog at blog.airsequel.com now. Our latest article about Exciting SQLite Improvements Since 2020 was well received on Hacker News.

All those improvements also are available on our Enterprise Edition. You can request an Enterprise trial instance at airsequel.com/trial.

Last but not least: I hope a few of you might also consider buying a subscription even though you currently don’t have strong incentives to do so. There are not many companies left trying to build a sustainable business powered by Elm and we would be very grateful for any help we can get! We’re also planing to open source parts of our code like the core SQLite to GraphQL engine, and the Elm table component. Any financial support would really help here! :man_bowing:

Can’t wait to hear your feedback! :blush:

11 Likes
2

Hey @ad-si – love your work! Congratulations on another release.

I was looking around for information on schema changes / migrations, i.e. how I would manage the lifecycle of my data schema over time (i.e. field additions/removals/renaming/type changes).

Are there some docs/concepts on that I missed? Or is that up to the user to manage themselves with SQL directly? If the latter does it have some impact/consideration for the other features like auto GraphQL APIs, spreadsheets, etc?

3

Thank you! :blush:

Right now users must manage it themselves with SQL. As far as I can tell there should be no surprising implications for the API or UI. Airsequel is stateless in the sense that everything is stored in the SQLite database and any changes you apply to the SQLite database are also reflected in the API / UI. (Therefore you can also download the database, modify it locally, and re-upload it without any problems.)
We should probably add a section about it to the documentation.

However, we’ve been thinking about adding a “Migrations” tab / setting with a dedicated UI to write, list, apply, and revert migrations just to make it easier for users to manage the whole migration life cycle and keep track of it. Do you think that would be a good addition? Do you have any other ideas on how to improve the status quo?

4

Okay cool, gotcha.

I was thinking about how a Lamdera + Airsequel demo or use-case might look. I guess you’d have to take the “use discipline to ensure you only ever add fields, and stagger a rename/removal over multiple deploys” approach.

Maybe versioned schemas or something could make things a little better, but it seems that’s not an SQLite thing, and things get pretty complicated quickly with that approach anyway.

The migrations tab thing could be nice but brings more questions than answers for me, personally my main concern is “will this schema still match what my app expects or will I break everything in prod”, so my thinking is about how you could make that clarity as pain-free as possible, even in the presence of schema changes.

5

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.