We've been working on doing something similar to create "one graph" at my job (though using our own library instead of graphql [1]).
There are definite difficulties to doing this, you need some strong cohesion between teams. If you try to do it in an agile manner, you're going to end up with a lot of duplication with minor differences. You'd need a way to flag existing similar data when trying to add new branches and nodes.
Our hope is to make our graph explorable and interactive so teams we don't have direct contact with, often in other countries, are able to find the data they would be interested in and see immediately how to read it out.
The SPA improvements look to have been released as the new `Browser` package, there's some good stuff in the guides on it - https://guide.elm-lang.org/webapps/
Gatsby produces static html sites and then rehydrates them once loaded, which is what makes it feel so fast. Elm dynamically generates the html.
There has been some work to generate static html from Elm - https://github.com/eeue56/elm-static-html - and there's no technical reason I'm aware of that prevents it from being taken as far as Gatsby does.
I haven't, but had a chat with Zoltan on twitter (a dev on it). It does seem to be pretty good, and definitely would be a less drastic solution since it builds on top npm.
I'd disagree they are naive. These all stem from my team's experiences developing platforms at a large international bank.
We have dozens of packages that share many of the same dependencies, moving those to a single copy of each would reduce used disk space by equal dozens of times. But saving disk space is almost more of a nice side effect of the other solutions.
We've tried reducing this by using lerna but that can only go so far due to only supporting a single shared version or fully independent versioning. Hence the more customisable workspaces.
I'd also contend this is not a narrow use case, every bank in London is building similar platforms and could benefit from something like this. They just tend to not talk too publicly about what they are doing.
I believe homomorphism is a subset of endomorphism.
So a function that turns an array into another array of different length would be endomorphic (since it maintains the same type), but not homomorphic since it has a different structure (a different set of keys).
Looks great and useful! One small UX issue I've just hit - I missed the "edit" button in the "Personal Information" box when viewing a contact for a few moments. Kept trying to click the "Birthdate is not set" etc text.
Our approach is being influenced by Om.Next, though I personally don't have a great deal of knowledge of it.
I'm a fan of Elm, and it and Om.Next share some significant concepts I believe, so that's been guiding a lot of my thinking with regards to this stuff.
Falcor is a very interesting approach, and as others have mentioned GraphQL is very similar. I can't go into any details, but we have been using Falcor on my team as the basis for our own work. We are gradually moving away from it though as it has become clear it is great for Netflix's use-case but less so for a more generalised solution. Particularly when you throw in streaming data.
I have a sneaking suspicion that the open sourced version of Falcor also isn't the version used internally. This is certainly true of their Prana (a sidecar used to allow a node app to talk to the rest of the Netflix stack). And the repo has had a massive slowdown and basically ground to a halt in the past year - https://github.com/Netflix/falcor/graphs/contributors.
So saying that, I'd have reservations about recommending it for other developers to use. The concepts are great, but GraphQL is more widely supported and discussed. Also the Falcor docs could use some serious work for clarity.
Though I also believe there are better ways to declaratively describe your data requirements against a graph than either Falcor or GraphQL.
It may be a difference between contractors and perms, but it seems not many actually have a github or similar portfolio. We're more interested in their previous experience and if it is relevant (fintech specifically) though.
We probably should check it out for those that have one to be fair. But I'd rather it didn't factor in as a implicit negative for those who are too busy to work on projects outside of the office.
Of the 6 tests I've personally run, 1 passed decently, 2 were probably affected by nerves, 3 just weren't capable. We've had >30 people come in so far and offered to 3 or 4 I believe.
The test is essentially writing a function that can take any number of numbers and add them together followed by a couple of bits around javascript's built in functions and object syntax.
1 of the failures couldn't write a for loop despite having 5 years experience including React.
The test also works as a general personality test as we need people who are fully confident in their abilities due to the difficultly and scale of the product. We are specifically aiming for the top 20% of candidates who come in, so there are subsequent tests after this one.
I thought I'd be able to spot a bad CV, but it turns out either people are lying or they are crediting other people's work to themselves when they are able to hide amongst the team at large organisations.
We've been running a very effective initial filter coding interview that simply tests the very basic ability to write loops, refactoring and a little recursion. It's astonishing how many people with CVs of 5+ years professional contract experience in London fail this test. We've had a <15% pass rate on that test alone.
Personally I'm not a fan of taking these interviews, but now being involved on the other side I've seen how essential it to filter out those who don't actually understand how to code.
I'm naturally a late sleeper, I travelled from UK to California then Floria for a couple of weeks and found I pretty instantly became a morning person in the new time zone.
Though I'm not sure if that is down to exhaustion from a 23 hour journey forcing me to sleep earlier and longer for a few nights and thus re-jigging my sleep cycle.
There are definite difficulties to doing this, you need some strong cohesion between teams. If you try to do it in an agile manner, you're going to end up with a lot of duplication with minor differences. You'd need a way to flag existing similar data when trying to add new branches and nodes.
Our hope is to make our graph explorable and interactive so teams we don't have direct contact with, often in other countries, are able to find the data they would be interested in and see immediately how to read it out.
[1] https://dwstech.github.io/muster/