Neat. I like the fresh take on validation. It’s not necessarily unique, but it may be cleaner / more efficient than previous attempts. The mixing of backend processing and the http layer reminds me of my CouchDB days. @stream seems potentially tricky to implement at scale but very useful. And a few nits here and there (eg maybe return a 202 instead of a 200 on accept), but overall pretty slick. Any numbers on performance and/or scalability in production?
@stream is actually straightforward in Node; it’s just part of the http request. Typically Instant API waits until the full request is processed to return headers and body as the endpoint implementation could modify headers; but with streaming headers are sent immediately and then the rest of the response streamed with .stream() injecting text.
In serverless environments — where we have used the framework as a gateway with endpoints being executed inside of Lambdas — streaming is accomplished using Redis broadcasting and channels are managed via UUIDs. We may open source this at some point but an enterprising engineer could fork and implement this.
Re; scaling. As mentioned in README we’ve scaled horizontally to 100M requests / day or about 1,157 RPS without issue on older, proprietary versions. Candidly this early release is designed for usability over performance but I wouldn’t be surprised in either direction. :)
It's also popular to price a seed round (from 500k up, in my experience) using the "Series Seed" legal documents that are close to boilerplate now. As a founder turned investor, it seems that those docs could be streamlined into software easily. Most of the terms are standardized at this point, aside from board seats.
Yeah, I just saw that on their youtube video; the sides can remain open during operation to allow etching/cutting of materials larger than the enclosure. That means human access is possible, so therefore the class IV.
Take a look at the specs -- you can either vent them out a window or buy the air filter (which I'm guessing is a fancy charcoal scrubber, don't know for sure).
This one I actually know -- biohazards depend on more than just wattage -- spot size, wavelength, pulse characteristics, etc, all go into it. I think you really compare them based on the Poynting vector. Disclosure: I'm a GF backer and am a card carrying physicist who had this question on his qualifying exam in grad school. https://www.rli.com/resources/articles/classification.aspx
Good question, I _think_ the ideas is the exact opposite -- you're not depending on Glowforge UI to be backed by a startups servers, the software runs on google cloud instead. Pros and cons, obviously, but I think the main pro is (like a Tesla) the machine's performance and usability can be improved without you installing any new software. As far as dependencies go, google's probably the best possible choice.
> you're not depending on Glowforge UI to be backed by a startups servers, the software runs on google cloud instead.
What? Who is going to pay that bill? For example, Glowforge goes out of business... Google isn't going to continue to host and maintain that software out of the kindness of their hearts.
> but I think the main pro is (like a Tesla) the machine's performance and usability can be improved without you installing any new software.
What does the UI being web-based, and "in the cloud" have to do with it's firmware?
For example, if the UI wasn't hosted on some google server, instead existed within the device accessible via WiFi (like a router) nothing you've said here would be any different... other than the user being able to decide themselves if they _want_ their device updated.
Not defend something needlessly cloud based, but this:
>but I think the main pro is (like a Tesla) the machine's performance and usability can be improved without you installing any new software.
is likely referring to them updating their cloud infrastructure, not the machine. By centralizing the processing and whatever else, they can ignore some local machine updating.
Its not worth the massive drawbacks, but its likely the truth wrapped in that marketing speak.
A bit off-topic, but you gave me an idea: What if Google did guarantee to host stuff forever when startups go out of business? It would eliminate customers' reservations in cases like this, and hence eliminate business reservations about going all-in on cloud services. The increased business could potentially more than cover Google's cost.
The trick would be the care and feeding of the software. But as the industry moves to more immutable infrastructure -- especially stuff like AWS lambda and JAWS -- this will become less of an issue.
That part is, in my experience, vanishingly cheap if you're not doing high rate DB transactions. The whole thing could clearly be moved to other managed hosting providers or private servers, and I'm sure ultimately you can run a somewhat constrained version on the device itself. That said, launching in the cloud seems like the right choice temporally (time-to-market) and economically. Focusing (sorry) on building the actual device seems like a reasonable choice to me.
I ordered one, wish I could pick it up in person instead of paying the shipping. Particularly interested in seeing what one can do with just a pen and skipping the computer design stage...
