Best to unify the process architecture when you can.įeel free to describe your desired latency and scale of the app and I’ll put a finer point on this topic.Building a successful business, especially a small one, means getting the most out of the time your team spends working. Spreading this architecture over multiple systems (Zapier, Server, Client) is not ideal - the complexities create many points of failure. When faced with these challenges at the client, developers often escape this madness by using server-side script - i.e., the client browser is always listening to the server for updates, and the server is always polling Airtable for new data. Airtable.js certainly achieves this - it is a single client-side SDK that talks directly to the Airtable API.īut it requires all the logic to be running on the client so you will likely encounter some issues with security, processing performance, and the brower support headaches (i.e., different browser vendors support javascript differently). In my view, the most reliable and less brittle way to achieve what you want to do is to try to eliminate as many moving parts as you can. Depending on the nature of the application you are building Firebase and PubNub may be overkill, but they are both near-free (and free at lower tiers of volume). Another technology that makes this possible is PubNub, a real-time data streaming network. This is best achieved with sockets - a technical concept that sustains an open connection between the browser page and the database.įirebase is famous for this capability and I use it often to achieve near-instant replication of data from servers and disparate services. Indeed, in a real-time climate the objective is to simply synchronize the data between the table and the browser web page. Ideally, you need a real-time architecture for data updates and synchronization to the browser. And with each look, Airtable.js must make a new call to the Airtable API to see if anything has changed in the target base/table. They are not impervious to each client’s available memory and other environmental conditions. This is not ideal because timer loops – in general – are fairly brittle machinery for the web. This is required because web pages are pretty dumb - they don’t refresh data unless nudged at an interval that matches the minimum latency tolerance for your use case. In this case, you could use airtable.js, but it would require a relatively complex web page that uses a polling interval established with a timer loop in the javascript running in that page. Let’s assume by “live” you mean updates should appear on the web page in less than a minute. In any case, it’s a good idea to consider the latency tolerance before choosing any specific implementation approach. A camera has to recognize the attack and report the event in less than 1/2 second to be considered “live data”. Others, such as the transit center in Los Angeles hold my company to a much faster standard when a bus driver is attacked - 500 milliseconds to be exact. Many users think they are getting live data when it’s never older than 5 minutes. When you say “live data”, you should qualify this by narrowing down the latency your users are willing to tolerate. I believe Integro requires you to add date/time fields to expedite the polling nature of this objective by limiting tests against tables based on recent polling intervals. While integration services like Zapier claim to support an event-like behavior (i.e., a new record is added and near-instant updates are processed), they are only mimicking an event-like behavior. Lacking these features, we must poll for changes. These are necessary to create truly responsive integrations. Updates into web pages require a definition since Airtable doesn’t provide webhooks or event handlers in the API.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |