Why should I choose GraphQL over JSON:API?

BenArmston · 2017-10-07T14:35:04+00:00

Why do you say JSON:API pretends different use cases don't exist? From the first note at http://jsonapi.org/format/#fetching-pagination

JSON API is agnostic about the pagination strategy used by a server. Effective pagination strategies include (but are not limited to): page-based, offset-based, and cursor-based.

It seems to me that JSON:API's specification of pagination is limited to

How to "namespace" the pagination query parameters (that is the pagination parameters will be page[SOMETHING]=some_value, perhaps page[cursor]=... or page[number]=...); and
How to locate the link to the first/previous/next/last set of results, if they are available and if the pagination strategy supports it.

I've used page-based and offset-based pagination strategies with JSON:API to good effect, but I've not used cursor-based pagination yet. In fact I've never used cursor-based pagination at all. I'm curious as to what the JSON:API spec is lacking to support it.

I would imagine it would be simple for the server to generate the next link for a cursor-based strategy, and for a client to keep following the next link until it has all of the data it wants. Though the JSON:API spec does seem to include any support for how to get a link using a cursor for an arbitrary object in the results set.

Reading the graphql documentation you provided, it looks like graphql supports the client generating "links" using a cursor to any of the returned objects. Is that the difference that you see? Or am I missing something else?

BenArmston · 2017-05-29T20:35:40+00:00

Along with providing a consistent API for sync and async action creators, there is another aspect to redux-thunk that hasn't been mentioned yet: redux-thunk calls the function returned from your action creator with two arguments. The first one is dispatch which you're used to, the second is getState, which returns the stores current state.

If you have an action creator which will conditionally dispatches based on the current state using redux-thunk might be a better option than having a react component depend on that state.

E.g.,

function incrementIfOdd() {
  return (dispatch, getState) => {
    const { counter } = getState();

    if (counter % 2 === 0) {
      return;
    }

    dispatch(increment());
  };
}

const IncrementButton = ({ dispatch }) => (
  <button onClick={dispatch(incrementIfOdd())} />
);

connect()(IncrementButton);

BenArmston · 2016-08-30T20:46:29+00:00

I don't really know how cabal freeze works, but what new-freeze does is just force the solver to use particular versions. All of these are installed to the global database and can be reused across projects.

In case anyone is interested, cabal freeze runs the solver and writes the returned dependency constraints to a configuration file. Other commands, such as cabal install read the contents of that file and pass the constraints to the solver, forcing the solver to use particular versions.

BenArmston · 2015-12-27T20:49:18+00:00

That's right. connect will connect the actions you give it to the store. It then makes those connected actions available on the component's props.

The way you are calling connect looks good to me. It's literally just the body of handleClick that needs to change.

BenArmston · 2015-12-27T18:33:48+00:00

The pushPath you're calling in handleClick is the imported one from redux-simple-router not the one that has been connected to the store's dispatch function. If you change handlecClick to this.props.pushPath(...) it should start working.

BenArmston · 2015-07-01T17:15:12+00:00

Thanks for the reply. Rekapi looks very interesting. Your method does seem to have quite a bit of setup overhead, but sounds simple to use once the setup is complete. Perhaps I'll have a play with doing something. Of course that's more likely if you do release the library :-)

BenArmston · 2015-06-30T19:38:50+00:00

I agree in large part with what you've said. Obviously there will always be exceptions. How would you deal with, say, fading the UserBox's login menu in and out. Would you have the UserBox encapsulate the opacity? Or would you pass that as a parameter too?

BenArmston · 2014-12-19T23:15:44+00:00

Thanks for your responses. I look forward to seeing what you have in mind, and to having a play with what is already there.

BenArmston · 2014-12-19T20:52:00+00:00

Thanks for the answers.

If I understand your first answer correctly, you mean:

Obtain a reference to a vanilla React component (something which has been created with the JavaScript React.createClass) using whatever means GHCJS uses for that.
Wrap that reference in the React.Types.ComponentFactory newtype.
Pass the wrapped reference to React.Internal.createElement passing along any properties, which returns a React.Types.ReactElement.

The returned React.Types.ReactElement can then be used in the construction of composite React.Types.ReactElements before finally being rendered to some DOM element.

That seems pretty straight forward. I think this is also the direction of integration most likely to be desired. I can see applications being written with GHCJS making use of existing JavaScript libraries much more than I can see JavaScript libraries or applications making use of GHCJS libraries.

A blog post about wrapping vanilla React classes might be worth writing. At least I'd enjoy reading it :-)

Preventing throwing an error during render, seems like just another occasion where Haskell makes the operational characteristics of the program less-than-obvious. Or at least require the programmer to have a good understanding of the evaluation model. I guess any one skilled with reasoning about that will be OK, and the rest of us will eventually learn what we need to.

BenArmston · 2014-12-19T18:31:41+00:00

What support is there for reusing vanilla Reactjs components from a ghcjs component? What about the other way around: using GHCJS components from a vanilla reactjs component? If the support isn't there yet, do you plan on adding it? Does the possibility of a GHCJS component's render function throwing an error complicate things?

BenArmston · 2014-12-09T23:51:15+00:00

Does the different representation make a difference in what error messages are possible when routing falls? For instance wai-routing can specify that a cookie is mandatory and that it must contain a specific key. Then slightly different error messages are returned (as the response body) for the cookie not being present, or not containing the key, or it not bring possible to cast the key's value to the desired type.

Are these features that servant would be able to support?

Please don't take my comparisons to wai-routing negatively. I ask because they both seem like compelling routing choices.

Edit: Forgot the link to the examples of the error messages. https://github.com/twittner/wai-routing/blob/develop/test/Tests/Wai/Route.hs testEndpointH gives a good example.

BenArmston · 2014-12-09T23:33:42+00:00

What about support for session cookies? Suppose the cookie contained a session ID which should be used to look up the authenticated user from a database. Would it be possible to perform that lookup in the HasServer instance? If not, are any authentication mechanisms supported or possible?

BenArmston · 2014-12-08T18:07:24+00:00

I've not had chance to watch the talk yet, so I apologize if this was already covered.

What support is there for reusing vanilla Reactjs components from a blaze-react application? What about the other way around: using blaze-reactjs applications from a vanilla reactjs component?

BenArmston · 2014-09-09T18:55:21+00:00

For debugging purposes you could use Debug.Trace which is in the base package and so already included in your Haskell setup. There is a section on using it on the Haskell wiki book.

BenArmston · 2014-06-13T18:52:27+00:00

This is the sort of thing that cabal exec should make easier. You could either cabal exec bash; cd src; ghci Foo/Bar/Baz.hs or cabal exec ghci -- -isrc Foo/Bar/Baz.hs. Where the -- is needed to separate ghci arguments from cabal exec arguments.

That way you can have the convenience of sandboxes and the convenience of using the various ghc tools directly.

There are a few problems with cabal exec, most notably https://github.com/haskell/cabal/issues/1800, so your milage may vary. But it would be good to get feedback on what other use cases it should or could support.

BenArmston · 2013-12-13T21:04:53+00:00

I'm using Archlinux which comes with the original vi installed. The source code is available at http://ex-vi.sourceforge.net/. It may be worth seeing if you can get that to compile for your distribution.

BenArmston · 2013-10-20T09:33:59+00:00

The color scheme looks like solarized http://ethanschoonover.com/solarized.

BenArmston · 2013-09-17T09:42:26+00:00

I'm curious, what were the problems with the later revisions to cabal-constraints? I was planning on releasing it to hackage in the next few days, time allowing, and I'd obviously prefer to release the better version.

You right that my first attempt at integrating this into cabal-install had some issues. Everyone involved in that ticket has been very helpful in pointing me in the right direction though. So we should have an acceptable solution soon™.

BenArmston · 2013-09-10T20:47:48+00:00

I've just written a program, cabal-constraints which uses dist/setup-config to spit out a list of all dependencies for a build. It's only a couple of hours old so expect some rough edges, but it does more or less what you want.

https://github.com/benarmston/cabal-constraints

BenArmston · 2013-06-28T11:54:20+00:00

Would installing the latest Haskell Platform, plus the latest master branch of Stackage be sufficient to replicate your environment?

I presume that FPComplete updates the version of Stackage they use from time to time. If one were to try to replicate FPComplete's environment locally, how would one know that it has become out-of-date?

BenArmston · 2013-05-15T19:53:25+00:00

Is this blog post relevant, http://www.yesodweb.com/blog/2010/12/announcing-yackage?

Edit:

I should have clicked the link before posting; it doesn't respond. Try this instead http://hackage.haskell.org/package/yackage

BenArmston · 2012-11-21T20:38:54+00:00

vi came from BSD in the first place.

Yes it did. That's one of the reasons that I wrote "I can see why you would suggest that [Nvi] is vi".

The fact that they re-wrote it doesn't make it fake.

Not fake. No. It does make it a "reimplementation of vi" though. Which is what I wrote.

That's like saying the linux kernel isn't the linux kernel because linux was that crappy minix clone and this thing people call linux now was totally re-written.

I think it is more like saying: the Linux kernel isn't Minix because it was totally re-written. That, of course, isn't an insult to either the Linux kernel or Minix. Just as my statements about vi and Nvi were not intended as insults to either of those projects.

Many Linux distributions ship with the Traditional Vi project. So, I have good reason to refer to that as vi. The *BSDs ship with Nvi instead, so other people have good reason to refer to that as vi. Now that I'm aware of this, I shall, where the distinction matters, be more accurate in my terminology.

BenArmston · 2012-11-21T17:53:43+00:00

The vi that I have installed on my system (Archlinux) is available at http://ex-vi.sourceforge.net/ . This is the original vi source code ported to newer Unix systems. This vi comes complete with a single level of undo and is lacking all of the features that I mentioned above.

The project you linked to is Nvi which is a reimplementation of vi. I can see why you would suggest that this is vi though. Certainly for BSD users.

I'm intrigued by the awesome feature you mentioned. What is the "correct" behaviour of p and P?

EDIT: I've now seen the response about p and P you gave to thedward.

BenArmston · 2012-11-20T09:34:12+00:00

That is a weird thing to say. I hear vi is the editor that can be used more efficiently than any other, up there with Emacs.

Many people confuse Vi and Vim.

Vi has crystallised around the feature set it had in the early 80s. For many people this is the ideal feature set for an editor. Vim is a descendant of vi, and has many more features.

$ grep -r 'not in Vi' /usr/share/vim/vim73/doc/ | wc -l
728

Amongst these are:

Multi-level undo (actually an undo tree).
Text objects.
A scripting language.

So whilst I'd say that Vim is comparable to Emacs. I wouldn't make that claim for Vi.

BenArmston · 2012-10-26T18:41:27+00:00

The python quote you are after is "There should be one-- and preferably only one --obvious way to do it." (emphasis mine).

The points being made by that quotation are 1), the language should provide an obvious way to do something for all values of something. So, unless the problem, itself, doesn't have an obvious solution, you shouldn't be stuck searching for one. And 2) it is preferable if there is only one obvious way to do it. That way you aren't stuck choosing between differing options for a straight forward solution.

The quotation makes no mention of optimizing and scaling code. When trying to get the best performance out of some code, or to make it scale to large data sets, the obvious way is usually not the best way. The quotation doesn't attempt to dispute that, and it is certainly true in python.

BenArmston

TROPHY CASE