i have heard (from multiple founders in the space) that the hosted db business is a difficult one to be in. see for reference graphcool's switch to prisma.
i suspect that mainly applies to venture backed businesses - it could be a great lifestyle biz
I'm sorry that we are not doing a better job marketing Nhost. We have been very focused on the product but we hope to get the word out better in the future. Because you are not alone. There are lots of developers with the same problem, that just want things to work.
Hopefully, we will be mentioned in the documentation for Hasura.
Hasura does provide a hosted version (EDIT: not a hosted version) (Hasura Pro). You can read more about it here: https://hasura.io/hasura-pro
1. We're working on adding nhost to the Hasura docs as a deployment guide for when you'd like authn + files + hosted postgres in one neat place. Johan just did a slick demo in the community call right now :)
2. To clarify: Hasura Pro is not a hosted version of Hasura. It's an agent that is added to wherever Hasura happens to be running for enabling monitoring/testing features.
> A very senior Microsoft developer who moved to Google told me that Google works and thinks at a higher level of abstraction than Microsoft. “Google uses Bayesian filtering the way Microsoft uses the if statement,” he said
You should write tests when building a project in a dynamically typed language to alleviate some paranoia anyway. As long as you have decent test coverage and use a decent linter/formatter such as StandardJS[0] or prettier[1], you'll be fine.
Yeah, if your linter/build tool can't handle Javascript that doesn't have semicolons, it should be considered fundamentally broken and/or incomplete.
So the question to me becomes, if the build tool doesn't correctly parse the JS that's lacking semicolons, should you really trust that build tool with the rest of your code? You already know at that point that it doesn't handle your otherwise-valid semicolonless JS correctly.
Google Photos uses ML to tag photos and this feature released amidst much fanfare at Google I/O a couple of years ago. They don't need location data to geotag photos anymore.
They took 126 million geotagged images from the web, bined them into 26,000 squares, and trained a neural net to predict which square on the earth an image was taken in. That's very poor resolution, but if you see that 20 images taken around the same time are tagged as the square that contains San Francisco, you can be pretty sure they all happened during a trip to San Francisco.
Thanks for explaining one possible method. It could still mean Google is tracking location "without consent". I suppose it depends on whether they use that location data for anything other than Google Photos.
If we want to store the object's URL in a relational database, should the browser send another HTTP request to our service? Wouldn't we lose the object if there's a network error during the interval between the two requests?
Yes, one option is to do as you've described, for example, use JS to upload the file, then submit a form as normal with a file url / id in the form.
However, you can also create a Lambda that is triggered whenever a file is uploaded to a given bucket and directory. With this, you can react to the file being received and update your database without the need for a second request.
they chose to make their own stack afew years ago instead of going with the already available and business friendly openstack, going by the same reasoning and the long amount of time they took to reach here, it highly likely to be a custom thing.
We started writing code for DO in the summer of 2011, we evaluated OpenStack at the time but felt there were four major problems.
1 - First was that it didn't really work. You could stand it up but DHCP licenses would fail, your VMs would go down, it just wasn't quite stable.
2 - Naively we thought it was a bit too complicated. Sometimes early on being naive is great and we certainly made a more simple system ourselves, however as time went on we realized, that our backend was beginning to resemble OpenStack in complexity, but we would still have more flexibility in hiding that complexity from our end users.
3 - OpenStack is designed for organizations but not necessarily to be multi-tenant. Taking any software and making it multi-tenant for different customers is a large effort, so coupling that with OpenStack not being mature, just seemed like a lot of effort to put into it.
4 - It wasn't really Open Source the way we were used to it. We were used to organic open source efforts by single developers or teams of developers that naturally grew and developed over time. OpenStack just looked like it was very much "corporate" sponsored open source, which wasn't something we felt comfortable putting our faith into.
My comment was a play on an old joke about Unix. My personal experience with OpenStack is that it's a moving target, complex and unstable, a combination of over- and under- engineering. The two large corporations that I know using it have required almost superhuman effort to keep their OpenStack environments up and running.
