When I, Nick Brooks, began travelling South East Asia as a remote worker, I'd try and scope out a cities rental situation before I hit the ground. This information is readily available - scattered across the internet on sites like Facebook, YouTube and personal blogs. A lot of great people put good time and effort into providing this information. It's a unique rental requirement, somewhere between nightly hotel accommodation and renting for 6-12 months.
There wasn't, however, one central repository for this information. A way to easily document, query, update, filter and compare this data. Something like most travel accommodation sites like AirBNB have...
The aim of Homadic is to make it easier to find great accommodation ahead of time, or even when you've hit the ground in your new city.
Homadic is also crowd sourced allowing it to be community driven. All data comes from fellow remote workers and travellers who have done it all before you.
Users can sign in, add a new listing or update an existing listing, add photos or reviews with the information they know about places.
Further to this, Homadic itself will poll location services for futher information about what's around a listing. Nearest subway or train station, nearest convenience store, nearest laundry and how long it will take to walk or drive to them. Soon you will be able to filter on these data points.
At the moment, to avoid a million different places being loaded in, the Google Maps Nearby Places search only fetches places with the selected keyword or type attribute. If you can't find your place here, the best thing to do is add the lodging type to a place by suggesting an edit.
Let me know if you can think of a more comprehensive way to find lodgings.
You can find out what we're building next by browsing the new feature label.
- React
- React Redux
- React Router
- Webpack
- Google Maps Javascript API
- Moment - Handle date and time objects.
- Axios - Http requests.
- Marked - Renders Markdown on the client.
- Others
Homadic is 100% serverless. Using Azure Functions and a combination of CosmosDB and Table Storage for data and file storage means I manage no servers and can focus on faster development!
Azure Functions handle all HTTP requests, queue functions, timer functions and other events.
The goal with all functions is to, as best as possible, only perform one task. If another task needs to be performed, add it to a queue and let another function pick it up from that queue.
HTTP request functions perform only the necessary tasks and then provide a response to the user as quickly as possible. Further tasks are sent to a queue in Table Storage which is then picked up by Queue Functions.
Queue functions are functions that need to be performed as soon as possible, but not critically. Examples are flushing cache, processing an uploaded image, regenerating listing description etc.
Timer functions are functions that need to be performed at a certain interval or a certain time of day such as updating the exchange rates in Table Storage each day.
CosmosDB is a schema-less document store allowing unlimited storage of JSON documents. This allows me to store anything I like, change how the data is structured and run complex queries with fast results. CosmosDB at this stage is used purely to store and query listings.
Azure Table Storage is a key-value store and is used to compliment CosmosDB. It includes information about images, reviews, users and basic data about listings for quick read access as well as some application logging to monitor errors and other circumstances.
It also is used to cache endpoints to 1) increase speed fetching a listing and 2) reduce the load on CosmosDB. When a listing change occurs, it will flush the cache and fetch the listing, a summary of reviews and the images. All listing search queries are cached for 5 minutes too. This is why sometimes an update to a listing isn't immediately reflected.