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'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 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 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).
The other way around. A homomorphism is a structure-preserving map between two arbitrary objects, whereas an endomorphism is a homomorphism where the source and target objects coincide.
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.
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.
I'm not sure how great it is for Netflix's use case but it is important to realize how very different Netflix's use case from most web apps. In general, Netflix data is read only. The only data an end user sends to Netflix that he/she cares about is current position (which certainly works most of the time but doesn't seem enormously reliable) and ratings (which you probably won't know or care if they aren't quickly or accurately updated).
If you're writing a truly interactive system where, for example, you expect multiple devices to be active on the same account working in sync then Netflix isn't paving these paths.
Falcor extensions like streaming are up at https://github.com/graphistry/falcor , which we slowly contribute back to the Netflix one. We've been loving UWS+falcor on the server talking to falcor in the client, and even smoother with node-opencl & webgl bookending them.
Supporting streaming in such a system is tricky. I think David Nolen in Om.Next wants to explicitly support it. He mentioned it in some talks, but I cant find much about it.
> Though I also believe there are better ways to declaratively describe your data requirements against a graph than either Falcor or GraphQL.
Om.Next used Datomic Pull Syntax, it seems really powerful. Im not sure how it compares to Falcor or GraphQL.
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.
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.
Have you looked into why these people fail? I see all the time claims made like this (i.e. that a large percentage of programmers fail fizz-buzz type questions), but I never see why. Are they morons, frauds, frazzled, confused?
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.
That sounds like my experience as well. We have been hiring for senior level positions and ask a fairly trivial string manipulation question (no code, just algorithm) and I have yet to see a candidate answer even close to correct. I suppose one or two candidates could have been nervous, but I expect the rest were truly imposters.
Thanks for this. I have not found this such a problem for developers I have interviewed (might be because I am hiring niche backgrounds), but for the sales area frauds are a huge problem. I wish there was the equivalent of fizz-buzz for sales people.
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.
Thank you for sharing your opinion which is really quite contrary to mine. To me a portfolio signifies where their interests are and what they are clearly capable of achieving without help.
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/