GitHub announcements: Marketplace, Apps and GraphQL API
github.com
github.com
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 ability to send email without paying the middleman privacy tax.
- Docker - Heroku - AWS - Google - Direct
Feels more for "discovery" than purchasing.
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.
TravisCI Pro Bootstrap via Github is $89: https://github.com/marketplace/travis-ci/plan/MDIyOk1hcmtldH...
I would say that the irony occurred when the "hub for open-source projects" is a closed-source platform.
(And I would say that as a paying user of Github that rather loves it.)
People already pay anywhere from 3-10x more for GH than for alternatives like BitBucket. I'm sure plenty will just click on 'buy'.
You want to see a tax? How does $72/user/year for code coverage tooling sound?
I would love to see Github add permissions to apps requesting OAuth permissions be able to restrict access to the repositories the 3rd party app has access to. It would also be nice to be able to revoke individual permissions.
[Edit] fixed some grammatical errors.
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 never subscribed to in the first place? Seems like an easy way to spam people without having any repercussions.
For those who want to disable this anti-feature, look at the bottom of https://github.com/settings/emails.
Personally a host that has a mail client which is free software would be the best deal. :P
Seriously, Twitter has ~20 email subscription options now, and they add a new one (and opt you in) every month.
http://www.acma.gov.au/Industry/Marketers/Anti-Spam/Ensuring...
- 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 working on? You can't do it.
- still no graphical interactive rebase to merge and squash and reorder commits (the main reason people put up with sourcetree).
It feel fast and responsive though.
Edit: downvotes seem odd. If you think this is offtopic, the GitHub Desktop Beta is announced in the article.
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.
You could submit an issue or a pull request with suggestions on what a more obvious UI might be!
- 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.
"query { viewer { login }}"
My understanding is that this request should return the same result, whether or not it is a POST or GET request (http://graphql.org/learn/serving-over-http/#get-request). Could someone provide some clarity on this?
I'm fond of the idea of allowing the query itself to contain every head-meta-data as well, i.e.,: `query { viewer(auth_token: "...") { login }}` because such queries are possible to copy in a URL without having to worry about side-channels of auth.
> In REST, HTTP verbs determine the operation performed. In GraphQL, you'll provide a JSON-encoded body whether you're performing a query or a mutation, so the HTTP verb is POST. The exception is an introspection query, which is a simple GET to the endpoint.
It could be the entry point of every repo, moderated by the owner of course (something like php docs where people can post interesting stuff related to the page at the end). And it would make Github more social.
Someone should probably give a go at making a site like that. Making it easier for project owners to find contributors and for potential contributors to find projects. Facilitating discussions beyond in issues, etc.
And what if the maintainer does not talk about any forum in the README? (What is, like, some 90% of the repos.)
So it looks like Github takes a 25% fee. I thought maybe they would do something more innovative regarding the fee structure, or maybe have a lower intro fee like 15%. But here is seems pretty much on par with the 30% of the Heroku marketplace.
Do you compare all usage, or just their hosted versions (i.e. do on-premise installs count)?
Do you compare all usage, or just paid usage?
Can a company that's not even close to profitable be considered a "market leader"?
Sure it can. Uber and Twilio are generally considered, far and away, as market leaders in their respective spaces; Uber is massively unprofitable and Twilio was operating at a loss at the time of its IPO.
Market leadership is a function of production and capacity, not profitability.
Edit: It only applies to Github Apps, we have an OAuth App. shame.
https://developer.github.com/apps/building-integrations/sett... https://developer.github.com/apps/building-integrations/sett...
Is there any support for caching in the GraphQL v4 API? I'm not seeing anything about it in the docs.
We're a small business and planning the work ahead of time is our only hope.
To be clear, I’ve been away from software development over the years, so I’m curious about the impact of Project board. Does it useful in the first place? Did it require manual tasks between other services such as CI? Do you, who is in charge of issue or board assignment, feel frustration using it?
> Apps cannot actively persuade users away from GitHub.
This is listed as requirement from the "Requirements for listing an app on GitHub Marketplace" page. Is this saying your app should only support GitHub?
Does this mean you aren't listed on the Marketplace until you have 1000 users + 250 installations?
GitHub Apps are per-repository "integrations" that don't perform actions on behalf of a specific user and are installed directly to a repo (with fine-grained permissions).
OAuth Apps are the classic "integrations" installed by a specific user and perform actions on behalf of that user.
I imagine they have lower requirements because they are new, more specialized, and likely to be installed a little less.
I also see that the security requirements are quite high. While its difficult to argue with source code security - here are some of the security requirements:
The standard annual risk assessment shall include, to the best of Developer's ability, the following:
(i) SOC 1 and/or SOC 2 audit report; (ii) 3rd party proof of PCI compliance (a certificate showing Developer's handling of credit card payments is compliant); (iii) Privacy Shield Attestation; (iv) ISO Certification or Cloud Security Alliance Self-Assessment; (v) Cloud Security Self Assessment; (vi) any information on subcontractor or vendor production datacenter(s), IaaS, PaaS, or private hosting providers, as required by GitHub based on data and services rendered; and (vii) Written responses and evidence of specific security requirements as outlined in this agreement
https://help.github.com/articles/github-marketplace-develope...
The GitHub Marketplace will be an exclusive place for a while with those requirements.
What happens today is the limits are enforced on the app side, not he GitHub side.
So for example our free plan is two users. If you wanted to add a third you'd need to go GH Marketplace and upgrade to the eg 10 user plan. That would trigger an upgrade in Codetree and your plan there would enable you to add up to ten users.
In short: you trigger upgrades and downgrades, not the tool vendor you're using or GH, and thresholds are stored in the tool vendors database so they're the ones who decide how to tell you that you need to upgrade.
I am concerned if in the future Github will add private repos to the marketplace. Making this move will discourage people from sharing code freely.
https://github.com/marketplace/category/continuous-integrati...
All new features at GitHub are now developed with GraphQL first which means integrators will have access to the same API that we built the feature on once it ships.
If you want to learn more, one of our engineers just spoke at GraphQL Europe yesterday detailing our experiences with GraphQL thus far, here are his slides: https://speakerdeck.com/bswinnerton/launching-githubs-public...
In graphQL there's one resource and you query it to tell you what you want.
https://blog.runscope.com/posts/you-might-not-need-graphql
tl;dr: maybe you want OData, JSON-API, or one of the many other standards or practices that solve this simple problem as their super-set of functionality on top of the networking principles of REST.
Using GraphQL for this alone is rather nuclear, as you gain a lot with GraphQL but lose other stuff.
https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overv...
The REST philosophy is so conceptually big that it's useless for actually building a system; what I meant by 'in practice' is that REST in practice is 'how do I stuff what I want into the http verbs and make it seem plausibly like state transfer' and that's an exercise that I can't see myself doing 'for purity' again. (in a simple app that actually is just asking about and updating state, sure, it's fine. But when you have to make ten queries for different records because you can't ask the server to join things for you dynamically, it's less fun.)
(edit: especially when you need the results to be an atomic picture of the underlying data, gathered in a transaction. Do I invent a GET resource for every tuple of values I might want to query directly? Or do I stop blindly following an architecture and do the practical thing and implement real queries? A: Always the latter.)
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 a sparse fieldset query parameter [1]:
/users/123?fields=name,email,work.name,work.address
user({ "id": 123 }) {
name,
email,
work {
name,
address
}
}
GraphQL is a form of RPC, it's not REST.
It's a tradeoff that makes sense for Facebook. It allows them to make changes to their API without needing to version it. And they can take the hit of more requests hitting their server. For most apps though, I think the tradeoff is probably not a great one to choose.
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 ...
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.
ctx => ctx.users.filter(u=>u.name.contains('Janusz')).slice(0,10);
And that will return 10 firsts users as JSON.
HN submissions are open, nothing stops them writing a blog post and submitting that.
The similarity of the posts makes it seem like a coordinated effort by those involved. A circle jerk of marketing bullshit, if you will.
Edit: So technically, GH probably could have had their new shit posted as a Show HN: but you generally want that to be something people can 'play' with right away, not a blog post about a way to pay more for the same things. /Edit
My best guess with what happened here (based on the similarity of the texts) is that GH arranged a pre-formatted 'base' text, with placeholders, sent it to each of the involved CEOs/whatevers and said "we will submit our story to HN, once we do please comment using this template".
Every one of the comments basically matches this pseudo-regex: "<Name> (at|from) <Company> [1] ..... one of the ([:digit:] <App Category>)? launch partners" and the [1] is referenced as a link to GitHub Marketplace. Only one has a link to their own site.
The HN story itself was submitted by someone who at least used to be, and based on that, likely still is a GH employee.
I assume they were trying to drum up lots of positive attention about this with the cool-kid me-too cargo-culting developer set that makes up a large part of HN readers.
"We are the chosen ones. We love the leader."
Actually fix the underlying cause, not just add a quick hack to make it go away.