Live data from Hacker News

GitHub announcements: Marketplace, Apps and GraphQL API

github.com

121–130 of 166 posts

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#121
post #83

I've recently been exploring GraphQL. It's an excellent way to design and maintain Web APIs imo. GitHub is a great resource for learning how GraphQL works. I've been using the GraphiQL tool to experiment with it. However, there is a big issue with the GraphQL implementation in that requests using the POST method work, but the mirror GET requests do not return the same results. For example, see the response for the si…

GET requests don't have HTTP bodies. How are you passing that JSON string in a GET request?

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#122
post #103

Earlier quoted context omitted.

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?

That's an oversight on Github's part and will end in a TOS change in one of two directions: price parity or complete prohibition of paid services that use GH integrations outside of the marketplace

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#123
post #88

I just got an advertising email about this from GitHub, even though I've never subscribed to GitHub advertising mail. I just checked my email settings and it looks like GitHub has added a new option (defaulting to being "on" of course) that auto-subscribes you to spam. Surely the unsubscription laws don't allow you to retroactively add more options that are defaulted to being on that subscribe you to things you were…

I think Twitter and LinkedIn may have patents on this dark pattern, based on the frequency with which they do it.

Seriously, Twitter has ~20 email subscription options now, and they add a new one (and opt you in) every month.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#124
post #70

Earlier quoted context omitted.

We don't have a timeline yet, but any updates will be posted on the API blog: https://developer.github.com/changes/

Does that mean you do plan to sunset it?

Not trying to be rude, but why would someone build a V4 API and plan to keep the V3 API alongside it long term?

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#126
post #112
post #91

I think it's only an upgrade for shitty REST-like protocol for APIs. The next after GraphQL will be something like executing your own code in sandboxed environment on the server, with strong constrains etc. Anyhow, I don't like centralized approaches. Easier access to Github data will encourage to create apps based on a global variable which is the Github. I'd rather want them to release installable libraries that co…

> The next after GraphQL will be something like executing your own code in sandboxed environment on the server, with strong constrains etc. Ah, like a SQL database with procedures? Honestly, I've wondered why the SQL interface isn't common for the remote APIs. My thoughts are that it's possible to run very expensive queries and you'd need provide some HTTP transport so it works for browser JavaScript.

I think we're don't do that because it's too dangerous and user would have too much privileges. I'm referring to something like AWS Lambda, but handled by your library on your web server. Say you can run JS snippet only for 10ms and the only global non-standards variables are those that contain data that can be queried. Or even pass them through function params, look:

ctx => ctx.users.filter(u=>u.name.contains('Janusz')).slice(0,10);

And that will return 10 firsts users as JSON.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#127
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…

Having a complete suite of tools will help Github compete with other options for tooling designed for bigger companies (various ALM suites, Atlassian, etc). I'm happy with it as long as third-party integrations are handled well.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#128
post #14

After trying new GitHub Desktop Beta mentioned in the article a week ago: it's still nowhere near compete enough to work: - You can only stage all changes in a file - so you can't discard 'console.log('Wooo'); debugger;' when committing, you have to remove those in your editor first, then commit. - you can't reverse commits. Need to roll HEAD back to a previous commit, push those fixes, then resume what you were work…

These sound like advance features that you can easily drop down to the CLI for.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#129
post #105
post #22

Earlier quoted context omitted.

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 ...

I agree that REST isn't a spec theoretically, but in my experience when you talk about building a Restful api you tend to be actually agreeing to use the HTTP verb spec, which is what I don't like at all.

Re: GitHub announcements: Marketplace, Apps and GraphQL API

#130
post #14

After trying new GitHub Desktop Beta mentioned in the article a week ago: it's still nowhere near compete enough to work: - You can only stage all changes in a file - so you can't discard 'console.log('Wooo'); debugger;' when committing, you have to remove those in your editor first, then commit. - you can't reverse commits. Need to roll HEAD back to a previous commit, push those fixes, then resume what you were work…

> 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.

Thanks! It took me a while to work out how to do this even reading your description.

- First I thought you select lines, like other git apps. No, it's not just that numbered line, it's the actual digits on the left.

- Then I selected some digits, expecting a 'stage' button to appear.

Then finally I realised just selecting the lines committed only them.

Even working out how to do it, it's still weird because lines with blue digits now get committed, lines with green ones don't.

Post reply on HN