
GitHub announcements: Marketplace, Apps and GraphQL API - joewadcan
https://github.com/blog/2359-introducing-github-marketplace-and-more-tools-to-customize-your-workflow
======
avaer
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 ability to send email
without paying the middleman privacy tax.

~~~
fennecfoxen
> Because this is exactly how we lost the ability to send email without paying
> the middleman privacy tax.

You want to see a tax? How does $72/user/year for code coverage tooling sound?

~~~
tuukkah
What regime forces you to use paid code coverage tooling? What percentage is
$72 of your annual per-developer budget?

------
mrinterweb
The thing I'd like to see Github focus on with their API is granular
permissions. There are many SASS integrations that I am just not comfortable
with granting access to because I don't want to have any more than necessary
3rd parties having access to repositories. Please correct me if I'm wrong, but
every time I grant an application access to my Github account, it
automatically has access to all repositories I have access to. I know there
are ways that organizations can set permissions such that they can approve app
integrations. Still, there are private repositories I have that I would prefer
to not have 3rd party integrations be able to access. With 3rd party SASS
providers having access to private repositories, it would be trivial for code
to be stolen or sold to competitors. If they wanted to be real nasty they
could rebase and force push, delete branches, tags, inject malicious code.
There are so many potential ways that providing full access to everything you
have access to in Github could be exploited.

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.

~~~
kardon33
+1 this a thousand times. The only way i have found to effectively lock things
down is using an org and creating a new Github user just for third-party
integrations.

~~~
Kequc
Bitbucket is fast, and I believe focuses on repository permissions. Have you
tried them?

~~~
kardon33
Yes, though it has been a year or two. However it's more of a personal
preference / fits within my normal work routine to use GH. I have a number of
OS repos that, for community reasons, need to stay on GH, then most of my
normal work is on GH which is generally where the concerns come in from a
security standpoint.

------
cyphar
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
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](https://github.com/settings/emails).

~~~
Drdrdrq
I usually give aliases for such accounts because of this (and because of data
breaches). Send me spam and I don't have to put up with your UI to
unsubscribe, I just delete mail alias. Of course, that doesn't work if I want
to receive any mail from you...

~~~
cyphar
What email service do you use? I've been trying to figure out where to switch
to from "the big G" and it's not clear to me what host is good.

Personally a host that has a mail client which is free software would be the
best deal. :P

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

~~~
cheshire137
> 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](http://imgur.com/a/4CQG7) You have to click on the
line numbers to add/remove individual lines.

~~~
IshKebab
Not a very obvious UI!

~~~
leesalminen
UI is same as Tower. Doesn't seem that far off for me.

~~~
roryokane
No, Tower works differently (unless it has changed in the few months since I
used it). In Tower, you can select lines by clicking line numbers, but then
you must click "Stage" to actually stage those lines. Then your selection is
cleared and those lines are moved to a separate "Staged" tab for that file.
Whereas with GitHub Desktop, just selecting the lines marks them as lines to
be staged. (GitHub Desktop doesn't actually run `git add` on those lines until
the moment you click "Commit".)

------
j_m_b
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 simple query

"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](http://graphql.org/learn/serving-over-http/#get-request)).
Could someone provide some clarity on this?

~~~
shurcooL
Perhaps [https://developer.github.com/v4/guides/forming-
calls/#commun...](https://developer.github.com/v4/guides/forming-
calls/#communicating-with-graphql) is relevant:

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

~~~
j_m_b
Thanks. I'm not sure that this conforms to GraphQL best practices.
[http://graphql.org/learn/serving-over-
http/](http://graphql.org/learn/serving-over-http/) It seems GET methods
should be supported for more than just introspection queries.

------
Entangled
How about communities, forums, boards? When I see an interesting project I'd
like to talk to the developer without cluttering the Issues section.

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.

~~~
hashkb
Why do you think you'd be cluttering the issues section? I wouldn't let that
(your) perception stop you. Just open the issue if you have something to say.

~~~
giaour
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!

~~~
marcosdumay
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.)

~~~
giaour
Feature requests are fine, since, like bugs, they have a defined scope and
will eventually be done. However, I've seen some major products move their
feature requests to a platform like UserVoice that's designed to track votes
and progress.

------
23david
"Once your revenue reaches a minimum of $500 USD for the month, you'll receive
an electronic payment from GitHub for 75% of the sales price."

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.

~~~
LeanderK
Wow, i think 25% is more than enough, they don't have costs that justify 25%.
It's just their monopoly that allows them to charge that much.

~~~
bradleyankrom
Monopoly in what sense? There is certainly healthy competition in the hosted
Git repository space.

~~~
overcast
You mean the ones that delete their databases without backups?

~~~
bradleyankrom
I assume you are referring to GitLab, so yes. GitLab and Bitbucket are both
actively releasing new features and have sizable paid user bases. GitHub is
the market leader, no question, but it not nearly a monopoly.

~~~
stephenr
"Market" is an interesting concept here.

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"?

~~~
moby
"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.

------
shabbyrobe
Nice to see the old "oops we didn't bother to check the if the 'subscribed'
column was true when we imported the mailing list" trick isn't beneath GitHub
either.

------
Klathmon
This is really cool, and I just discovered sentry.io because of it which is
something that we have wanted but hadn't yet put the time into finding.

~~~
mwarkentin
Sentry is pretty awesome. There are a few similar services like Airbrake,
Rollbar, etc.

------
davidjgraph
"...fine-grained repository permissions with GitHub Apps...", excellent, this
caused us more problems integrating than anything else. Especially for an
organization, anything beyond 15-20 repos and they just couldn't give
permission.

Edit: It only applies to Github Apps, we have an OAuth App. shame.

~~~
bkeepers
GitHub Apps also support authenticating users with OAuth, so you might want to
check out if it makes sense to migrate.

[https://developer.github.com/apps/building-
integrations/sett...](https://developer.github.com/apps/building-
integrations/setting-up-a-new-integration/about-choosing-an-integration-type/)
[https://developer.github.com/apps/building-
integrations/sett...](https://developer.github.com/apps/building-
integrations/setting-up-and-registering-github-apps/identifying-users-for-
github-apps/)

------
shurcooL
REST v3 API supports conditional requests, that return 304 when content hasn't
changed since last time you asked and don't count against rate limit. It means
one can use a caching HTTP transport and benefit from that.

Is there any support for caching in the GraphQL v4 API? I'm not seeing
anything about it in the docs.

~~~
cryptonector
If your query is complex and/or depends on sharded data, it can be difficult
or impossible to cheaply (i.e., without re-executing the query) check whether
the results have changed. That doesn't mean that the server couldn't execute
the query, hash the results, and compare to an ETag from a client's If-None-
Match: header, or some GraphQL equivalent of that (if it has it), thus saving
network bandwidth. You just might not be able to save cycles and I/O on the
server-side.

------
chaostheory
Github's Marketplace would be much better to Github's bottom line long term if
they expanded the free plan to include private repos. I can see this working
more to bitbucket's benefit if Atlassian gets more aggressive with its own
marketplace offering.

------
santiagobasulto
Anyone knows if they plan to deprecate V3 (which is likely) and when?

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

~~~
hashkb
Does that mean you do plan to sunset it?

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

------
philip1209
This feels like a Docker-esque move. Taking a product that people love, then
thinking that they can conjure new features on top to grow more. The issue is,
none of these new features really seems to be something that people want. So,
it creates bloat and harms the core product.

------
smagch
I guess that the main benefit of GitHub Marketplace would be the full-scale
integration with GitHub Issue and Project board, launched last year. Consider
a common situation: when CI fails, people need to reopen an issue manually,
getting an error report via email. People who are in charge of project
management may be seeking a better way to streamline the manual task, which
probably increased since the introduction of Project board.

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?

------
ed_blackburn
I wonder how this will work with GitHub Enterprise?

~~~
bkeepers
GraphQL will be available in GitHub Enterprise 2.10, and GitHub Apps will be
available in 2.11. For Marketplace, we will be researching how to solve
similar problems for Enterprise customers after this initial launch.

------
sdesol
Can somebody from GitHub comment on this?

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

------
mrclark411
The Listing requirements: [https://developer.github.com/apps/adding-
integrations/listin...](https://developer.github.com/apps/adding-
integrations/listing-apps-on-github-marketplace/requirements-for-listing-an-
app-on-github-marketplace/) mention: \- OAuth Apps should have a minimum of
1000 users. \- GitHub Apps should have a minimum of 250 installations.

Does this mean you aren't listed on the Marketplace until you have 1000 users
+ 250 installations?

~~~
creichert
GitHub apps are slightly different than OAuth Apps.

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.

~~~
mrclark411
Thanks.

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...](https://help.github.com/articles/github-marketplace-developer-
agreement/)

The GitHub Marketplace will be an exclusive place for a while with those
requirements.

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

~~~
thangngoc89
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](https://github.com/apollographql/persistgraphql)

------
kkirsche
If I install a free version and hit the limit does it auto upgrade me and
charge me or am I just cut off from the service and told I should upgrade to
keep using it?

~~~
kareemm
I'm an owner at Codetree - one of the project management launch partners for
Marketplace. We talked through this scenario with GH when we were integrating.

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.

------
mtw
How is GraphQL related to the marketplace?

~~~
alangpierce
It's not. Each section of the post is a separate announcement.

------
strin
So this is a marketplace for "meta-apps" \- apps that run on codebases.

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.

------
nikon
No CI? Gitlab and Bitbucket have built-in pipelines.

~~~
user15672
What's the point in GitHub creating yet-another-CI-tool? Travis and Circle CI
have had good integrations for years and work very well.

~~~
nikon
Cost?

~~~
user15672
Circle CI works well on their free tier, so no, not cost.

~~~
nikon
If you're OK with one container, sure.

~~~
felicianotech
You can always purchase more plus open-source projects get four containers for
free.

------
therealmarv
I did not followed recent GitHub news closely. Is GraphQL a new thing at
GitHub? And do you think GitHub integration benefits from this?

~~~
m12k
GraphQL is a method of creating APIs for consumption by e.g. JavaScript apps
or mobile apps that is gaining popularity at the moment. So it can be seen as
a successor to REST. It gives you a pretty easy query language to specify
which data on which objects you are interested in and that data is then
fetched for you. An example could be a React app where each component
specifies which data it needs to work on, and then when a page is loaded, all
of the rendered component's queries are merged into a single query that
fetches all the data in one go.

~~~
mpetrovich
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...](https://philsturgeon.uk/api/2017/01/24/graphql-vs-rest-overview/)

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

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

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

------
bartq
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 communicate with other parts of the system.
Sort of.

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

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

------
erikbye
I expected GitHub to attempt further monetizing but perhaps not something as
cheesy as an "app store".

------
l5870uoo9y
Better integration and monetization of Github Apps (formerly Integrations)?

------
arca_vorago
Is it all GPLv3'd? That's my question. If not, why not?

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

~~~
moron4hire
So what the hell is "Show HN" _but_ marketing?

~~~
stephenr
Show HN is expected to be submitted by the person who made the thing to show,
and it's expected that they're showing it for a reason: it's either new, or
had a significant change.

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.

------
stephenr
The eerily similar posts from CEO/etc of "chosen partners" in this thread is a
bit creepy.

"We are the chosen ones. We love the leader."

~~~
hashkb
Beyond creepy. It's gross, shameless, and inappropriate content (marketing)
for an HN comment.

------
peter_retief
Only for Mac or PC? Clearly not aimed at me

------
romanovcode
So basically they just released GraphQL. Everything else is just renaming?

------
brentvatne
There is some undesirable horizontal scrolling on this page for me (mbp 13")
-- fixed by adding `overflow: hidden` to `div role="main"` element.

~~~
codefined
Just hiding bugs isn't a good practice! It'll ruin responsiveness with lower
resolutions where that content is required.

Actually fix the underlying cause, not just add a quick hack to make it go
away.

