minzak's comments

Nice article. I'd also highly recommend "How To Design A Good API and Why it Matters" video from Joshua Bloch (co-author of Java). He digs much deeper, mostly at code level rather than JSON level but the same principles apply. Even though this video is almost 20 years old, the topics are as significant today as they were back then. https://www.youtube.com/watch?v=aAb7hSCtvGw

I've spent last 8+ years working on various booking engines for a world's major travel company. From the provided information it's a bit hard to see the full requirements so I'll just mention some of the aspects I had to deal with. Managing availability isn't as straightforward as it looks on the first glance.

There are things like:

* in-advance-known closeouts

* sporadic closeouts (e.g. due to the bad weather conditions)

* sell-outs

* varying availability by date/start time

* links to partner services who can partially reduce the availability count

* allotments (availability quotas for different sellers)

* resources linked to availabilities (which is another dimension)

* the list goes on and on...

Anyway, back to the data structures.

After many iterations I've settled with using Guava's Table (yes, we use Java). There are many ways to model this, e.g. you can have start times as rows and dates as columns.

It might not sound as sexy as you'd expect but it's super easy to visualise the model in your head and read/maintain the code later.

Then you can use Guava Range functionality for dates or times and do intersections etc. Hope this helps.

A bunch of arguments they list on their Github page are strawmans.

For example they say nobody wants to learn a new query language. I worked with Hibernate's QL as well as Ebean's QL and have to say none require any special training. Sure, the syntax differs somewhat but you can achieve what you want fairly quickly by looking at examples. And they all look like simplified SQL anyway.

Also the page says one has to invent DAO layer but again - neither Hibernate nor alternatives require this. On the contrary, for example if you look at the canonical Playframework/Ebean examples they suggest static finders inside POJO classes, which work just fine.

They've made a classical mistake of building everything from scratch. I happen to work for a company which builds and maintains SaaS system with a Marketplace for tours & activities (not just last minute), apart from other things. Dozens of super bright developers have spent almost a decade building these features they've tried to build with $209K. They could have just used us or our competitors and get a similar result for a fraction of time/budget they've spent. The rest is sales, as they say. And yes, this market is exceptionally hard to get into.