Thanks for taking the time to review and comment.

YADA doesn't abstract any underlying system, it abstracts access to the underlying system. You can think of it as a pluggable web service that you slap on, say, a legacy warehouse, except it can also reach into any other system, enabling access to data using the same standard syntax.

It's like a BI or ETL tool in that respect, except those tools wall off the work you've done and limit repurposing. BI tools generate reports and that's pretty much it. You couldn't, for example, point Spotfire to Cognos, you'd connect them both to the db instead, distributing the credentials, and possibly construct the same query in both places using their interfaces. With YADA, you could instead write the SQL once, and get the data from anywhere.

I do agree with your sentiment however, that as innovators we always think there is a better way, or more commonly, that their _must_ be a better way, because we don't understand the problem fully, or grasp the complexity of the current solution. Often we discover we're not the first to think of a great idea. I'm sure there are similar tools to YADA, but I also think YADA has potential to offer a wide array of users some options and combinations of features that are distinct in the marketplace.

As a tool for data analysis I could see using something like this, but I don't think I could ever write an application on top of this. At the low levels you are running on top of hard-coded native DB queries, potentially across multiple data sources. What happens when you are 100's of queries into a project and someone needs to change the underlying data structure? That is a shaky foundation.

Thanks for taking the time to comment. You're basically rephrasing the hammer cliche, which is accurate. First though, as your first sentence indicates, you agree we still need hammers. Right now, YADA is a great tool for prototyping, adhoc reporting, data analytics, ETL, and smaller SPJAs. One testament in our environment has been to repurpose the work we do for one endpoint in another, e.g. webapp and spotfire, or vendor app and ad hoc reports. We are working with a high-volume machine-learning group, so eventually we expect to be able to scale.

Which is why JSON for non-indexed attributes is useful.

There's another point in your development career where you realize that strings, numbers, maps, and lists are not nearly enough data types for more complex work. Of course, first you'll have to go through the phase where you fight to make them fit into those four types simply so you can use JSON.

Even when those four types are sufficient, you'll frequently find there are better ways to handle storage and transmission than serializing the data to JSON.

Then eventually you give up on all that and try to focus on building a datetime library that works the way you want it to.

Yup, done that one too. Ended up falling back on using the Linux zoneinfo database and accepting that I'm unlikely to do better (and keep up with it, no less).

I would _highly_ recommend never to do this. Date/time is complex in so many subtle ways, least of which is staying up to date on changes. Because its so fundamental every language is likely to have a mature, maintained, and roughly canonical library to use.

But what about JSON web tokens?