Live data from Hacker News

GitHub announcements: Marketplace, Apps and GraphQL API

github.com

101–110 of 166 posts

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#101
post #75

Earlier quoted context omitted.

Please don't. Issues are for bug reports and are not a support forum. If the repo maintainer asks in the README that usage questions should first be asked on Gitter, Slack, or Stack Overflow, please respect that request!

Where does a "hey, I have this idea, could send a PR if you like it" goes? And what if the maintainer does not talk about any forum in the README? (What is, like, some 90% of the repos.)

That's why I wish every project had an IRC channel or something - it's a PITA trying to contact a maintainer or project creator because they don't always include their email and github doesn't have private messages.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#102
post #68

The shameless support posts by execs/founders at launch partners are slimy! You guys should be ashamed. This isn't your marketing site, it's for discussion.

So what the hell is "Show HN" but marketing?

This isnt a show hn

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#103

Earlier quoted context omitted.

>this subtly piggy-backs on it towards lock-in for tooling FTA: "More than a dozen integrators have apps in GitHub Marketplace today, including Travis CI, Appveyor, Waffle, ZenHub, Sentry, and Codacy" Travis CI and many others were widespread prior to this marketplace. Seems to me that creating a marketplace is a logical way to collect these third-party services in one place.

...and charge the going market rate of 30% of any revenue earned via the GitHub platform.

TravisCI Pro Bootstrap direct is $69: https://travis-ci.com/plans

TravisCI Pro Bootstrap via Github is $89: https://github.com/marketplace/travis-ci/plan/MDIyOk1hcmtldH...

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#104
post #33

Earlier quoted context omitted.

I have, a lot, and when I could only GET kinds of hierarchical data instead of lumping nested queries, I turned to graphQL (or a, er, homegrown subset of it - it had just been announced) to fill in the gaps. It turns out that most software doesn't, really, care about asking for or updating 'state' per se , and the amount of awkward munging you have to do interpret every kind of query as 'asking about state' is, in my…

Again, the problems you describe with REST are a limitation of your implementation, not of REST itself. GraphQL itself is built on top of REST via a single GET/POST query endpoint. The difference between it and typical REST implementations is that the resource identifier and fields to return have been moved into a novel query syntax. However, the same result can be achieved with a typical REST endpoint combined with…

When you say that GraphQL is built on top of REST, are you sure you're not mixing up REST and HTTP? Replace the hierarchical URI structure from REST with a 'novel query syntax' and all that's left is pretty much just the fact that both are ways of fetching data using HTTP methods.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#105
post #22

Earlier quoted context omitted.

REST and GraphQL are two completely different things, and one is not a replacement for the other. REST is an architectural concept, whereas GraphQL is a query language spec. https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...

That's true in theory, but in practice REST is a (limiting) spec for the kinds of verbs you're allowed to use between systems, and graphQL is a significant and much needed expansion of that.

> REST is a (limiting) spec

Nitpick but REST is not a spec to begin with. It's a set of ideas. There is absolutely no normative REST spec. Developers as of today are still debating what REST is, for better or worse. GraphQL IS a spec, like SOAP, XML-RPC ...

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#106
post #103

Earlier quoted context omitted.

...and charge the going market rate of 30% of any revenue earned via the GitHub platform.

TravisCI Pro Bootstrap direct is $69: https://travis-ci.com/plans TravisCI Pro Bootstrap via Github is $89: https://github.com/marketplace/travis-ci/plan/MDIyOk1hcmtldH...

any indication why the prices are different? it's not like they think we won't sniff that out, right?

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#107
post #59
post #19

Hm, I like Github but I don't like this. This is a great move, but we already have a code hosting monoculture, and this subtly piggy-backs on it towards lock-in for tooling. Github knows orgs have inertia. Sorry for the slippery slopeism. I'm just imagining a future where shipping an app without a middleman moves to inconvenient, then annoying, then difficult, then impossible. Because this is exactly how we lost the…

Bitbucket has more traction than you think. Especially in megacorps who use JIRA. As long as the services have a docker container you can run locally I see no lock-in.

bitbucket was a consideration for my team, until we went through the end of life with their other git saas stash. won't consider it again because of the pain we went through due to that. went over to gitlab after that.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#109

Earlier quoted context omitted.

> You can only stage all changes in a file If I'm understanding you correctly, this is wrong. You can add individual lines in a file to your commit. That's one of the main uses I have for the app: it's easier to split up file changes between commits than on the command line. See this screenshot: http://imgur.com/a/4CQG7 You have to click on the line numbers to add/remove individual lines.

Not a very obvious UI!

Well, fortunately it's free and open source: https://github.com/desktop/desktop

You could submit an issue or a pull request with suggestions on what a more obvious UI might be!

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#110

Kinda random - anyone have experience scaling GraphQL APIs? It seems super difficult since you're basically giving clients the ability to arbitrarily query your data.

I never worked on Github scale but if your API is not open and you're in control of all of your clients. Take a look at Persisted Queries[1] . It enables you to whitelist all queries that your application uses.

[1]: https://github.com/apollographql/persistgraphql

Post reply on HN