dbb01

Duke Crucible | Cloud Infrastructure Engineer, Full Stack Engineer | Remote and Onsite | Durham, NC

https://crucible.duke.edu/

Duke Crucible is a small healthcare focused software engineering and data science group within Duke. We do data & application engineering for clinical research, clinical operations and clinical trials.

Cloud Infrastructure Engineer: Support our application engineers by furthering our Azure systems. Kubernetes, Istio, Knative, GitOps, Flux, Kustomize, Terraform. You like making the developer experience better within the confines of a regulated healthcare enterprise.

Full Stack Engineer: Develop full stack applications to support clinical research, trials and operations. Build data infrastructure and applications across the enterprise. Azure, FHIR, Django, React, CRA, AntDesign, NextJS, GraphQL, REST. Work with other senior devs in small teams.

crucible@duke.edu

Duke Crucible | Cloud Infrastructure Engineer, Full Stack Engineer | REMOTE or in Durham, NC

https://crucible.duke.edu/

Duke Crucible is a small healthcare focused software engineering and data science group within Duke. We do data & application engineering for clinical research, clinical operations and clinical trials.

Cloud Infrastructure Engineer: Support our application engineers by furthering our Azure systems. Kubernetes, Istio, Knative, GitOps, Flux, Kustomize, Terraform. You like making the developer experience better within the confines of a regulated healthcare enterprise.

Full Stack Engineer: Develop full stack applications to support clinical research, trials and operations. Build data infrastructure and applications across the enterprise. Azure, FHIR, Django, React, CRA, AntDesign, NextJS, GraphQL, REST. Work with other senior devs in small teams.

crucible@duke.edu

Having these features built in without having to hack them together ourselves is nothing short of wonderful. Thanks for the great additions!

In my experience SPAs are actually much more prone to bloat and the resultant performance issues. If you have thousands of components you definitely need to dive into all the complexity of code splitting and server side rendering to make your app fast. You can very quickly find that you have a 4MB JS download.

Of course each application has different needs, but for large multi-developer UIs, I think a better option is to split your front end into distinct server based pages where you leverage React/GraphQL/SPA/PWA features for great DX within those pages. That way you can keep it fast and potentially limit some of the complexity.

The neo NFC works with iPhones 7 and above

This isn't accurate. When you now pay for a year long "subscription" you own that version and can use it indefinitely. Exactly like buying a version-license previously.

The key though is that you want to use open source software that some company has provided as a service so you get all the benefits of SaaS without the lockin. Heroku Postgres for example. If Heroku shuts down or is no longer an option, you just spin up with a different PostgreSQL service provider, or run it yourself with no code changes.

I agree with the previous comments about a project like this not being open source isn't a great idea. Hard to monetize on GETs and anyone who invests a lot of time developing to the url's API will have to redo their app when you deprecate your service, as google did with the chart API.

Still, having it as a hosted service doing image charts can be great, you just need to give folks a backup plan.

This is actually incorrect. The Relay/GraphQL folks explicitly call out the concept of directly exposing your persistence structure via GraphQL as detrimental. Instead, you simply describe what your business models are with GraphQL (regardless of how they're stored), just as you would with a REST api. GraphQL acts as an abstraction layer on top of your persistence. The key difference with GraphQL vs a REST API is that you don't have to commit specific endpoints that return specific models, the clients can simply pick and choose (within the confines of what your GraphQL schema allows).