Quit scraping your own data and maintaining scattered SQL statements

Sign up for our API now!

The concept of a Database-as-a-Service isn’t new. Lots of people use them; but always in tandem with a database of their own. We think that should change. In fact, curated Databases-as-a-Service should be a de-facto part of the tech landscape.

At Semantics3, our goal is simple. We think that eCommerce startups deserve the chance to build great applications and sites, without having to worry about getting the data to populate their applications. That’s why we built our eCommerce product and price database, with a standardized, normalized data response and query framework, freeing you from having to build a database from scratch.

Think about it: Managing a database is a startup’s single biggest cost, after engineer salaries. Scraping that data, cleaning it up, organizing it, and delivering it in an acceptable time can be the biggest problem to solve for startups, one that can often demand the full attention of an engineer (and think about the cost of that too!)

In fact, even if you manage to build your own database, scattering SQL statements all over your application will only cause future headaches as your DB undergoes the inevitable schema changes.

Worse case, even IF you manage to create your own database, maintaining that data freshness is going to take up much of your time.

This is why an API is almost always better. You’ll get significant benefits in terms of reusability of the data and portability of your code, as well as avoiding coupling between your app and the database.

In fact, by utilizing a database API that has a standardized form of query and response, you almost never have to worry about data management. And guess what? You can free up that engineer to work on the stuff that actually matters — creating awesomely creative products that make the world a better place.

Many modern websites use JavaScript (AJAX etc) and then make service calls to an API. If you took that approach you would simply have a carefully designed, reusable API layer in front of your DB.

If you're worried about API response times especially when considering the options of:

website <-> database, vs

website <-> API <-> database, or

website <-> API,

the differences in response times can be very little. Semantics3's API has been optimized to provide responses in subseconds, while some poorly managed databases could result in multiple second response times.

In fact, given the extra time and effort required to build and maintain your own product database, I’d be sceptical that you’ll incur noticeable performance penalties.

Check out our API here

Some resources:

Avoid Using a Database as an API Integration Point
Before I begin, I should clarify what I mean by using a database as an API integration point. In another life in a…haacked.com

Which is better: {REST API, website} --> {database}, or {website} --> {REST API} --> {database}?
I have a product that gathers and displays measurements of all kinds (won't go into it). The display portion is, as one…stackoverflow.com