Will AppGyver support my app idea?

I would like to build an app with the following requirements and am wondering if my requirements are supported and/or what high-level trade-offs or architectural considerations will need to be made to be successful on the platform.

  • App users will register, sign-in, add and track their individual collection of widgets
  • Widget have custom metadata, including custom images uploaded by a user
  • Users can browse others users’ widgets
  • Users can make and respond to widget trade requests
  • Users can rate transactions

It’s not too unlike craigslist or OfferUp except it’s not as broad in terms of the kinds of widgets being traded or sold.

Secondarily, I would prefer to use a 3rd-party as my primary source-of-truth database (like AWS RDS or my own SQL db), but I’m open to using AppGyver’s data platform so long as I can easily migrate my data whenever it becomes needed.

Is this kind of widget trading app feasible with AppGyver? Are there any challenges, limitations or considerations that I might need to keep in mind specific to how AppGyver works when designing the app?

Thank you!

As long as your backend supports all the necessary requests via REST APIs, there’s nothing to stop you – this sounds like a very good match for Composer’s capabilities.

What do you mean by my own backend? I know what a backend is, but why must I have my own? Are you saying that I can’t build the data brokering / messaging within the app?

Am I understanding that AppGyver only provides a way to build a UI ontop of an existing API?

At the moment, the app builder is very much focused on frontend, so instead of coding a React web and a React Native project by hand, you can use Composer. You can get started with the AppGyver Auth for authentication and AppGyver Cloud Storage for data, but for a production-grade app, you’d want to use your own backend through the REST API integrations you can set up in Composer.

We are working on a full Backend-as-a-Service offering that will seamlessly integrate with Composer, but that’s still some months away.

Ah, that’s a real bummer. I’d argue that the AppGyver marketing is misleading. It says right on the homepage: “You will never go back to coding.” - that isn’t true since AppGyver is designed to work with a backend that presumably many people, myself included, will need to code.

Anyway, you answered my question and I appreciate that. Have a good one. I’ll keep an eye out for that new service.

Yeah, fair enough feedback, I can see the confusion – it is very clear to us that once we can offer a comprehensive backend-as-a-service functionality, the out-of-the-box use cases become much wider, so we hope to get there sooner than later!

We have worked to make the REST integrations as straightforward as possible (and the configurator doesn’t require coding), so if you’re using e.g. Airtable or some other no-code backend platform for your APIs, then the whole fullstack development experience IS something where you don’t have to go back to coding. :slight_smile: But your comment still stands!

1 Like

At @iheartbio, while many backends require some coding there are some few ones that require no coding at all.
Take a look at Bubble (personally will recommend this) and Backendless.

You can use AirTable to store the data and it’s pretty easy to pull data from AirTable -without needing to code- into AppGyver. I made exactly something like you are describing (browse and trade widgets with matching of categories and varieties of widgets), but switched to another platform for certain reasons. But it’s certainly possible to implement with AppGyver. I launched an alpha this weekend. Message me and we can discuss.

Sorry for taking such a long time to reply. I appreciate the responses. @Harri_Sarsa, I’ll be sure to keep an eye out for that backend service. Sounds really interesting and as a software engineer, I’m curious to hear how it’ll be architected.

@SeanHoots Thanks. I’ll check those out!

@Nihal_Parkar I’d love to test your app and hear what you’ve learned that might help me save some time. I’ll shoot you a pm now.

I realize this thread is already a couple of months old, but as I search for the right low-code / no-code platform, I came across it. Candidly, I’m currently reviewing a variety of tools such as AppGyver, Mendix, WaveMaker, bldr, retool, etc.

For context: my career spans several generations of code development and technology – but I’ve also focused my own, and my teams’, efforts on Rapid Application Development (RAD) tools. When mainframe developers would spend two years building mainframe applications, my teams learned APL and cranked out super slick user friendly applications in 2 or 3 months. When Windows developers were wrestling with the complexity of C++ app dev and slow compile times, my teams used Borland Delphi to create gorgeous compiled native Windows apps in a fraction of the time.

I’m looking for the same concept now with low code – and no-code with an option to tweak internals when needed – tools. It seems that the tools I mentioned, and many others, hover around the area, but seem to either fall short in one or two respects, or have a pricing model that limits practicality of the solution, or introduces a level of vendor lock-in that many CIOs will find onerous.

I suggest that the low code / no code vendor who gets this model right will win an enormous market.

It seems that tools like AppGyver, Mendix, Bildr, Bubble, etc. get the UI portion down nicely. An immediate red flag for me, though, comes up when I see that need to bind app components to either REST API’s, a vendors proprietary data storage, or only one or two 3rd party DBMS’s. API’s require coding. They can certainly offer benefits, but also limit app developers to only the functionality and data views that the APIs publish. Horribly limiting. For contrast – I urge all of you to look at the way tools like Delphi (originally Borland, now Embarcadero – brilliant beginning and architecture, but poor business practices killed their market position, and now their pricing is suicidal), and also look at Retool – I mention these both, because they follow a similar model: a simple but effective UI designer, data “controls” (grids, drop downs, etc.) that bind with data “sources”. Sources can be a data table, e.g., from any relational database, a SQL query, etc. The is NO NEED to have a developer write a REST API. You can do it / use one, when needed, but by default, it’s simply not an issue. This speeds development significantly, removing yet one more layer between the developer and the end result. I urge vendors to look at the development cycle / model for tools like Delphi and Retool.

Finally – pricing: Platforms that tie pricing to arbitrary metrics like, “number of items”, “number of rows”, etc., take themselves out of the running immediately for a huge subset of users. One of my teams is building next-generation pharmacovigilance / drug safety software, and the databases we’re using typically have millions of rows. Tools like Retool look great – but concern me greatly with runtime licensing tied to a per seat basis – that truly limits it to in-house apps, but make it infeasible to deploy for a million user publicly accessible application. Why would you, as a vendor, create artificial barriers that limit your adoption?

I urge vendors to think about the whole market, and about your user base and all the use cases. I see wonderful innovation and creative thought across the market, but a certain degree of myopia that’s limiting the potential of virtually every product in this space as of today.


1 Like