|
|
|
|
|
by QuercusMax
857 days ago
|
|
I work on healthcare at Alphabet, and in late 2016 I set out to build a flexible DICOMweb STOW-RS receiver in the form of a GCP API - the first time anyone had done that at Alphabet. (I've worked on the same project across Verily and Google). In the process I researched and built a bunch of little prototypes built in a variety of ways, and for example had to rule out building it as an App Engine API - because DICOMweb uploads can potentially be gigabytes in size, and App Engine didn't support handling a POST as a stream as it arrived. At any rate, along the way over the course of 9 months or so I found a technology stack that supported all my requirements and ran into a bunch of roadblocks. Lots of things related to how internal bits of GCP APIs are handled - the internal libraries had documentation indicating that streaming APIs were supported, and that each chunk of the request would be passed from the API proxy/backend multiplexer to the actual API server as they arrived. This worked for streaming responses, but not for streaming requests, and so I had to add that functionality to the API proxy. That was a huge pain - really hairy c++ code using fibers with multiple layers of request processing wrappers. But I worked thru that and got it landed into the google-wide binary, and never worried about it again. I got this project to the level I needed it to support the precise requirements for the (regulated medical device) system I was working on. Around this time the GCP Cloud Healthcare group was getting started, and they built a new system using a fair number of bits of my implementation, which they'd eventually replace completely. But my first system saved them most of a year or work, resulting in the CHC feature set rapidly leapfrogging what I'd built. |
|