4 ms·

I looked at a few companies in this space when I was at a VC, and the fundamental problem was that they didn't provide enough value to the end developer. Aggre

by ig1 12y ago

I looked at a few companies in this space when I was at a VC, and the fundamental problem was that they didn't provide enough value to the end developer. Aggregator APIs tend to provide extremely reduced functionality compared to the source API, and the ease-of-use doesn't compensate for this. In most cases it just makes more sense for the developer to spend a day building a custom adaptor for the API. That said I think the SQL front-end is an interesting twist. While developers find it easier to use the source API there are many people (i.e. business analysts, etc.) who can't program but can use SQL and that might be an interesting market to go after (and also a market more willing to pay).

bravura 12y ago
Thank you. The pure SQL is a cool twist, because you can instantly start getting fancy, e.g. doing JOINs between different services. In terms of value to the end-developer, there are a handful of value-add services we'll be rolling out that are a pain for people to implement: - Authentication - Federated search - ETL / caching - Record matching / fuzzy inference of foreign-key relationships - Entity de-duplication We also feel that Empire API will be exciting for pure client-side apps and apps that don't want to run a backend, e.g. the sort of apps that would build on Parse or Firebase.