Aug 18, 2019 06:35 AM
I have a base that is a migration from a MySQL db and a web based (I think JS) app. I did not build the original and the person who did has disappeared. I am not a coder. Successfully migrated the data and created the proper links within the base, but the client really wants something pretty on the front end. The db is a list of photographs with info like size, medium, etc. and pieces sold for how much, how many in the series, etc. They want an interface to interact with the db like they had.
Is this doable and how might I go about it or might there be someone who is interested in doing the work?
Thanks in advance.
Howard Goldstein
Aug 23, 2019 06:25 AM
Sure, CSV export is one way to go. But there are some devils in the details.
No easy answers.
Aug 23, 2019 07:04 AM
Thank you nea_lpatil, but I think that would be very complicated for the client. The ultimate idea here is simplicity for the client.
Bill- still thinking about this. Appreciate your continued input.
Howie
Aug 23, 2019 10:47 AM
I can build prototype very quickly based upon requirement details with the csv option.
Thanks,
Neal
Aug 24, 2019 05:40 AM
Neal,
I’m confident that a CSV export/import could be achieved and this strategy is one that has been around and used for many decades so we fully understand it. But that’s a red flag - anything that has been around for decades is probably not going to take advantage of modern web or integration architectures or standards.
I use CSV files all the time and typically because I must, not because I can. Integrating with legacy systems that have no other option fall into this category. Some decades-old platforms can export and FTP CSV data automatically. Airtable can’t, nor should it (my opinion). APIs are far more precise for integration processes. Indeed, they are not as simple to implement, but employing them tend to make the connective tissue in software apps less brittle.
Stepping back, I think it’s also wise to define the requirements in advance of any specific implementation approach. Choosing the protocol for data sharing [now] is akin to selecting a V-8 engine for a new mall shuttle that’s on the design table.
Without knowing how this company plans to render information on the web, or how users will interact with the data, an integration implementation choice is a bit premature, right?
Aug 25, 2019 06:53 PM
API rate limit limits number of options available for solution.
Neal
Aug 26, 2019 06:37 AM
You’re conflating rate limits with design choices. It is possible to design performant web applications where API access is tightly constrained. It’s called a cache-forward design and it’s used all the time.
Imagine you have a single API account pulling records from Airtable and you need a web app that can support 10,000 simultaneous users all reading and searching the Airtable data.
Given that a direct connection to Airtable is unlikely to support the thousands of requests - many over the 5-per-second threshold - the API is unsuitable for direct use in this case. However, imagine a cache between the API and the front end. Imagine a real-time database (like Firebase) synchronizing Airtable data to all 10,000 users in less than 250 milliseconds. Airtable’s API need only update changes to a single endpoint and Firebase handles the distribution and access to all 10,000 users in near-real-time.
In this architecture, changes to the data by any single client are also synchronized back into Firebase in less than 250ms. Firebase’s real-time cloud functions handle the updates into Airtable at a pace orchestrated in a manner compliant with the API limits.
But, as I said earlier, it’s premature to conclude how wide (or narrow) the implementation approaches are until you know the true requirements.
Aug 26, 2019 03:50 PM
You may want to sign up for this beta. It appears to meet some of your needs - perhaps many of them.
Aug 26, 2019 06:04 PM
Bill-
Signed up. It looks like it might do the trick. Thanks! Will let you know how things work out.
Howie