We should probably add another point which is "you probably don't need Apollo tools".
I'm using GraphQL in production since 2015 and I feel like the only Apollo contribution to the ecosystem was pushing lot of marketing content around their hacky tools and "best practices", leading teams to poorly designed backends.
Yeah, I haven't seen a lot that has been particularly useful from Apollo so far.
They supposedly have a slightly different recommended way of doing the things Relay tries to do, but it's poorly documented and only compatible with Apollo, whereas the Relay spec is relatively clear (just the spec, I haven't used the Relay library).
Also they seem entirely JS focused. Our backend is Python and our frontend so far is Swift. They have no Python tooling, and their Swift codegen has a lot of issues, our iOS devs use it pretty reluctantly and replace a lot of parts of it, and even that tooling is all in JS, not Swift, which means our iOS builds suddenly need Node, Yarn, NPM, etc, a whole load more complexity, caching, and so on.
I'm currently working on building an open source library for building backend GraphQL APIs in Python. I'd love to hear your use cases! My email is in my profile, if you're interested.
I know the ISPs are against it. To the point that Netflix essientially threatened to switch to a p2p model if the Comcast peering fiasco wasn't solved amicably.
Peer5 is actually a really interesting example of how the user experience can be improved using peer-to-peer, particularly in areas with less capable internet infrastructures - their technology _only_ kicks in if the user experience can be improved by using peer-to-peer, and it'll fallback to traditional CDNs if they can't improve the experience.
Despite this logic, they were capable of very impressive P2P offloads during the world cup. Their datasheet linked at the bottom of this blog post is worth a read for more details: https://blog.peer5.com/what-a-world-cup/ (email address needed)
>their technology _only_ kicks in if the user experience can be improved by using peer-to-peer
I'm curious on how well that works in practice.
I'd imagine there's more failures modes versus a regular CDN even after the initial decision of P2P or CDN. For example, you're downloading from another user who suddenly closes their app or whose network connection degrades. You can handle that but you'll need a larger buffer, on average, which increases latency.
My gut instinct is there's both technical and business reasons.
From a technical perspective, traditional CDNs are struggling to grasp what it means to be a CDN in the peer-to-peer space, their networks have been built to support traditional HTTP traffic, and they've been fairly successful delivering that. Adapting to cacheable peer-to-peer objects would mean large architectural changes.
From a business perspective I suspect they also see a challenge where encouraging people to chase peer-to-peer oriented solutions may increase adoption, and start to reduce the amount of traffic they're serving from their private edge as more viewers start to peer between each other.
P2P is now slower and less reliable than conventional CDNs. This is a combination of bandwidth becoming cheaper, CDNs getting better (more locations, more peering, etc.), reliable always-on desktop PCs going away, etc.
I disagree. I've seen P2P outperform traditional CDNs many times, take a look at some of the data from Peer5 I linked below around improving the user experience.
P2P doesn't need "always on" boxes in large scale live stream scenarios, which is one of the use cases where it works best. I think we'll see a lot of growth in hybrid P2P/traditional CDN in the next couple of years.
The big problem with P2P is it doubles the bandwidth cost for the end user. Not a problem if we're talking desktops in countries that aren't 3rd world (or Australia). But most mobile plans still have strict bandwidth limits. If you have 10GB of data a month, do you want to use 1GB to stream a live event for a few hours, or 2GB?
First, congrats on this work! It's certainly a lot of work to write this code, the documentation, think about enterprise offerings, etc.
That being said, I think you're inviting a lot of ill will by calling your project "the best", "in the world", etc. It's fine for a proprietary product but it feels awkward for open source projects (if that's your goal).
I think you should spend more time detailing how TaskBotJS is better than the competition in a formal document to justify your pricing. Again, the open source vs. product thing is confusing right now, which is fine for the initial release. If following an open source business model is your primary goal, I would spend more time on open source and community building and then the paying customers will follow. As of now, there isn't a lot of incentive to pay.
Finally, this work is dual licensed, how are you dealing with external contributions?
> That being said, I think you're inviting a lot of ill will by calling your project "the best", "in the world", etc.
I understand that viewpoint, and I'm definitely sympathetic to it. But I've spent a lot of time digging into this (as mentioned elsewhere--don't build when you can buy) and from my perspective I feel it's true. I'll change it when facts on the ground change. =)
You are correct in that right now the incentives to purchase are lopsidedly presented. Working on that this weekend, as it happens. Thing is, though, TaskBotJS is super useful, right now, as its open source release, and because it's super useful (I'm using it now on a project to make sure I keep tabs on how the developer experience of the OSS release feels) I wanted to get it out there for people to play with.
Which is why I am comfortable dealing with the lopsided nature of its marketing for a bit. The reason that I'm offering a pro version with feature gates is largely because 1) I want to use this for the long haul, 2) financial incentives need to align for me to be able to spend time on it, 3) I'm that convinced it's that good, and 4) selling pure support without a "you also get feature X, Y, and Z" is a conceptually more difficult road.
As a consultant I pretty regularly find myself going "you might want to consider Sidekiq Pro, because of support and also because batches will save your bacon", to which clients look at it, try it, and are comfortable paying for that (and also getting the support that, IMO, they need); I am doing likewise.
> Finally, this work is dual licensed, how are you dealing with external contributions?
I have a CLA and a rights grant I need to wire up to GitHub. Which totally does exclude some people from contributing, and I realize that. I built this with the expectation that I would be the overwhelmingly primary committer and I expect most open-source stuff to be plugins, etc.--people scratching their own itch, as I have with this.
It's a weak signal for the maturity of the ecosystem around it, but it's a signal.
It's hard to define what's "the best in the world" so users are totally justified in looking at different metrics to figure out what that actually means, if there is no clear defined metrics to compare against.
Nice tutorial, just not found of the authorization part, which "encourage" you to rely on http headers.
Imho http headers are fine for a REST API, since the protocol depend on HTTP, but not for a GraphQL API since you can perfectly serve GraphQL behind something else, like Websocket, nats, or even direct TCP
Thank you for your comment. You are right and I admit I didn't come with another solution at this time. This is why I did not write a huge part about authorizations.
Great pricing, but literally no customer support.
Week's ago I wanted to change my billing address, I was surprised not to find the option within my account settings, so I asked customer support to do so, whom replied that they simply can't do it.
I can just close my current account, then recreate it with my new address and of course, there is no migration tools.
Having experience with both on Node back-end projects, I can tell you than IMHO Flow is smarter, especially on union types, BUT there are way more TS community type definitions available right now.
If you use discriminated union types - e.g. give them both a type key which is a unique string, then you don't need type guards as typescript is smart enough to understand that checking the type key does the type discrimination.
You're right, every city I used to live in France, I had at least 1 Monoprix within a short walk distance. Where I currently live, I can get to 3 different Monoprix in less than 10 minutes by walk.
Never seen a Monoprix outside of a city anyway:)
As many of my friends, I love to eat and I love to cook, but unfortunately, my time, kitchen room and budget is limited.
So I prefer by far for the same time/budget having let's say 3 poor (joylent/queal) meals and 1 excellent meal than 4 passable meals.
Yeah, I definitely realize there's a big tradeoff here. I try to cook extra for each dinner, so that my lunch the following day is leftovers. (3 sameish-meals in a row is rough but 2 is fine by me).
Another thing that's been helpful is big roasts. turkey breast, pork shoulder, etc are very easy to toss a quick seasoning on throw in the oven for 2-6 hours, plus are pretty cheap ($2-$3 a lb, though a bit of that is bone). Gives you some meat to work into all sorts of things for the week with pretty low effort cooking.
With that, a carb staple and random sauteed veg you can get pretty far.
I don't understand the budget angle, at least if it's referring to the financial budget. One of the first tenants of financial counseling for people who are struggling to pay their bills is that they have to quit eating out immediately. Dave Ramsey has a quip on the radio about that the person who is getting out of debt should not see the inside of a restaurant unless it is his or her second job.
Kitchen room doesn't need to be big. In fact, a small kitchen can be a plus as long as it's organized: it's like the bus is faster between the processing and storage units.
If you look at some of the traditional kitchens in the South of France (just as an example), you'll see tiny spaces with very small counter spaces and limited cooking/sink areas and yet awesome food come out of those kitchens.
I'm using GraphQL in production since 2015 and I feel like the only Apollo contribution to the ecosystem was pushing lot of marketing content around their hacky tools and "best practices", leading teams to poorly designed backends.