Limits of free plan?

I just saw the TechCrunch article about Composer Pro being free for small companies. First of all – awesome, thanks!

What are the limits of this free plan?

In particular, what are the data limits? How much data can we store in the AppGyver platform? Can we link to tables stored in Google Sheets?

And are there any limits on users? If I put up a web app for my small company, how many external users can my app have? How many developer users?

Are there any limits on bandwidth?

Thanks!

– Maria

Thanks for the feedback! :slight_smile:

There’s no data limits (well, we might impose some if you start throwing terabytes of assets at us). The AppGyver Cloud Storage DB is limited to hobby (i.e. non-production) use, so for production use, you’d want to set up your own backend behind a REST API. For example, https://sheetsu.com/ does that for Google Sheets. (We’ve got a backend-as-a-service product cooking too, but more on that later.)

There’s no limit to the amount of users for the deployed app (this is possible since it’s not an active server, but a static deployment to Amazon S3).

If by “developer users” you mean AppGyver accounts that can access the same project – for now, there’s no organization support on the free tier, so it’s one user per project.

1 Like

What is the difference between “hobby” use and production use? Can small companies use AppGyver to create and deploy apps that they and their customers actually use, as long as they use some other platform to store the data?

If you want to use Google Sheets as the back end, is there a way to do this? A tutorial? A wizard? I.e., can someone who doesn’t know what “REST API” is do this?

For example, many platforms give you an easy point-and-click way to add integrations with Google Drive, Dropbox, etc… etc… so that a non-developer can set up a usable workflow. Is that possible with AppGyver, or you do intend that your platform be used by developers looking to speed up app creation – as opposed to non-developers creating apps for the first time using easy-to-use tools?

Thanks!
– Maria

4 Likes

The “hobby” term really only applies to AppGyver Cloud Storage under the free plan – it’s meant to be used in the phase of development where you don’t yet have a backend set up for production use. It doesn’t have any hard limitations, but we don’t ensure availability, scalability or even 100% the integrity of data there, so it’s not suitable for production use.

As for the second part of your questions – yes, small companies can absolutely use AppGyver to build any kinds of apps without limitations; the only thing we don’t provide is an unlimited production-grade backend.

We are working on more point-and-click examples and tutorials for using data from various backends; I’m planning on building one specifically for using Google Sheets with Sheetsu soon.

As for the question about non-developers vs. developers – we absolutely want non-developers to be successful with Composer, including using data from various backends, but at the same time we don’t want to necessarily hide everything behind magical wizards. Rather, we want to make the user interface and tutorials so intuitive that you’ll be able to do all the necessary steps while still keeping the developer-level advanced options available.

That said, we are considering building even simpler setup wizards for backends, but before that, we want to see if we could actually teach non-developers what a REST API is and how easy it actually is to integrate to one. :slight_smile:

2 Likes

I used to be a database developer way back when. And I write about this stuff for a living, and know what a REST API is.

However, if I need to be able to do something with a REST API, I won’t use the platform. Mostly because it will take me a long time to figure out this particular implementation of it, since I don’t use it at all in my daily life (since other platforms have point-and-click integrations). And if I go through all the trouble and figure it out, once something changes a month later and I have to go back and fix it, I’ll have forgotten all about how it works and will have to figure it out again from scratch.

Normally, when that happens in a platform, I will stop using it right then and there, even if I’ve put in the initial investment to learn whatever it was. I’m not going to spend an hour or two relearning something each time I want to make a change or fix something.

I’m not opposed to having powerful tools for expert users. And once I use a platform a lot, I do occasionally start writing scripts and using the more powerful features.

But having to do it up front makes for a huge barrier to entry for me.

I guess my ideal option would be to have easy-to-use defaults, and pre-built integrations with the top file sharing platforms. And I don’t want to have to sign up for a third-party service like SheetsU or Zapier because that will create yet another platform for me to try to learn and keep track of, and makes it that much harder to diagnose issues when they arise.

For example, I have some IFTTT workflows set up, that I forgot about. So, say, my blog posts automatically get sent to Twitter. But then something happens, and the integration no longer works, and I’m looking around at Twitter, and looking around at my blog platform, and can’t figure out what’s going on, because I forgot all about the IFTTT connector.

I do want to have an online database platform to use to replace a hodge-podge of Google Docs, Sheets, Wordpress, Filemaker, Dropbox, etc… etc… But if a new platform just forces me to add a bunch of other services that I have to manage, then that’s a deal breaker.

Right now, I’m looking at Zoho, Coda, and AppSheet. They all have significant limitations. AppGyver looks like it can address a lot of their limitations, but it has those big other ones of the difficulty connecting data sources and lack of templates. Ironically, given that AppSheet is owned by Google, they also do a poor job of connecting to Google Sheets. If you need to make changes in table structure, you have to go back to the Google spreadsheet and make them there, then go back to AppSheet and rebuild the database. On the plus side, you can just pick a spreadsheet from a list. You don’t have to use a REST API.

– Maria

3 Likes

@Harri_Sarsa. So till you are working with Sheetsu and google sheets, which no-tool DB tool can we integrate with appgyver? Is airtable available?

@Maria_Korolov sorry for taking a while to respond, especially given such a thoughtful response! I hear your points and they are valid.

Having pre-built integrations is definitely on the backlog. The tricky part is that for most of them, the proper architecture includes a server-side component (for example to securely store an API key or handle OAuth-based user authentication). This is something we do not provide yet (apart from the user management and the hobby-use cloud storage), though we do have plans to bring the visual development flows to a Backend-as-a-Service product too.

That said, we’re working on flow functions to make e.g. Google SSO very easy, after which you could use the user-specific access token returned to access the Google Sheet APIs directly. At this point, the current architecture provides two options: we can package a preconfigured REST API data resource and make it available via the Marketplace, or if the direct response is not straight away usable in, publish flow functions that include the necessary data transformations. Still, these would be equivalent to you coding the same kind of integration by hand, so if Google changes their APIs, you’d need to at least update your app to newer versions of our integration config/flow functions.

So, to reiterate, we do want to get to the point where you can just click “Data”, select “Google Sheets” or “Airtable” from the list, enter your API key (or log in with your account like Zapier does for many services), and then pick a source sheet from a list, with everything magically working both ways, but that’s still some time away. In the meantime, we’ll be taking steps to provide tutorial videos and example configurations to make it simpler and more understandable to integrate with various services’ APIs.

3 Likes

@Harri_Sarsa: Really appreciate your response. Thanks for it.

I have found out that Bubble exposes Rest APIs. Can I use it dirrectly as my backend with appgyver?

I haven’t used Bubble myself, but looking at https://bubble.io/reference#API, you should be able to use the Data API endpoints to get the data into Composer via the REST API direct integration data resource type.

Note that while the direct API key authentication mechanism is the most straightforward one, the API key is in the admin scope, so all your data and all actions are possible. Since an API key pasted directly into the data resource config will be included in the app source code, someone could extract it from there and cause damage. Thus, the secure way would be to either make a proxy server that only allows certain API calls through, or use the Login API to get a user-specific token (https://bubble.io/reference#API.authentication).

Hope this helps!

Following this thread as I have similar integration questions/requirements. If you’re planning to build out more data integrations, I’d love to see a path towards tighter integration with restdb.io as this seems like a great back end tool for managing data sources.

AppGyver Composer Pro seems great so far but the largest product gap seems to be securely integrating back end data sources (whatever those might be) combined with per user authentication to that data. If there were clear paths defined for those, I for one would be off and running.

Thanks for the feedback and suggestion! The first step we’ve got planned is to roll out an integrated OAuth 2.0 login flow function, which should enable secure per-user authentication for a huge number of APIs (Google, Twitter etc). After that, the plan is to provide example REST API configurations for a number of APIs, so it’s at least clear what the basic configuration looks like. Looking at restdb.io quickly, it should very much work with Composer.

No definite timeline for these yet, but stay tuned!

4 Likes

Harri, I was curious if you’d recommend Google Sheets or Airtable as the database to connect with the Appgyver app? Especially for an app that will have lots of data and increasing amounts of it

1 Like

Is “lots of data” thousands or millions of rows? :slight_smile:

Google Sheets has a rather complex API unless you use something like www.sheetsu.com to ease the integration, so I’d recommend you look at the API docs before committing – if they look daunting, then Airtable is probably more straightforward. Not sure where Airtable’s limitations come up though in terms of database size.

Alternatively, as I mentioned, some people have mentioned using http://restdb.io/ for their data storage, but I haven’t tried it out in depth myself.

1 Like

Airtable’s api is incredibly easy to use! well, in comparison to google’s

3 Likes

ive been asking same questions - is there anyone there to answer us? whats up with this strange company? Free services

That is true. From what I’ve read from them directly, they’re funded sufficiently by big-player clients using Appgyver Black that they’ve chosen to provide such a versatile tool to us smaller/indie-type app developers at no direct expense to us. Now, with their recent acquisition by SAP, it’s possible they may offer modular expansions (backend services, etc.) at a reasonable cost. But you absolutely can build, launch, and release your native app/web app free of charge if you choose to do everything yourself – building your own backend, for example.

If it’s any consolation, in a manner of speaking, us indie app developers have a kind of symbiotic relationship with Appgyver. We get a versatile tool to use to build our apps and, in turn, we test out and report bugs and the like to help the team make an ever more stable platform for everyone – including paying customers.

Something you should be aware of: You do own the final resulting app or web app files to release and do with, more or less, as you please. However, you sacrifice access to the deep-level source code that you would have were you to write the app out by hand.

1 Like