During most of agileBase’s life so far the focus has been on making the user interface fast, friendly and flexible. Over the past couple of years we’ve been getting a real feeling from customers that we’ve cracked it, which we’re really pleased with.
Now, we’re concentrating on making life easier for developers who want to integrate agileBase into workflows, websites and other software within customer enterprises.
A lot of the work that people are doing with agileBase involves integrating the platform with other systems, particularly amongst larger enterprise customers. The agileBase APIs are instrumental in allowing data to be easily inserted, updated and extracted. The standard JSON format makes it easy for developers to get to grips with querying data to import & export from third party systems.
Over the past couple of months we’ve been having conversations with partners who are setting up customer systems to see how we can make integrations (always the most time-consuming part of any software project) better.
One thing that has repeatedly arisen is the naming of objects in the system. To the customer, fields have nice, easily understandable names, however behind the scenes, a field such as “Name” may have a randomly generated ID like “phhkog1j1nubhipmt”. When dealing with lots of views, tables and fields, these references can get confusing to developers, because you can’t easily see which ID corresponds to which field.
So we’ve now made IDs a bit easier to understand. When a field is created, the internal ID will now match up more obviously. Continuing the above example, “Name” would have the ID “name_phhkog1j1nubhipmt”. As you can see, the randomly generated part of the ID is still there, because field IDs have to be globally unique, but the prefix makes it easy to identify.
Note that if the field name’s changed in agileBase, e.g. “Name” to “Full Name”, the ID won’t change with it – IDs have to remain permanent otherwise changing names may break integrations.