StoreBookingEngineprovides the quickest and most prescribed approach. It has a very tightly defined contract, and its API has a minimal surface area - making it the most inherently stable and maintainable route for implementation. It is also the current focus of this guide.
CustomBookingEngineprovides more flexibility, and requires the implementer to do more of the heavy-lifting, including implementing error conditions and validation.
OpenBookingHelperprovides helper methods that may be useful for a totally bespoke implementation. They are designed to be used independently, and do not have any dependencies on the other two routes.
StoreBookingEngineapproach provides the quickest and most opinionated implementation. Implementers are strongly encouraged to use this approach (which is the focus of this guide, and provided examples), and provide feedback on any key gaps or constraints which would otherwise have forced them to move towards using the
OpenBookingHelperapproaches. We will move quickly to add features as required in line with your implementation timescales.
StoreBookingEnginefor your use case - reducing the cost of your implementation and increasing maintainability. Please note that we may not accept all suggestions, in cases where they are very specific to your implementation, and may instead suggest viable alternative approaches.
OpenBookingHelperclasses are not yet stable, except where needed to support the
StoreBookingEngineapproach documented in this guide. We encourage exploration and prototyping approaches based solely on these at this stage, and feedback is very welcome as we move to stabilise these over the coming couple of months. Moving functionality between
CustomBookingEngine(to make the latter more/less powerful vs customisable) is a particular area of interest.
OpenBookingHelperclasses is primarily within the codebase itself at present - separate guides have not yet been written - although looking at the
StoreBookingEngineis a good introduction to an example implementation of